This document explains the workflow for anyone working with issues in GitLab Inc. For the workflow that applies to everyone please see PROCESS.md.
Products at GitLab are built using the GitLab Flow.
If you notice that the tests for the
master branch of GitLab CE or EE are failing (red) or broken (green as a false positive), fixing this takes priority over everything else development related, since everything we do while tests are broken may break existing functionality, or introduce new bugs and security issues.
Create an issue, post about it in
#development so that other developers are aware of the problem and can help. If the problem cannot be fixed by you within a few hours,
@mention the relevant Engineering Leads and CTO in the issue and on Slack, so that resources can be assigned to fix it as quickly as possible.
If you find or are alerted of a security issue, major or small, fixing this takes priority over everything else development related.
Create a confidential issue mentioning the Security and the relevant Engineering Leads, as well as the VP of Engineering, and post about it in
For general guidelines about issues and merge requests, be sure to read the GitLab Workflow.
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.
Labels are described in our Contribution guide.
GitLab.com is a very large instance of GitLab Enterprise Edition. It runs release candidates for new releases, and sees a lot of issues because of the amount of traffic it gets. There are several internal tools available for developers at GitLab to get data about what's happening in the production system:
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.
If you want to schedule an
Accepting Merge Requests issue, please remove the label first.
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.
Engineering and product schedule (establish scope of) which issues are to be worked on in the following milestone. In particular:
There is an informal scheduling process discussion in the #scheduling Slack channel. Anyone can join and suggest improvements to our scheduling process.