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, integration with external trackers, Markdown rendering, Elasticsearch integration, and email notifications.
For more details about the vision for this area of the product, see the Plan stage page.
|Sean McGivern||Engineering Manager, Plan|
|Felipe Artur||Backend Engineer, Plan|
|Jarka Kadlecová||Backend Engineer, Plan|
|Brett Walker||Senior Backend Engineer, Plan|
|Jan Provaznik||Senior Backend Engineer, Plan|
|Mario de la Ossa||Backend Engineer, Plan|
|Chantal Rollison||Junior Backend Engineer, Plan|
|Annabel Dunstone Gray||UX Designer, Plan|
|André Luís||Interim Frontend Engineering Manager, Create & Plan|
|Fatih Acet||Senior Frontend Engineer, Plan|
|Pedro Moreira da Silva||Senior UX Designer, Plan|
|Kushal Pandya||Frontend Engineer, Plan|
|Victor Wu||Product Manager, Plan|
|Winnie Hellmann||Frontend Engineer, Plan|
|Constance Okoghenun||Frontend Engineer, Plan|
|Ramya Authappan||Senior Test Automation Engineer, Plan|
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.
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.
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.
The source repository for these updates is group-conversations. The README contains more information on how they are built.
The due-22nd label indicates issues that have a soft due-date of the 22nd of the month (two weeks after the kick-off on the 8th), as opposed to other issues which can be completed at any time during the month. We are still evaluating this label and its usage, but we hope to:
We are tracking its success, or otherwise, in a retrospective follow-up 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: