Skip to content
Snippets Groups Projects
Select Git revision
  • move-gl-dropdown
  • improve-table-pagination-spec
  • move-markdown-preview
  • winh-fix-merge-request-spec
  • master default
  • index-namespaces-lower-name
  • winh-single-karma-test
  • 10-3-stable
  • 36782-replace-team-user-role-with-add_role-user-in-specs
  • winh-modal-internal-state
  • tz-ide-file-icons
  • 38869-milestone-select
  • update-autodevops-template
  • jivl-activate-repo-cookie-preferences
  • qa-add-deploy-key
  • docs-move-article-ldap
  • 40780-choose-file
  • 22643-manual-job-page
  • refactor-cluster-show-page-conservative
  • dm-sidekiq-versioning
  • v10.4.0.pre
  • v10.3.0
  • v10.3.0-rc5
  • v10.3.0-rc4
  • v10.3.0-rc3
  • v10.3.0-rc2
  • v10.2.5
  • v10.3.0-rc1
  • v10.0.7
  • v10.1.5
  • v10.2.4
  • v10.2.3
  • v10.2.2
  • v10.2.1
  • v10.3.0.pre
  • v10.2.0
  • v10.2.0-rc4
  • v10.2.0-rc3
  • v10.1.4
  • v10.2.0-rc2
40 results

CONTRIBUTING.md

Blame Permalink
Forked from GitLab.org / GitLab FOSS
412 commits behind the upstream repository.
After you've reviewed these contribution guidelines, you'll be all set to contribute to this project.
CONTRIBUTING.md 32.39 KiB

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

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