Cells Infrastructure Team

Vision

The Cells Infrastructure team is responsible for developing key services and components of the Cells architecture. The team also collaborates closely with other infrastructure and development teams on their contributions to Cells.

Team Members

How We Work

Project Management

Issue Tracking

The Cells Infrastructure team adheres to these core principles:

1. Assign only actively in-progress issues. Issues that aren’t being worked on should remain unassigned.
2. Apply mandatory labels. Every issue must include:
   • group::cells infrastructure
   • devops::tenant scale
   • Category:Cell
3. Add service-specific labels as needed. If an issue pertains to a particular service (e.g., the Topology Service), tag it accordingly—e.g., Service::Topology Service.

The Cells Infrastructure team works across multiple GitLab projects such as gitlab-org/gitlab, gitlab-org/cells/http-router, gitlab-org/cells/topology-service, and gitlab-com/gl-infra/gitlab-dedicated/instrumentor. By default, you should open issues that will be owned by the team under the Cells Infrastructure Team Issue Tracker and apply the group::cells infrastructure label. Move issues for the Cells Infrastructure team from other projects to the team issue tracker when appropriate.

For issues tracked in the team’s issue tracker or other gitlab-com/gl-infra projects, we use the workflow-infra::* labels to track an issue’s workflow status. Ensure that all issues that are in progress, ready, or need triage have the relevant workflow-infra::* label applied. We use a workflow issue board to track the workflow status of active issues.

Sometimes we’ll need to track issues contained in the gitlab-org top-level group, which does not contain workflow-infra::* labels. For these issues, please use the workflow::* labels. We track these issues using a workflow issue board for gitlab-org. If you need to make an issue in gitlab-org please mention @dlogalbo by using /cc @dlogalbo.

Having two issue boards is not ideal and is a result of our recent reorganization into the Infrastructure Platforms department. Our long-term goal is to minimize the amount of issues that we need to track in the gitlab-org group and to primarily use the team’s issue tracker in gitlab-com/gl-infra/tenant-scale/cells-infrastructure/team.

Workflow Label Mappings

The following are the workflow::* and workflow-infra::* labels that we use and how they map to each other.

Issue Descriptions

All issues need to include a description of the work, any identified action items or exit criteria. When decisions are made regarding implementation details that change the initial description, update the description (and issue title if necessary) so that it always accurately reflects what the issue is implementing or achieving.

Blocked Issues

We use the following guidelines for denoting when an issue is blocked:

• If an issue depends on the completion of another issue, we use the blocked by feature to denote the dependency.
• If an issue was started but requires further input, completion of another issue, etc before progressing, we use ~"workflow-infrafin::Blocked".
• If an issue is blocked by work required from another team please make sure that team is aware and the appropriate labels are applied.

Epic Tracking

[TODO]

Ways of Working

Team Meetings

Each week the Cells Infrastructure meets for one hour on Tuesdays - alternating between APAC/EMEA and AMER friendly time zones. The intent of this meeting is to:

• Demos
• Review any technical decisions, blockers, etc. as a team to get feedback.
• Share information that the team should know
• Team discussions (process, roadmaps/upcoming work, company items, etc.)

Geekbot/Status Updates

We use an integration with Slack, Geekbot, to provide updates on work in progress. Each Monday and Thursday, Geekbot will ask team members for an update and post via Slack.

Manager Responsibilities

Each week the EM will review the issue boards. The intent of the review is to:

• Ensure that issues have the appropriate workflow labels.
• Check on the status of in progress, blocked, and in review issues.
• Ensure that there are refined issues ready to be worked on. Refined issues are weighted, have sufficient context in the description, and a workflow label indicating that it is ready to be worked on.
• Check that issues are aligned to our roadmap and status updates on relevant epics.

AI Prompts used by the team

Weekly Epic Summaries

Each week we have to generate a status report of what happened during the week across in cells infrastructure for tenant scale level reporting. The following is an AI prompt that can be used to generate this status report

Using this markdown template write a summary for cells infrastructure this week using the most recent epic updates in cells infrastructure

2025-xx-xx Update for Grand Review
:issue-blocked: Help Needed / Blockers

None this week

:closed_book: To Be Closed

None this week

:star2: Highlights

None this week

Issue Readiness

Evaluate this issue based on the following checklist and provide recommendations

### Core Requirements
- [ ] **Context**: Team/section identified with labels?
- [ ] **Problem**: Clear current vs desired state?
- [ ] **Action**: Next steps with checkboxes or clear options?
- [ ] **Links**: Parent epic/initiative referenced?
- [ ] **Specifics**: Exact component/table/index/config names provided where known?

### Discussion Issues Must Have
- [ ] **Questions**: Specific items needing input listed?
- [ ] **Stakeholders**: Tagged with reason for involvement?
- [ ] **Timeline**: Decision or action timeline indicated?

### Labels Present
- [ ] Category label (e.g., `Category:Cell`)
- [ ] Team/group label (e.g., `group::cells infrastructure`)
- [ ] Type label (e.g., `type::maintenance`)

### Communication
- [ ] Resources/documentation linked?

## Score
- **Ready**: 80%+ checked
- **Needs work**: 50-79% checked
- **Not ready**: <50% checked

Issue Summary on close

Provide a concise summary to put in issue description upon close, include reference to any threads where research, discussion or data was referenced, create a summary table where appropriate

Manual Testing Plan Creation

This prompt helps create testing plans for merge requests. Usually requires refinement to specify the testing approach:

Create a manual testing plan for this merge request so I can run it myself.

Example refinement for specific scenarios:

Create a manual testing plan using grpcurl for the new protofiles that are added.

Code Review and Explanation

During code reviews, use this prompt to understand changes:

Why are the changes in file X needed? What are they doing?

Alternative prompt for more comprehensive analysis:

explain what these changes are doing, why they are necessary, and what other possible alternatives to the current approach are.

Documentation Updates

During merge requests, check if documentation needs updating:

Should I update any documentation anywhere?

Resources

• Slack (internal): #g_cells_infrastructure, #g_cells_infrastructure_standup
• Cells Infrastructure Team Issue Tracker
• Team Member Assigned Issues Board
• Issue Board gl-infra
• Issue Board gitlab-org

View page source - Edit this page - please contribute.