For this edition of the GitLab contributor blog posts, I'm excited to introduce Katrin Leinweber. Let's get to know more about her!
Can you tell us where you live and what you like about your area?
I live in Hanover, Germany, which is transitioning from a car manufacturing hub to a more modern and diversified city. The city is reasonably bicycle friendly with large parks and gardens, which are worth a visit. I don't find Hanover too touristy, which is probably a plus for us citizens.
How long have you used GitLab and why did you want to make a contribution?
I started using GitLab CE at my university in April 2015 as a backup server for my PhD thesis, data analysis scripts, etc. My first merge request was simply fixing a typo in a blog post.
You also help translating GitLab into German. How is that different from making contributions via MRs and why is translating GitLab important to you?
Localization is one of the tasks that got me into contributing to open source software projects in general. Even though I myself don't need a localized UI, I think it's valuable to many people to be able to use a complex software in their native language. Since I think that GitLab has valuable uses beyond programming, I hope lowering the barrier to entry for non-programmers will help support those use cases. Also for me, doing quick translations is a sort of productive procrastination.
Canoeing on Hanover's river Leine
What has been your experience contributing to GitLab?
Technically, it's pretty straightforward and something people should be familiar with if they've contributed to other projects or used tools like GitHub. Every time I contribute, I feel like I'm living (in) the future where projects allow people to change something of theirs.
However, we shouldn't forget that "No, this Wiki page is only editable by colleagues in the XYZ department" is still the default in so many work environments. So the future isn't quite here for everyone yet.
One of the things that bothers me about GitLab's contribution process is the fact that even simple changes – like documentation updates – get pushed into the same CI pipeline as code changes in many cases. It seems like a waste of electricity. Maybe not in terms of absolute kWh, but since the risk of anything breaking due to a typo fix or an updated hyperlink is almost zero, those kWh are effectively wasted. There should be a smarter way to minimize human effort in preventing build breakages than to use more CPU cycles for testing. We all know that humanity can't afford to waste resources anymore.
In that vein, I wouldn't mind seeing GitLab also supporting the renewable energy industry as I don't see that listed in the market segmentation page yet.
Do you participate in other open source projects? If yes, what do you like about other communities and what are some of the things that GitLab can learn?
I do, for example in The Carpentries, which provides Open Educational Resources and basic programming training for researchers. I find the GitLab community is quite thoughtful about sharing what they learn about successfully pushing the product and the company forward. So I think other open source projects will find lots of advice in GitLab's blog and handbook that is worth considering.
What do you like to do when you're not working?
I enjoy gardening and going cycling, hiking, and canoeing.
Anything else you want to share with the community?
Wherever appropriate, use [skip ci]
more often in your commit messages and MR titles.
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.
