This document explains the workflow for anyone working with issues in GitLab Inc. For the workflow that applies to everyone please see PROCESS.md.
Table of contents
For larger issues or issues that contain many different moving parts, you'll be likely working in a team. This team will typically consist of a backend developer, a frontend developer, a UX designer and a product manager.
Start working on things with the highest priority in the current milestone. The priority of items are defined under labels in the repository, but you are able to sort by priority.
After sorting by priority, choose something that you’re able to tackle and falls under your responsibility. That means that if you’re a frontend developer, you work on something with the label
To filter very precisely, you could filter all issues for:
Use this link to quickly set the above parameters. You'll still need to filter by the label for your own team.
If you’re in doubt about what to work on, ask your lead. They will be able to tell you.
To allow for asynchronous issue handling, we use milestones and labels. Leads and product managers handle most of the scheduling into milestones. Labelling is a task for everyone.
Most issues will have labels for at least one of the following:
container registry, etc.)
If you come across an issue that has none of these, you can always add the team and type, and often also the subject.
All labels, their meaning and priority are defined on the labels page.
Team labels specify what team is responsible for this issue. Assigning a team label makes sure issues get the attention of the appropriate people.
The current team labels are
Release. The descriptions on the labels page explain what falls under the responsibility of each team.
Team labels are always colored aqua, and are capitalized so that they show up as the first label for any issue.
container registry, etc.)
Subject labels are labels that define what area or feature of GitLab this issue hits. They are not always necessary, but very convenient. If you are an expert in a particular area, it makes it easier to find issues to work on.
Examples of subject labels are
Subject labels are always colored blue and all-lowercase.
Type labels are very important. They define what kind of issue this is. Every issue should have one or more. Examples of types are:
Examples of type labels are
A number of type labels have a priority assigned to them, which automatically makes them float to the top, depending on their importance.
Type labels are always lowercase, but can have any color, besides blue (which is already reserved for subject labels). The descriptions on the labels page explain what falls under each type label.
To manually assign priority to specific features, there are labels such as
P3. These are assigned by leads and product to indicate overruling priority, and are to be used carefully.
Right now, these are in use:
P1: Critical. Above all, this should be worked on this milestone. Reserved for only a handful of issues.
P2: Must. Must be finished this milestone
P3: Should. Should be finished this milestone.
All other issues are nice to land in a milestone, but not necessarily expected to do so. They will be naturally ordered by the prioritized type labels. This prevents ‘nice to have’ features from being prioritised over fixing bugs, which might be less fun, but is often more important.
GitLab Inc has to be selective in working on particular issues. We have a limited capacity to work on new things. Therefore, we have to schedule issues carefully. This is done primarily by product and engineering managers.
Each issue that is scheduled should meet most of these criteria:
Direction issues are the big, prioritized new features for each release. They are limited to a small number per release so that we have plenty of capacity to work on other important issues, bug fixes, etc.
Issues that are not scheduled for a future milestone, but we are committed to doing, are put in the Backlog milestone.
Issues that are beneficial to our users, 'nice to haves', that we currently don't have the capacity for or want to give the priority to, are not scheduled. These issues are labeled as accepting merge requests, so the community can make a contribution.
Any scheduled issue should have a team label assigned, and at least one type label.
Only fleshed-out issues can be scheduled. If an issue is vague or has unclear requirements, we can not schedule it.
To request a scheduling of an issue, ask the responsible lead. You can find the leads on the team page, and in the descriptions of the team labels. For (major) feature requests, ask the relevant product manager. Right now this is either Mark (for CI) or Job.
We have much more requests for great features than we have capacity to work on. There is a good chance we’ll not be able to work on something. Make sure the appropriate labels (such as
customer) are applied so every issue is given the priority it deserves.
There is an informal scheduling committee that has a weekly meeting that discusses issues around scheduling and how the process of scheduling issues can be improved. Actual scheduling, prioritization and others has to happen on GitLab.com and nowhere else.
The meeting is open to anyone wanting to join. Ask in #scheduling to be added.