-
Sean McGivern authoredSean McGivern authored
Contributor license agreement
By submitting code as an individual you agree to the individual contributor license agreement. By submitting code as an entity you agree to the corporate contributor license agreement.
This notice should stay as the first item in the CONTRIBUTING.MD file.
Table of Contents generated with DocToc
- Contribute to GitLab
- Security vulnerability disclosure
- Closing policy for issues and merge requests
- Helping others
- I want to contribute!
- Workflow labels
- Implement design & UI elements
- Issue tracker
- Merge requests
- Definition of done
- Style guides
- Code of conduct
Contribute to GitLab
Thank you for your interest in contributing to GitLab. This guide details how to contribute to GitLab in a way that is efficient for everyone.
GitLab comes into two flavors, GitLab Community Edition (CE) our free and open source edition, and GitLab Enterprise Edition (EE) which is our commercial edition. Throughout this guide you will see references to CE and EE for abbreviation.
If you have read this guide and want to know how the GitLab core team operates please see the GitLab contributing process.
Security vulnerability disclosure
Please report suspected security vulnerabilities in private to
support@gitlab.com, also see the
disclosure section on the GitLab.com website.
Please do NOT create publicly viewable issues for suspected security
vulnerabilities.
Closing policy for issues and merge requests
GitLab is a popular open source project and the capacity to deal with issues and merge requests is limited. Out of respect for our volunteers, issues and merge requests not in line with the guidelines listed in this document may be closed without notice.
Please treat our volunteers with courtesy and respect, it will go a long way towards getting your issue resolved.
Issues and merge requests should be in English and contain appropriate language for audiences of all ages.
If a contributor is no longer actively working on a submitted merge request we can decide that the merge request will be finished by one of our Merge request coaches or close the merge request. We make this decision based on how important the change is for our product vision. If a Merge request coach is going to finish the merge request we assign the ~"coach will finish" label.
Helping others
Please help other GitLab users when you can. The channels people will reach out on can be found on the getting help page.
Sign up for the mailing list, answer GitLab questions on StackOverflow or respond in the IRC channel. You can also sign up on CodeTriage to help with the remaining issues on the GitHub issue tracker.
I want to contribute!
If you want to contribute to GitLab, but are not sure where to start,
look for issues with the label Accepting Merge Requests and weight < 5.
These issues will be of reasonable size and challenge, for anyone to start
contributing to GitLab.
Workflow labels
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:
- Type: ~"feature proposal", ~bug, ~customer, etc.
- Subject: ~wiki, ~"container registry", ~ldap, ~api, etc.
- Team: ~CI, ~Discussion, ~Edge, ~Frontend, ~Platform, etc.
- Priority: ~Deliverable, ~Stretch
All labels, their meaning and priority are defined on the labels page.
If you come across an issue that has none of these, and you're allowed to set labels, you can always add the team and type, and often also the subject.
Type labels (~"feature proposal", ~bug, ~customer, etc.)
Type labels are very important. They define what kind of issue this is. Every issue should have one or more.
Examples of type labels are ~"feature proposal", ~bug, ~customer, ~security, and ~"direction".
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, and 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.
Subject labels (~wiki, ~"container registry", ~ldap, ~api, 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. You can also subscribe to those labels to receive an email each time an issue is labelled with a subject label corresponding to your expertise.
Examples of subject labels are ~wiki, ~"container registry", ~ldap, ~api, ~issues, ~"merge requests", ~labels, and ~"container registry".
Subject labels are always all-lowercase.
Team labels (~CI, ~Discussion, ~Edge, ~Platform, etc.)
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 ~Build, ~CI, ~Discussion, ~Documentation, ~Edge, ~Gitaly, ~Platform, ~Prometheus, ~Release, and ~"UX".
The descriptions on the labels page explain what falls under the responsibility of each team.
Within those team labels, we also have the ~backend and ~frontend labels to indicate if an issue needs backend work, frontend work, or both.
Team labels are always capitalized so that they show up as the first label for any issue.
Priority labels (~Deliverable and ~Stretch)
Priority labels help us clearly communicate expectations of the work for the release. There are two levels of priority labels:
- ~Deliverable: Issues that are expected to be delivered in the current milestone.
- ~Stretch: Issues that are a stretch goal for delivering in the current milestone. If these issues are not done in the current release, they will strongly be considered for the next release.