Plan:Project Management Team

Plan:Project Management Team

The Plan:Project Management team works on GitLab’s Project Management category in the Plan stage.

For more details about the vision for this area of the product, see the Plan stage page.

Team members

Name Role
Donald CookDonald Cook Engineering Manager, Plan:Project Management
Alexandru CroitorAlexandru Croitor Senior Backend Engineer, Plan:Project Management
Brett WalkerBrett Walker Senior Backend Engineer, Plan:Project Management
Senior Frontend EngineerSenior Frontend Engineer Senior Frontend Engineer, Plan:Project Management
Deepika GulianiDeepika Guliani Frontend Engineer, Plan:Project Management
Heinrich Lee YuHeinrich Lee Yu Staff Backend Engineer, Plan:Project Management
Mario CeliMario Celi Backend Engineer, Plan:Project Management
Simon KnoxSimon Knox Staff Frontend Engineer, Plan:Project Management

Stable counterparts

Name Role
Costel MaximCostel Maxim Senior Security Engineer, Application Security, Plan (Project Management, Product Planning, Certify), Create:Source Code, Growth, Fulfillment:Purchase, Fulfillment:Provision, Fulfillment:Utilization, Systems:Gitaly
Gabe WeaverGabe Weaver Senior Product Manager, Plan:Project Management
Melissa UshakovMelissa Ushakov Group Manager, Product Management, Plan
John HopeJohn Hope Senior Manager, Engineering, Plan
Natalia TepluhinaNatalia Tepluhina Principal Engineer, Plan
Ottilia WesterlundOttilia Westerlund Security Engineer, Fulfillment (Fulfillment Platform, Subscription Management), Govern (Security Policies, Threat Insights), Monitor (Observability), Plan (Product Planning), AI-powered:AI Framework
Matthew MacfarlaneMatthew Macfarlane Product Manager, Plan Stage, Knowledge Group

Hiring chart

Check out our jobs page for current openings.

Scalability Targets

We’re tracking a number of issues that we believe could cause scalability problems in the future.

Type Description Estimated Timeline for Failure Resolution Due Date 12 Month Target Issue Status
Primary key int4 overflow system_note_metadata.id column is at 50% saturation and must be converted to bigint (int8). March 2024 - 2025 2023-12-22 Sub-50% #424114 Urgent
Redis Primary CPU Unexpected load on the Shared State Redis instance caused by SUBSCRIBE, UNSUBSCRIBE and PUBLISH commands. Unknown November 2023 150k Concurrent WebSocket Connections at peak Okay
Redis Memory Retention of Action Cable messages in Redis Shared State memory due to high numbers of and/or stalled/hung clients. Unknown November 2023 150k Concurrent WebSocket Connections at peak #326364 Okay
Various Scaling a combined ‘Work Items’ table consisting of all current issues, epics, requirements and test cases. Unknown November 2023 [100k Work Items][workitems] created per day Okay

Note: Work is ongoing on migration helpers to mitigate Int4 Primary Key Overflows. These will provide a standard way to resolve these issues.

Work

You can see how we work as a stage at the Plan stage page.

For the backend team specifically, we use the standard GitLab engineering workflow. To get in touch with the Plan:Project Management backend team, it’s best to create an issue in the relevant project (typically GitLab CE) and add the ~“group::project management” label, along with any other appropriate labels. Then, feel free to ping the relevant Product Manager and/or Engineering Manager as listed above.

For more urgent items, feel free to use #s_plan on Slack.

Capacity planning

We use a lightweight system of issue weighting to help with capacity planning, with the knowledge that things take longer than you think. These weights are used for capacity planning and the main focus is on making sure the overall sum of the weights is reasonable.

It’s OK if an issue takes longer than the weight indicates. The weights are intended to be used in aggregate, and what takes one person a day might take another person a week, depending on their level of background knowledge about the issue. That’s explicitly OK and expected.

These weights we use are:

Weight Meaning
1 Trivial, does not need any testing
2 Small, needs some testing but nothing involved
3 Medium, will take some time and collaboration
4 Substantial, will take significant time and collaboration to finish
5 Large, will take a major portion of the milestone to finish

Anything larger than 5 should be broken down if possible.

We look at recent releases and upcoming availability to determine the weight available for a release.

Weighing bugs

Estimating bugs is inherently difficult. The majority of the effort in fixing bugs is finding the cause, and then a bug be accurately estimated. Additionally, velocity is used to measure the amount of new product output, and bug fixes are typically fixes on a feature that has been tracked and had a weight attached to it previously.

Because of this, we do not weigh bugs during ~“workflow::planning breakdown”. If an engineer picks up a bug and determines that there will be a significant level of effort in fixing it (for example, a large migration is needed, or we need to switch state management to Vuex on the frontend), we then will want to prioritize it against feature deliverables. Ping the product manager with this information so they can determine when the work should be scheduled.

Refining and organizing feature work

