Is anyone else wondering how the f it’s already February? 🤔
2021 is well underway and as a travel-tech company, we’ve got a lot of interesting challenges ahead of us. One of our favourite collaboration tools to develop our accommodation price comparison is Github – the place where most of the open-source software is crafted. So, why not use it for developing an accommodation price comparison website?
Inside trivago, all engineering teams use one single organization to boost cross-team and department collaboration, foster transparency, and benefit from best practices like automation and templates.
You know the drill, we’ll be adding a new tip every day, so keep an eye out. If you’re a frequent user with some tips of your own to share, let us know in the comments below!
Tip #1
Imagine you have an Open Source Repository in your GitHub account. One day, you wake up, check your email account, and receive a notification that Mary from South Africa has opened a Pull Request to your project to fix a bug you were not aware of. Yey! What a great feeling and boost motivation.
To keep the quality of your code high, you do a code review before merging. Overall, the code looks great. However, there is one small thing about a corner case that Mary missed.
You have two options:
Commenting on what needs to be changed and move on.
Creating a Code-Change-Suggestion directly into the review comment.
Option 1) requires that Mary get back to the code and understand how you, as a code owner, imagine the code to be changed, make the change, and waits for another review by you. This can take some time.
On the other side, in Option 2) you directly add the suggested change in the review comment and ask Mary for a review:
This helps:
to merge the Pull Request faster by lowering waiting times
to share the effort making the change between the code owner and contributor
to avoid constant back and forth pings
to get higher quality by another review
to enable Mary to learn more about your project with low effort
Tip #2
Open Source, Code and (Software Engineering) is all about people and communication. The best software is useless if there are no users. And users typically have questions, comments, or sometimes just a simple “Thank you” for you.
An issue tracker might not be the best place for this kind of content. You can easily lose the overview of critical bugs or important features between all questions. Many projects run a Forum next to their GitHub Project. With GitHub Discussions you can keep everything together.
Enable the Discussions-Feature for your repository today (under Settings → Features) to create a space for all topics that don’t fit in the issue tracker:
See how this can evolve:
Tip #3
Be aware: Just because Code is published on GitHub does not automatically mean that this Code is Open Source or that you’re allowed to use it in your project. If the code doesn't have a LICENSE, the code is declared as proprietary code. And to make it even more complicated: It depends on the copyright laws in your country.
That's why a LICENSE file is essential. To declare what is allowed and what is not allowed for this project and code.
There are many LICENSES out there. It can be overwhelming to choose one:
MIT License
Apache License 2.0
and many more …
But be aware: Not every license that claims to be an open-source license is one.
The Open Source Initiative put a list of licenses together that comply with the Open Source Definition.
GitHub helps you to choose the correct Open Source License with choosealicense.com:
And is making it easy to start new projects with a LICENSE.
Tip #4
Not every maker receives feedback about their incredible work. On the one side, to know that real people using your code is motivating. On the other side, If you can’t measure it, you can’t improve it.
Do you know how often your project is used, cloned, or how many visitors your README has daily? You don’t control the GitHub website; that's why you won’t have this data on your hand.
But: GitHub shows you this data under <Your Repo> → Insights → Traffic
Tip #5
Every time you integrate a new library, start with a new language or talk to an external API – you need to learn how to use it and read the documentation to be successful.
Especially in the beginning, this can be challenging.
At this time, specific code examples can be a lifesaver. However, often the particular piece you are looking for is missing.
Open Source to the rescue!
Why not check others' code on how they use it?
GitHub Search is powerful and an excellent use-case for this. A place to see how other people are using the library, the language, or the external API with the different filter options.
Here are a few examples:
That’s all for now folks. Let us know which Github tips and tricks you’ve picked up yourself over the years – we’re always happy to exchange with you!