Published on July 17, 2019
4 min read
Katrin Leinweber shares her experience contributing to GitLab documentation and translations.
For this edition of the GitLab contributor blog posts, I'm excited to introduce Katrin Leinweber. Let's get to know more about her!
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.
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.
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
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.
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.
I enjoy gardening and going cycling, hiking, and canoeing.
Wherever appropriate, use [skip ci]
more often in your commit messages and MR titles.
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.
Find out which plan works best for your team
Learn about pricingLearn about what GitLab can do for your team
Talk to an expert