We want to make it as easy as possible for GitLab users to become GitLab contributors, so we’ve created this guide to help you get started. We have multiple tracks to cater to people of varying experience levels.

If you’re uncomfortable getting into open source development right away, you may want to consider the Documentation or Translation tracks. Documentation and Translation are both just as important as code, and we'd be happy to have your contributions.

Code of Conduct

As contributors and maintainers of this project, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.

We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, or religion.

Examples of unacceptable behavior by participants include the use of sexual language or imagery, derogatory comments or personal attacks, trolling, public or private harassment, insults, or other unprofessional conduct.

Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct. Project maintainers who do not follow the Code of Conduct may be removed from the project team.

This code of conduct applies both within project spaces and in public spaces when an individual is representing the project or its community.

Instances of abusive, harassing, or otherwise unacceptable behavior can be reported by emailing

This Code of Conduct is adapted from the Contributor Covenant version 1.1.0, available at


These instructions are for development of GitLab Community Edition specifically. Please note that use of the GitLab Development Kit is currently experimental on Windows. macOS or Linux are recommended for the best contribution experience.

  1. Download and setup the GitLab Development Kit, see the GDK README for instructions on setting it up and Troubleshooting if you get stuck.
  2. Fork the GitLab CE project.
  3. Choose an issue to work on. * You can find easy issues by looking at issues labeled Accepting Merge Requests and sorting issues by weight, low-weight issues will be the easiest to accomplish.
    • Be sure to comment and verify no one else is working on the issue, and to make sure we’re still interested in a given contribution.
    • You may also want to comment and ask for help if you’re new or if you get stuck. We’re happy to help!
  4. Add the feature or fix the bug you’ve chosen to work on.
  5. Open a merge request. The earlier you open a merge request, the sooner you can get feedback. You can mark it as a Work in Progress to signal that you’re not done yet.
  6. Add tests and documentation if needed, as well as a changelog entry.
  7. Make sure the test suite is passing.
  8. Wait for a reviewer. You’ll likely need to change some things once the reviewer has completed a code review for your merge request. You may also need multiple reviews depending on the size of the change.
  9. Get your changes merged!

For more information, please see the Developer Documentation.


See the Documentation Styleguide and Writing Documentation pages for important information on writing documentation for GitLab.

  1. Visit for the latest documentation for GitLab CE/EE, GitLab Runner, and GitLab Omnibus.
  2. Find a page that’s lacking important information or that has a spelling/grammar mistake.
  3. Click the "Edit this page" link at the bottom of the page. * Note that this will most likely link you to the GitLab EE repository, most features are available in GitLab CE and you'll likely want to contribute to CE instead. Simply replace gitlab-ee in the URL with gitlab-ce, e.g. would become
  4. Fork the relevant project and modify the documentation in GitLab’s web editor.
  5. Open a merge request.
  6. Follow branch naming conventions and append -docs to the name of the branch.
  7. Wait for a review, you may need to change things if a reviewer requests it.
  8. Get your changes merged!

For those interested in writing full technical articles, we also have a GitLab Community Writers Program which includes compensation for writing technical articles.


Please note that GitLab is in the process of being internationalized. Not all pages have been updated to be translatable, and all languages other than English are incomplete. For more information visit the documentation.

  1. Visit our Crowdin project and sign up.
  2. Find a language you’d like to contribute to.
  3. Improve existing translations, vote on new translations, and/or contribute new translations to your given language.
  4. Once approved, your changes will automatically be included in the next version of GitLab!