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.
