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.
| Person | Role |
|---|---|
| Donald Cook | Engineering Manager, Plan:Project Management |
| Alexandru Croitor | Senior Backend Engineer, Plan:Project Management |
| Brett Walker | Senior Backend Engineer, Plan:Project Management |
| Coung Ngo | Senior Frontend Engineer, Plan:Project Management |
| Deepika Guliani | Frontend Engineer, Plan:Project Management |
| Eulyeon K. | Backend Engineer, Plan:Project Management |
| Heinrich Lee Yu | Staff Backend Engineer, Plan:Project Management |
| Mario Celi | Backend Engineer, Plan:Project Management |
| Simon Knox | Senior Frontend Engineer, Plan:Project Management |
| Person | Role |
|---|---|
| Gabe Weaver | Senior Product Manager, Plan:Project Management |
| Matthew Macfarlane | Product Manager, Plan Stage, Knowledge Group |
| 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 |
| Désirée Chevalier | Senior Software Engineer in Test, Plan:Project Management |
| John Hope | Senior Manager, Engineering, Plan |
| Natalia Tepluhina | Principal Engineer, Plan |
| Melissa Ushakov | Group Manager, Product Management, Plan and Ecosystem |
Check out our jobs page for current openings.
We have a metrics dashboard intended to track against some of the Development Department KPIs, particularly those around merge request creation and acceptance. From that dashboard, the following charts shows MR Rate.
The following chart shows the MR Rate of the Dev section as a whole, for the identification of trends:
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 |
|---|---|---|---|---|---|---|
| Int4 Primary Key Overflow | Primary key overflow in the notes table. |
April 2023 | April 2022 | Creation of 1m Notes per Day | Attention | |
| Redis Primary CPU | Unexpected load on the Shared State Redis instance caused by SUBSCRIBE, UNSUBSCRIBE and PUBLISH commands. |
Unknown | April 2022 | 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 | April 2022 | 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 | April 2022 | 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.
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.
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.
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.
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 |
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.
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.
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.
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.
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:
When you pick something to work on, please:
(Sisense↗) We also track our backlog of issues, including past due security and infradev issues, and total open System Usability Scale (SUS) impacting issues and bugs.
(Sisense↗) MR Type labels help us report what we're working on to industry analysts in a way that's consistent across the engineering department. The dashboard below shows the trend of MR Types over time and a list of merged MRs.
(Sisense↗) Flaky test are problematic for many reasons.
