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
Nick NguyenNick Nguyen Senior Engineering Manager, Tenant Scale/a>
Aaron RichterAaron Richter Site Reliability Engineer, Cells Infrastructure
Bojan MarjanovićBojan Marjanović Senior Backend Engineer, Cells Infrastructure
David LeachDavid Leach Site Reliability Engineer, Cells Infrastructure
Jen-Shin LinJen-Shin Lin Senior Backend Engineer, Cells Infrastructure
Omar QunsulOmar Qunsul Senior Backend Engineer, Cells Infrastructure
Sangwoo HanSangwoo Han Backend Engineer, Cells Infrastructure
Vladimir GlafirovVladimir Glafirov Senior Site Reliability Engineer, Cells Infrastructure

How We Work

Project Management

Issue Tracking

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.

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”

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::blocked.

Weekly Review

Each week the EM will schedule time to review the issue boards and team members can optionally attend. 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