For this month's blog post, we're featuring Alexis Reigel. Alexis was also an MVP for GitLab 9.5 and 10.8.
How did you get involved with contributing to GitLab?
My Siemens colleagues have been using GitLab since 2013 with GitLab 5.2. The upstream first principle is important at Siemens, as they don't want to maintain local patches/forks of software. I was hired to contribute features to GitLab that are needed at Siemens, and this give-and-take process between contributors and users is what is great about open source software. My first contribution was the ability to add a custom brand header logo in emails, which I created on Feb. 7, 2017 and was merged on Feb. 22, 2017.
What was your experience with the first merged MR?
There was no controversy with my first MR, and therefore not much debate before it was merged. The review was very quick and the relevant people chimed in right from the start. For some of the later, more complicated merge requests, it was not always this straightforward. Depending on how complicated the MR is and how many people from GitLab participate, the process may take longer and generate a lot of discussions.
What advice do you have for others who may be interested in contributing to GitLab? In particular, any insights you can share with current GitLab customers who may be thinking about making code contributions?
First, I recommend reviewing existing MRs and issues before submitting an MR. In many cases, there are already discussions and potential solutions for a certain feature or bug fix. It's also helpful to find out who from GitLab is relevant or responsible for a certain area so you can ping the right person from the start.
The initial contribution should always be a minimal solution or what GitLab calls a "Minimum Viable Change (MVC)", because the solution will often change with feedback. The initial contribution should be considered a starting point for collaboration between the contributor and GitLab team-members.
In some cases, a contributor may need to be patient with their MR, as depending on the topic and complexity it may take some time to move things forward. The people from GitLab are always very kind and friendly so the discussions are respectful.
Do you have other colleagues at Siemens who also contribute to GitLab? How do you go about planning and working on your contributions?
Yes, there are several colleagues who are active within the GitLab community and you will see Siemens mentioned in MRs.
My Siemens colleagues collect issues and feature requests internally and prioritize them based on how important and urgent they are. After discussing feature requests with coworkers to make sure we have a common understanding of the intended functionality, I start to work on the issues according to their priority. I have a lot of freedom and trust from Siemens on what the solution I contribute should look like.
What do you like to do when you're not working?
I work on several other free and open source projects such as Metaflop, Mykonote, and others in my spare time. Apart from that, I like spending time with my family and friends. If there's any time left, I make and listen to music or watch a movie or two.
Anything else you want to share with the community?
GitLab is a great product and is one of the friendliest and healthiest open source communities. Contributing to such a large project may seem daunting at first, but will pay off in the end. Your contribution will be appreciated by GitLab team-members as well as everyone who uses the product.
Interested in learning how you can contribute?
A good place to start is the Contributing to GitLab page, where you can learn how you can contribute to GitLab code, documentation, translation, and UX design.
If you have any questions, you are always welcome to reach me at [email protected].
Note: This post is part of a series featuring people who contribute to GitLab.
