For more details about the vision for this area of the product, see the Plan stage page.
From an engineering perspective, we are also responsible for the code backing our GraphQL API. This does not mean we own everything about the API - each team is responsible for implementing its own resources in GraphQL - but we are responsible for the overall stewardship of this API.
|New Vacancy - John Hope (Acting)||Engineering Manager, Plan:Project Management|
|Brett Walker||Senior Backend Engineer, Plan:Project Management|
|Mario de la Ossa||Backend Engineer, Plan:Project Management|
|Patrick Derichs||Backend Engineer, Plan:Project Management|
|Heinrich Lee Yu||Senior Backend Engineer, Plan:Project Management|
|Alexandru Croitor||Backend Engineer, Plan:Project Management|
|Eugenia Grieff||Backend Engineer, Plan:Project Management|
|Donald Cook||Frontend Engineering Manager, Plan|
|Simon Knox||Frontend Engineer, Plan:Project Management|
|Justin Farris||Group Manager, Product, Plan|
|Scott Stern||Frontend Engineer, Plan:Project Management|
|Coung Ngo||Frontend Engineer, Plan:Project Management|
|Walmyr Lima e Silva Filho||Senior Software Engineer in Test, Plan:Project Management (primary) & Plan:Portfolio Management (secondary)|
|Holly Reynolds||Senior Product Designer, Plan:Project Management|
|Gabe Weaver||Senior Product Manager, Plan:Project Management|
|Marcin Sędłak-Jakubowski||Technical Writer, Plan|
This chart shows the progress we're making on hiring. Check out our jobs page for current openings.
The following Plan:Project Management BE Team vacancies are overdue to be filled. They are counted toward today on the chart above.
|Engineering Manager, Plan:Project Management||2020-01-01|
We have a metrics dashboard for the Plan:Project Management backend team. This is intended to track against some of the Development Department KPIs, particularly those around merge request creation and acceptance. Below is a single metric from that dashboard: MR Rate, scoped to this team.
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:
|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're discussing a possible change to the weight scale we use.
We look at recent releases and upcoming availability to determine the weight available for a release.
To assign weights to issues in a future milestone, we ask two team members to take the lead each month. They can still ask questions - of each other, of the rest of the team, of the stable counterparts, or anyone else - but they are the initial. This is currently shared across the three Plan backend teams: Project Management, Portfolio Management, and Certify, so people will be asked to weight some issues outside of their immediate team.
To weight issues, they should:
The rotation for upcoming releases is:
|12.8||2020-01-13||Felipe Cardozo||Mario de la Ossa|
|12.9||2020-02-13||Charlie Ablett||Heinrich Lee Yu|
|12.10||2020-03-13||Jarka Košanová||Alexandru Croitor|
|12.11||2020-04-13||Jan Provaznik||Brett Walker|
|13.0||2020-05-13||Felipe Cardozo||Patrick Derichs|
|13.1||2020-06-13||Charlie Ablett||Eugenia Grieff|
Points of weight delivered by the team on the last three milestones, including rolling average. This allows for more accurate estimation of what we can deliver in future milestones. Full chart here.
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.
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: