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