8.6 KiB
How to contribute to GitLab
Help the community by contributing to code, documentation, translations,
user experience design, and more.
I think many people are familiar with GitLab—the company or the software. What many may not realize is that GitLab is also an open source community that started with this first commit from our co-founder Dmitriy Zaporozhet in 2011. As a matter of fact, we have more than 2,000 contributors from the wider community who have contributed to GitLab.
The wider community contributions span code, documentation, translations, user experience design, etc. If you are interested in open source and in contributing to a complete DevOps platform, I'd like you to consider joining the GitLab community.
You can find things that you can start contributing to by looking at issues with the "Accepting merge requests" label sorted by weight. Low-weight issues will be easier to accomplish. If you find an issue that you're interested in working on, be sure to add a comment on the issue saying that you'd like to work on this, and verify that no one is already working on it. If you cannot find an issue that you are interested in but have an idea for a contribution (e.g., bug fixes, documentation update, new features, etc.), we encourage you to open a new issue or even open a merge request (MR) to start working with reviewers or other community members.
If you are interested, here are the different areas at GitLab where you can contribute and how you can get started.
Development
Whether it's fixing bugs, adding new features, or helping with reviews, GitLab is a great open source community for developers from all backgrounds. Many contributors have started contributing to GitLab development without being familiar with languages like Ruby. You can follow the steps below to start contributing to GitLab development:
- For GitLab development, you should download and set up the GitLab Development Kit. The GDK README has instructions on how you can get started.
- Fork the GitLab project that you want to contribute to.
- Add the feature or fix the bug you want to work on.
- If you work on a feature change that impacts users or admins, please also update the documentation.
- Open an MR to merge your code and its documentation. The earlier you open an MR, the sooner you can get feedback. You can mark your MR as a Work in Progress so that people know that you're not done yet.
- Add tests, if needed, as well as a changelog entry so you can be credited for your work.
- Make sure the test suite is passing.
- Wait for a reviewer. A "Community contribution" label will be added to your MR, and it will be triaged within a few days and a reviewer notified. You may need multiple reviews/iterations depending on the size of the change. If you don't hear from anyone in several days, feel free to mention the Merge Request Coaches by typing @gitlab-org/coaches in a comment.
Documentation
Contributing to documentation is a great way to get familiar with the GitLab development process and to meet reviewers and other community members. From fixing typos to better organizing our documentation, you will find many areas where you can contribute. Here are the recommended steps for people interested in helping with documentation:
- Visit https://docs.gitlab.com for the latest GitLab documentation.
- If you find a page that needs improvement, click the "Edit this page" link at the bottom of the page, fork the project, and modify the documentation.
- Open an MR and follow the branch-naming convention for documentation so you can speed up the continuous integration process.
- Wait for a reviewer. A "Community contribution" label will be added to your MR and it will be triaged within a few days and a reviewer notified. If you don't hear from a reviewer in several days, feel free to mention @gl-docsteam in a comment.
You may also want to reference GitLab Documentation Guidelines as you contribute to documentation.
Translation
GitLab is being translated into more than 35 languages, and this is driven primarily by wider community members. If you speak another language, you can join more than 1,500 community members who are helping translate GitLab.
The translation is managed at https://translate.gitlab.com using CrowdIn. First, a phrase (e.g., one that appears in the GitLab user interface or in error messages) needs to be internationalized before it can be translated. The internationalized phrases are then made available for translations on https://translate.gitlab.com. Here's how you can help us speak your language:
- Log into https://translate.gitlab.com (you can use your GitLab login).
- Find a language you'd like to contribute to.
- Improve existing translations, vote on new translations, and/or contribute new translations to your given language.
- Once your translation is approved, it will be merged into future GitLab releases.
UX design
In order to help make a product that is easy to use and built for a diverse group of people, we welcome contributions from the wider community. You can help us better understand how you use GitLab and your needs as you work with the GitLab UX team members. Here's how you can get started:
- Visit the https://design.gitlab.com for an overview of GitLab's open source Design System. You may also find the Get Started guide to be helpful.
- Choose an issue to work on. If you can't find an issue that you are interested in, you can open a new issue to start a conversation and get early feedback.
- Create an MR to make changes that reflect the issue you're working on.
- Wait for a reviewer. A "Community contribution" label will be added to your MR, and it will be triaged within a few days and a reviewer notified. If you don't hear from anyone in several days, feel free to mention @gitlab-com/gitlab-ux in a comment.
Getting help
If you need any help while contributing to GitLab, you can refer to the Getting Help section on our Contribute page for available resources. One thing I want to emphasize is that you should not feel afraid to mention people at GitLab in issues or MRs if you have any questions or if you feel like someone has not been responsive. GitLab team members should be responsive to other community members whether they work at GitLab or not.
via: https://opensource.com/article/19/9/how-contribute-gitlab