To help drive alignment with our stable counterparts, provide visibility into progress, and breakdown our vision into a series of MVCs, we collaborate with Product and UX during ~workflow::planning breakdown to refine and organize ~type::feature deliverables into the following structure:

  • Feature (Epic) - Contains all of the necessary vertical feature slices to default the corresponding feature flag to “on”. The feature epic will also serve as the location to generate a corresponding Release Post item MR. The feature epic should be scoped to the minimal amount of functionality that still provides customer value. Additional scope planned for future enhancements should be stored in follow-on epics.
    • Spike (Issue) - If we are unable to accurately estimate the effort necessary to implement the feature, we first conduct a spike
    • UX (Issue) - For larger initiatives, UX creates a separate UX issue that serves as the SSOT for design goals, design drafts, design conversation and critique, and the chosen design direction that will be implemented. Learn more about UX issues.
    • Vertical Feature Slice (Issue) - A subset of the feature that can be completed within a single milestone, tested, and verified within the plan-stage group on production.
      • Engineering Tasks (Task - Optional) - One or more engineering tasks that need to be completed in order to deliver the vertical feature slice. The scope of a task should generally correlate to a single MR.

During the ~workflow::planning breakdown phase, all issues need to be weighted so we can efficiently and effectively collaborate with Product and UX on “right sizing” the feature epic. It’s advisable that all issues are connected to a parent epic that describes the broader set of improvements we are proposing within a specific area of the product. The desired outcome is to ensure it’s as small as possible, maximizes our ability to iterate, and makes it easy to track overall progress on delivery, while providing meaningful value and avoiding an undue amount of “change fatigue” for our customers.

Spikes

There is a decent amount of complexity in the features that we as a team are responsible for, and we’re aiming to determine where the majority of risks involved in building a feature are prior to commitments being made and development starting. We are trying out a concept of a rotation of DRIs for spikes. Spikes will be a two week time period where one engineer DRI works exclusively on breaking down an issue/epic by asking questions to determine risk and complexity, creating proof of concepts, and writing up iteration plans for implementation.

The DRI will not be expected to produce MRs during the period they are on rotation, but instead, will be expected to produce issue artifacts at the end of the period, so that a first iteration can be worked on in the following milestone (either by the DRI or other engineers).

By the end of the spike, there should be documented acceptance criteria for a first iteration, that the internal parties (spike DRI, PM, UX, and EM) have all agreed to.

DRI rotation:

DRI Start date End date Spike
Alexandru Croitor 2023-01-23 2023-02-03 Moving work items
Simon Knox 2023-02-06 2023-02-17 Frontend of work items at the group level
Heinrich Lee Yu 2023-02-20 2023-03-03 Group by work items
Coung Ngo 2023-03-13 2023-03-24 Group by work items ~frontend focused
Mario Celi 2023-03-27 2023-04-07
Deepika Guliana 2023-04-10 2023-04-21
Eulyeon Ko 2023-04-24 2023-05-05

Historical Capacity

Points of weight delivered by the team in previous milestones, including a 3-month rolling average, are available in this chart. This allows for more accurate estimation of what we can deliver in future milestones.

Collaboration between backend and frontend

Using the ~“backend complete” label

The ~“backend complete” label is added to issues with multiple specializations (usually backend and frontend) to indicate that the backend component is complete. Add this label when the backend work is functionally complete, merged and verified but frontend, or other, work is ongoing.

Picking something to work on

The Plan:Project Management Build board always shows work in the current release, with workflow columns relevant to implementation. There is an additional column to show in-progress community contributions. Filtering it by ~backend shows issues for backend engineers to work on.

It’s OK to not take the top item if you are not confident you can solve it, but please post in #s_plan if that’s the case, as this probably means the issue should be better specified.

High Severity Issues

When an issue comes through that is both ~“severity::1” and ~“priority::1”, our SLO requires that it be looked at right away. Other items being worked on should be postponed in favor of any investigations or work for the high severity/priority issue. When postponing an issue, engineers should leave a comment on the issue with a link to the high severity item that is being prioritized instead. Leaving a comment will help with communication with the cross-functional team and for historical tracking. The exception to this is if another ~“severity::1”/~“priority::1” issue is currently being worked on by an engineer. If this is the case, the engineer should make others on the team aware of the new issue on Slack but then keep working on the initial issue.

Working on unscheduled issues

Everyone at GitLab has the freedom to manage their work as they see fit, because we measure results, not hours. Part of this is the opportunity to work on items that aren’t scheduled as part of the regular monthly release. This is mostly a reiteration of items elsewhere in the handbook, and it is here to make those explicit:

  1. We expect people to be managers of one, and we use GitLab ourselves. If you see something that you think is important, you can request for it to be scheduled, or you can work on a proposal yourself, as long as you keep your other tasks in mind.
  2. From time to time, there are events that GitLab team-members can participate in, like the issue bash. Anyone is welcome to participate in these.
  3. If you feel like you want to have some specific time set aside, but aren’t interested in the topics of an existing event, feel free to label issues with “For Scheduling” and copy your manager for visibility.

When you pick something to work on, please:

  1. Follow the standard workflow and assign it to yourself.
  2. Share it in #s_plan - if not even more widely (like in #development or #backend).

Dashboards

Last modified March 5, 2024: remove sisense references from dev pages (9ac41eaa)
View page source - Edit this page - please contribute. Creative Commons License