PROCESS.md

GitLab Contributing Process

Purpose of describing the contributing process

Below we describe the contributing process to GitLab for two reasons. So that contributors know what to expect from maintainers (possible responses, friendly treatment, etc.). And so that maintainers know what to expect from contributors (use the latest version, ensure that the issue is addressed, friendly treatment, etc.).

• GitLab Inc engineers should refer to the engineering workflow document

Common actions

Issue team

• Looks for issues without workflow labels and triages issue
• Closes invalid issues with a comment (duplicates, fixed in newer version, issue report for old version, not a problem in GitLab, etc.)
• Asks for feedback from issue reporter (invalid issue reports, format code, etc.)
• Monitors all issues for feedback (but especially ones commented on since automatically watching them)
• Closes issues with no feedback from the reporter for two weeks

Merge marshall & merge request coach

• Responds to merge requests the issue team mentions them in and monitors for new merge requests
• Provides feedback to the merge request submitter to improve the merge request (style, tests, etc.)
• Mark merge requests Ready for Merge when they meet the contribution acceptance criteria
• Mention developer(s) based on the list of members and their specialities
• Closes merge requests with no feedback from the reporter for two weeks

Priorities of the issue team

1. Mentioning people (critical)
2. Workflow labels (normal)
3. Functional labels (minor)
4. Assigning issues (avoid if possible)

Mentioning people

The most important thing is making sure valid issues receive feedback from the development team. Therefore the priority is mentioning developers that can help on those issues. Please select someone with relevant experience from GitLab core team. If there is nobody mentioned with that expertise look in the commit history for the affected files to find someone. Avoid mentioning the lead developer, this is the person that is least likely to give a timely response. If the involvement of the lead developer is needed the other core team members will mention this person.

Workflow labels

Workflow labels are purposely not very detailed since that would be hard to keep updated as you would need to re-evaluate them after every comment. We optionally use functional labels on demand when we want to group related issues to get an overview (for example all issues related to RVM, to tackle them in one go) and to add details to the issue.

• ~"Awaiting Feedback" Feedback pending from the reporter
• ~UX needs help from a UX designer
• ~Frontend needs help from a Front-end engineer. Please follow the "Implement design & UI elements" guidelines.
• ~up-for-grabs is an issue suitable for first-time contributors, of reasonable difficulty and size. Not exclusive with other labels.
• ~"feature proposal" is a proposal for a new feature for GitLab. People are encouraged to vote in support or comment for further detail. Do not use feature request.
• ~bug is an issue reporting undesirable or incorrect behavior.
• ~customer is an issue reported by enterprise subscribers. This label should be accompanied by bug or feature proposal labels.

Example workflow: when a UX designer provided a design but it needs frontend work they remove the UX label and add the frontend label.

Functional labels

These labels describe what development specialities are involved such as: CI, Core, Documentation, Frontend, Issues, Merge Requests, Omnibus, Release, Repository, UX.

Assigning issues