As a Merge Request Coach, I am happy to help community contributors feel comfortable when contributing to GitLab. During my time reviewing merge requests, I’ve learned a bit about how it feels contributing to GitLab as a newcomer, and I’d like to share my learnings with you.
Common issues in an MR (merge request)
In the past, I think styling might have been one of the most common issues. However, we’re improving our CI to run more static analysis, so these issues are now automatically pointed out. Today, contributors can easily see what didn’t pass CI, and they can fix the issues very quickly, so this is not as common as it was in the past.
The biggest issue today might be that many contributors don’t add tests, since tests often require much more effort than fixing or adding something. If you’re struggling with adding tests, please don’t worry. Merge request coaches can tell you how to add tests when we see your contribution, and we’ll work through it together.
Best practices
-
If you only remember one best practice, I hope it is to keep this reference handy when contributing to GitLab. I know it’s super long, but it has all the information you need when it comes to making contributions to GitLab.
-
Get GDK set up locally if you haven’t already. Running tests locally is the best way to develop and debug, and I highly encourage that you incorporate this into your workflow.
-
Don’t ignore CI. If your pipeline didn’t pass, it’s important to go back and identify the problem. Troubleshooting issues is a great way to practice your skills and help you learn from mistakes.
-
Look at the GitLab team page and pick a merge request coach to ping if you need help. Merge request coaches guide contributors and will even jump in to help finish an MR if a contributor can no longer work on it, ensuring that the attribution stays with the original contributor. Our goal is to help everyone feel comfortable and empowered to contribute even with smallest possible effort. Coaches have other responsibilities and don’t always proactively look for contributors who need help, so ping them if you’re stuck or ready for a review. If they’re not the right person to ping, they’ll pass you over to the right one. We love helping community contributors, and we look forward to guiding and working with you.
Little-known features
We recently welcomed Web IDE to quickly edit multiple files on the web directly without cloning the whole repository. Web IDE is useful if you just want to make some small changes online. If you’d like to learn more about Web IDE, please head over to our documentation.
Since GitLab's development velocity is pretty high, sometimes conflicts can happen very frequently. Did you know that you can resolve conflicts directly from the web UI? I really love this feature, because it’s very easy to resolve simple conflicts, and I don’t need to launch my editor or Git to pull, merge, and push. With some simple clicks, I can save a lot of time for simple conflicts.
What everyone should know about MRs
To me, an MR is a tool to interactively develop and explore with other people. Don’t worry about being perfect in the first version of your MR. We learn through our mistakes and get better over time.
If you’ve made tons of contributions, we invite you to join our core team or apply for a full-time position at GitLab. The MR is one of the most important ways we work together, and we’d love to collaborate with you.
What to do if you’re struggling
If you’re having some trouble getting the hang of merge requests, I suggest taking a look at how others work on the MRs. Following other people’s example can help you understand what they did and why they did it. Reaching out to a merge request coach, joining discussions, and reviewing others’ code are also ways to help you get up to speed. I think that interacting with others is a great way to learn and improve.
We’d love your contributions!
We really enjoy collaborating with community contributors, and we look forward
to working together. If you don't know what you can contribute, please take a
look at Accepting merge requests.
We label some issues to explicitly call out the ones that we won’t schedule
anytime soon, but we still want it. These issues usually have very clear scopes,
so they often just require a simple implementation. They’re nice targets if
you don’t know what to contribute but want to gain experience.
If you would like to see how we handle community contributions, please take a
look at Community contribution.
We put this label on all community contributions, therefore you can easily
find all the past and current community contributions. We look forward to
your future contributions as well!
Cover image by Victor Freitas, licensed under CC X.
