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.).

Common actions

Issue team

Looks for issues without workflow labels and triages issue
Monitors pull requests
Closes invalid issues and pull requests with a comment (duplicates, feature requests, fixed in newer version, issue report for old version, not a problem in GitLab, etc.)
Assigns appropriate labels

Asks for feedback from issue reporter/pull request initiator (invalid issue reports, format code, etc.)
Asks for feedback from the relevant developer(s) based on the list of members and their specialities

Monitors all issues/pull requests for feedback (but especially ones commented on since automatically watching them):
Closes issues with no feedback from the reporter for two weeks
Closes stale pull requests


Development team

Responds to issues and pull requests the issue team mentions them in
Monitors for new issues in Awaiting developer action/feedback with no developer activity (once a week)
Monitors for new pull requests (at least once a week)
Manages their work queue by looking at issues and pull requests assigned to them
Close fixed issues (via commit messages or manually)
Codes new features!
Response guidelines
Be kind to people trying to contribute. Be aware that people can be a non-native or a native English speaker, they might not understand thing or they might be very sensitive to how your word things. Use emoji to express your feelings (heart, star, smile, etc.). Some good tips about giving feedback to pull requests is in the Thoughtbot code review guide.


Priorities of the issue team

Mentioning people (critical)
Workflow labels (normal)
Functional labels (minor)
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 issue. 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 reevaluate them after every comment. We optionally use functional labels on demand when 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

Awaiting confirmation of fix: The issue should already be solved in master (generally you can avoid this workflow item and just close the issue right away)

Attached PR: There is a PR attached and the discussion should happen there

We need to let issues stay in sync with the PR's. We can do this with a "Closing #XXXX" or "Fixes #XXXX" comment in the PR. We can't close the issue when there is a pull request because sometimes a PR is not good and we just close the PR, then the issue must stay.


Awaiting developer action/feedback: Issue needs to be fixed or clarified by a developer


Functional labels
These labels describe what development specialities are involved such as: PostgreSQL, UX, LDAP.

Assigning issues
If an issue is complex and needs the attention of a specific person, assignment is a good option but assigning issues might discourage other people from contributing to that issue. We need all the contributions we can get so this should never be discouraged. Also, an assigned person might not have time for a few weeks, so others should feel free to takeover.

Label colors