Merge Request Coach

The main goal of a Merge Request Coach is to help merge requests from the community get merged into GitLab.

Responsibilities

• Triage merge requests labeled ~"Community contribution".
• Close merge requests that we don't want, with a clear explanation on the reasons why, so that people don't feel discouraged.
• Help contributors to get their merge requests to meet the contribution acceptance criteria.
• Read the weekly Merge requests requiring attention email to follow-up on inactive MRs. Each coach should pick a few MRs to follow-up each week.
• Help find and assign merge requests to available reviewers.
• If the contributor is unresponsive or if they are unable to finish it, finish their merge requests. Also, see the closing policy for issues and merge requests.
  1. Close the original merge request and say that you will finish it.
  2. Check out the branch locally.
  3. Make sure a changelog entry crediting the author exists.
  4. Add your own commits to improve and finish the original work.
  5. Push to a new branch and open a new merge request.
• Make it easy to contribute to GitLab even for people who are new to Ruby, JavaScript, Golang, etc. or programming entirely. For example, you can add any hints or possible fixes on issues that are open for community contribution.

Collaboration guidelines

As a Merge Request Coach you will collaborate with people from the wider GitLab community and respond or close their merge requests per need.

Responding to merge requests

With each merge request opened by a wider community member, it's important to note GitLab is not their main focus. They have contributed to GitLab out of kindness, and we should aim to give them the space they need to fulfill their merge request.

After a merge request from a wider community member has been submitted and you have provided feedback, allow a period of up to two weeks for the community member to continue their work before following up with the community member through a comment in the merge request.

Closing merge requests

Sometimes community contributions become stale or obsolete and changes become no longer relevant or applicable. If the changes are no longer needed, it's fine to close the merge request whether the author is responsive or not. If there’s an open discussion or questions for the author, allow some time for them to get back to the discussion before closing the merge request.

In all cases, always provide some context on why the merge request is being closed as this can lead to fewer questions later on and create a point for future reference which would be useful for team members and community contributors.

Last but not least, if there's an opportunity to provide any help or pointers for future contributions try to do that. This could be pointing to code review guidelines, documentation on how to contribute, or getting help while contributing to GitLab.

More information on the Merge Request Coach role is available in the handbook.

About GitLab

GitLab Inc. is a company based on the GitLab open-source project. GitLab is a community project to which over 2,200 people worldwide have contributed. We are an active participant in this community, trying to serve its needs and lead by example. We have one vision: everyone can contribute to all digital content, and our mission is to change all creative work from read-only to read-write so that everyone can contribute.

We value results, transparency, sharing, freedom, efficiency, self-learning, frugality, collaboration, directness, kindness, diversity, inclusion and belonging, boring solutions, and quirkiness. If these values match your personality, work ethic, and personal goals, we encourage you to visit our primer to learn more. Open source is our culture, our way of life, our story, and what makes us truly unique.

Top 10 reasons to work for GitLab:

1. Work with helpful, kind, motivated, and talented people.
2. Work remote so you have no commute and are free to travel and move.
3. Have flexible work hours so you are there for other people and free to plan the day how you like.
4. Everyone works remote, but you don't feel remote. We don't have a head office, so you're not in a satellite office.
5. Work on open source software so you can interact with a large community and can show your work.
6. Work on a product you use every day: we drink our own wine.
7. Work on a product used by lots of people that care about what you do.
8. As a company we contribute more than we take, most of our work is released as the open source GitLab CE.
9. Focused on results, not on long hours, so that you can have a life and don't burn out.
10. Open internal processes: know what you're getting in to and be assured we're thoughtful and effective.

See our culture page for more!