The Plan team works on the backend part of GitLab for the Plan stage. Among other things, this means working on GitLab's issue tracker, portfolio management features, integration with external trackers, Markdown rendering, and email notifications.
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.
| Person | Role |
|---|---|
| Sean McGivern | Engineering Manager, Plan |
| Felipe Artur | Backend Engineer, Plan |
| Jarka Košanová | Backend Engineer, Plan |
| Brett Walker | Senior Backend Engineer, Plan |
| Jan Provaznik | Senior Backend Engineer, Plan |
| Mario de la Ossa | Backend Engineer, Plan |
| Patrick Derichs | Backend Engineer, Plan |
| Heinrich Lee Yu | Backend Engineer, Plan |
| Alexandru Croitor | Backend Engineer, Plan |
| Charlie Ablett | Senior Backend Engineer, Plan |
| Eugenia Grieff | Backend Engineer, Plan |
| Person | Role |
|---|---|
| Annabel Dunstone Gray | Product Designer, Plan |
| Donald Cook | Frontend Engineering Manager, Plan |
| Fatih Acet | Senior Frontend Engineer, Plan |
| Kushal Pandya | Senior Frontend Engineer, Plan & Geo |
| Winnie Hellmann | Senior Frontend Engineer, Plan and Intern Backend Engineer, Plan |
| Amarbayar Amarsanaa | Senior Site Reliability Engineer, Create, Plan, Monitor |
| Rajat Jain | Frontend Engineer, Plan |
| Martin Hanzel | Frontend Engineer, Plan |
| Walmyr Lima e Silva Filho | Senior Test Automation Engineer, Plan |
| Michal Wasilewski | Site Reliability Engineer, Create & Plan |
| Alexis Ginsberg | Senior Product Designer, Plan |
| Gabe Weaver | Senior Product Manager, Plan |
| New Vacancy - Eric Brinkman (Interim) | Senior Product Manager, Plan:Enterprise Planning |
| New Vacancy - Eric Brinkman (Interim) | Senior (or Intermediate) Product Manager, Plan:Certify |
| J.H. | Engineering Manager, Plan |
| Russell Dickenson | Senior Technical Writer, Plan |
This chart shows the progress we're making on hiring. Check out our jobs page for current openings.
In general, we use the standard GitLab engineering workflow. To get in touch with the Plan team, it's best to create an issue in the relevant project (typically GitLab CE) and add the ~Plan 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 #g_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 |
| 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.
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. To weight issues, they should:
The rotation for upcoming releases is:
| Release | Weights due | Engineer | Engineer |
|---|---|---|---|
| 12.3 | 2019-08-07 | Felipe Cardozo | Heinrich Lee Yu |
| 12.4 | 2019-09-07 | Charlie Ablett | Mario de la Ossa |
| 12.5 | 2019-10-07 | Brett Walker | Alexandru Croitor |
The Plan backend board always shows work in the current release, with the left column being items that are:
It's OK to not take the top item if you are not confident you can solve it, but please post in #g_plan if that's the case, as this probably means the issue should be better specified.
Most of our team meetings are recorded and publicly available on Youtube in the Plan team playlist.
The Plan team conducts monthly retrospectives in GitLab issues. These include the backend team, plus any people from frontend, UX, and PM who have worked with that team during the release being retrospected.
These are confidential during the initial discussion, then made public in time for each month's GitLab retrospective. For more information, see team retrospectives.
The retrospective issue is created by a scheduled pipeline in the async-retrospectives project. For more information on how it works, see that project's README.
Our Group Conversations are public, published through GitLab Pages. For more information, see the Group Conversations handbook page. These are shared with the rest of the Plan stage group.
The source repository for these updates is group-conversations. The README contains more information on how they are built.
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:
