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 Cook	Engineering Manager, Plan:Project Management
Alexandru Croitor	Senior Backend Engineer, Plan:Project Management
Senior Frontend Engineer	Senior Frontend Engineer, Plan:Project Management
Deepika Guliani	Senior Frontend Engineer, Plan:Project Management
Fernanda Toledo	Frontend Engineer, Plan:Project Management
Heinrich Lee Yu	Staff Backend Engineer, Plan:Project Management
Mario Celi	Senior Backend Engineer, Plan:Project Management
Marc Saleiko	Senior Fullstack Engineer, Plan:Project Management
Simon Knox	Staff Frontend Engineer, Plan:Project Management
Stefanos Xanthopoulos	Backend Engineer

Stable counterparts

Name	Role
Costel 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 Weaver	Senior Product Manager, Plan:Project Management
Melissa Ushakov	Group Manager, Product Management, Plan
John Hope	Senior Manager, Engineering, Plan
Nick Leonard	Senior Product Designer, Plan:Project Management
Natalia Tepluhina	Principal Engineer, Plan
Ottilia Westerlund	Security Engineer, Fulfillment (Fulfillment Platform, Subscription Management), Security Risk Management (Security Policies, Threat Insights), Monitor (Observability), Plan (Product Planning), AI-powered (Duo Chat, Duo Workflow, AI Framework, AI model validation, Custom models)
Matthew 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 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) 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

Estimating effort

When estimating the effort involved in upcoming work, we use the same approach and numerical scale as other groups in the Plan stage.

When weighting an issue for a milestone, we use a lightweight, relative estimation approach, recognizing that tasks often take longer than you think. These weights are primarily used for capacity planning, ensuring that the total estimated effort aligns with each group’s capacity for a milestone.

Key Principles

Relative Estimation: We focus on the relative complexity and effort required for each issue rather than precise time estimates.
Aggregate Focus: The sum of all issue weights should be reasonable for the milestone, even if individual issues vary in actual time taken.
Flexibility: It’s acceptable for an issue to take more or less time than its weight suggests. Variations are expected due to differences in individual expertise and familiarity with the work.

Weight Definitions

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

Initial Planning: During milestone planning, tasks can be estimated up to a weight of 5 if necessary. However, as the milestone approaches and the team moves closer to starting implementation, any task with a weight larger than 3 should be decomposed into smaller, more manageable issues or tasks with lower weights.

Why This Approach: Allowing larger weights early on provides flexibility in high-level planning. Breaking down tasks closer to implementation ensures better clarity, reduces risk, and facilitates more accurate tracking and execution.

We assess the available capacity for a milestone by reviewing recent milestones and upcoming team availability. This ensures that our milestone planning remains realistic and achievable based on the collective effort estimated through these weights.

Weighing bugs

Estimating bugs is inherently difficult. The majority of the effort in fixing bugs is finding the cause, and then a bug can 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), 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

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 shows prioritized work 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.

Queueing Experimentation

As part of our ongoing efforts to improve efficiency, we will experiment with queuing techniques instead of traditional weight/story points for the migration of legacy issues to work items project. Starting in milestone 17.3, we will:

Refine Required Issues: Review the list of required issues for the first MVC.
- Determine the best way to group bundles of tasks, using issues or epics.
- Break down large issues into tasks, aiming for tasks that are small enough to be moved from ~“workflow::in dev” to ~“workflow::in review” within 5 business days.
Prioritize Tasks: Prioritize the tasks from step 1.
Update Workflow: Update the #picking-something-to-work-on section to include the list of tasks, monitoring work in progress to keep it as low as possible.

This will help us manage and report progress more effectively using queue management principles.

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:

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

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

Dashboards

Useful links

Plan:Project Management Build board - this shows work in the current release
#s_plan in Slack
Recorded meetings
Retrospectives
Group Conversations (archive; group conversations now happen at a the section level)

Last modified November 14, 2024: Fix broken external links (ac0e3d5e)

View page source - Edit this page - please contribute.