Plan Team

On this page

Plan Team

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.

Team members

Person Role
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

Stable counterparts

Person Role
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

Work

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.

Picking something to work on

The Plan backend board always shows work in the current release, with the left column being items that are:

  1. In priority order, with priorities set from the Product Manager.
  2. Not assigned to anyone in the Plan backend team. (They may be assigned to people from other teams; for instance, if an issue needs backend, frontend, and UX work, then the frontend and UX parts may already be assigned.)

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.

Team meetings

Most of our team meetings are recorded and publicly available on Youtube in the Plan team playlist.

Retrospectives

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.

Group Conversations

Our Group Conversations are public, published through GitLab Pages. For more information, see the Group Conversations handbook page.

The source repository for these updates is group-conversations. The README contains more information on how they are built.

The due-22nd Label

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:

  1. Help Product communicate priority outside boards, in a more granular way than the existing Deliverable and Stretch labels.
  2. Force ourselves to ensure issues are scoped down appropriately.
  3. Give everyone a clearer sense of the state of the milestone; if all of the due-22nd issues are still open on the 24th, for instance, then we are probably at risk of other issues slipping.

We are tracking its success, or otherwise, in a retrospective follow-up 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:

  1. 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.
  2. From time to time, there are events that GitLabbers can participate in, like the issue bash and content hack days. Anyone is welcome to participate in these.
  3. 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 treat the third Friday of the month as an open work day, as in the Distribution team's open work day model.

When you pick something to work on, please:

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