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

Name	Role
Manager, Engineering	Manager, Engineering
Aaron Richter	Site Reliability Engineer, Cells Infrastructure
Bojan Marjanović	Senior Backend Engineer, Cells Infrastructure
David Leach	Site Reliability Engineer, Cells Infrastructure
Jen-Shin Lin	Senior Backend Engineer, Cells Infrastructure
Sangwoo Han	Backend Engineer, Cells Infrastructure
Tarun Khandelwal	Site Reliability Engineer, Cells Infrastructure
Tomasz Skorupa	Senior Backend Engineer, Cells Infrastructure
Vladimir Glafirov	Senior Site Reliability Engineer, Cells Infrastructure

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.

gitlab-org issues	gitlab-com/gl-infra issues
~“workflow::refinement”	~“workflow-infra::Triage”
~“workflow::ready for development”	~“workflow-infra::Ready”
~“workflow::in dev”	~“workflow-infra::In Progress”
~“workflow::in review”	~“workflow-infra::Under Review”
~“workflow::blocked”	~“workflow-infra::Blocked”
~“workflow::verification”	~“workflow-infra::Verify”
~“workflow::complete”	~“workflow-infra::Done”

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.

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