Define the process for involving other groups in Cells' work

Description

The Tenant Scale group cannot accomplish all the Cells' work without the involvement of other groups. During the last quarter, we learned how to implement Cells work and defined the Cells development guidelines. We need to involve other groups and closely collaborate with them to complete the Cells project.

Next steps:

• Review current development guidelines, existing examples, epics, etc.
• Create a template with all the information about what we want to achieve and what we need from them, see below.
• Reach out to all the groups with the template
  • Groups identify their workflows and for each one:
    • Create epic
    • Create issues
    • Fix issues
    • Demo
• Create OKRs to track the progress
  • (FY25Q1 OKR) Define their own workflows
  • (FY25Q1 OKR) Create an epic for each workflows and the issues, including a demo
  • (FY25Q1 OKR) Close 2-3 issues
  • (FY25Q2-FY25Q3 OKR) Complete 1 workflows with a demo

Template

Title: Cells: Define <group name> workflows

Context

Hi , . The growth of GitLab's SaaS business is putting increasing pressure on GitLab's primary database. To solve this problem we are creating a Cells architecture, which consists of many mostly isolated GitLab instances. The number of Cells can grow alongside the growth of our business. Organizations are the vehicles in which we can distribute customer data across multiple Cells. They require isolation from each other to ensure they remain movable between independent Cells.

Workflows

The Tenant Scale group has defined a list of essential workflows (epic) and a list of additional workflows (epic). Essential workflows are meant to cover the majority of the application functionality that makes the product useable, but with some caveats. Please prioritize this work if your group owns one of the essential workflows.

What are we asking you to do?

Why?

The scope of the Cells project is so vast that we need everyone's help. Every team owning features has the most context. We are making many assumptions, but having detailed knowledge of the different parts of the product and the customers' needs is essential to make good decisions. Moreover, it's important that teams understand the implications of the Cells architecture on their workflows/features and are empowered to make the changes needed to make these workflows compatible with Cells.

OKRs

We will create OKRs to track this work and help you with the priorities. Here is what we are asking you to do:

• (FY25Q1 OKR) Define your own workflows. See the existing examples for essential workflows and additional workflows. Please take into account we are referring to Cells, but some functionality should be scoped to the Organization level, eg. groups and projects will belong to one Organization.
• (FY25Q1 OKR) Create epics under &11688 (closed) for each identified workflow and the corresponding issues, including a demo issue. See User can create a group, and User can create a project as examples.
• (FY25Q1 OKR) Close 2-3 issues of one workflow. Follow the Cells Development Guidelines and Multiple Databases Docs to approach this engineering work. As part of this work, you may create cross-database issues, but they are not blocking the demo. Please make sure you also schedule them at some point because we will need them before the production release.
• (FY25Q2-FY25Q3 OKR) Complete 1 workflows with a recorded demo. See a recorded workflows example.

Questions

If you have any questions, do not hesitate to contact the Tenant Scale group, and we will try to help as much as possible or give further direction. Our engineers can also help with any technical questions and during code reviews.