I joined GitHub in October 2010, most of those years since were spent working on private repositories but recently I have become more and more active in open-source projects on GitHub and in the past month I have made 107 commits into 8 repositories.
I currently help maintain the react-spring organisation and I am a moderator for the three.js slack community. I have been writing software since I was 7 years old and professionally for more than 20 years. I have spent many hours interacting with people and projects on GitHub and I absolutely love developing software.
I believe that being part of an open-source project can really help you professionally in a multitude of ways and together I think we are the ones who change the world, we are the ones who bring passion and commitment to the projects which help literally thousands of developers and companies deliver great software.
Recently I saw a comment on slack which led me to write these following tips.
1) Dogfooding
A funny term which simply means “use your own product”. Many of us use hundreds of libraries in our projects and any one of those can be a great candidate to get involved with. When you use a piece of software you better understand it’s purpose and your commitment to making it better is going to reward you as well as the other people using that piece of software.
Being involved in a piece of software you actually use is much easier than picking a random piece of software. Maybe you are not using the software today but you plan to use it in the future, that is also fine. Working on a project you enjoy using will just make contributing much easier.
A normal path into open-source is fixing a bug you have found or at least reporting it. After reporting a bug, take a look at other open issues and perhaps the maintainers are looking for help, maybe you can pick up a task or even fix the bug you discovered.
“Eating your own dog food or dogfooding is the practice of an organization using its own product. This can be a way for an organization to test its products in real-world usage. Hence dogfooding can act as quality control, and eventually a kind of testimonial advertising.” - Wikipedia
2) Code reviews, testing and debugging
In my opinion, the goal of being part of a community is to simply improve the software for everybody who uses it. That does not always mean writing code.
Other ways to contribute, check out open pull requests and see if you can contribute to those. Take an open branch and test it, include screenshots and examples of any bugs you find (I even use video sometimes to explain complex issues when needed). Feeding back on pull requests helps build trust and helps you understand the software better before attempting to change it.
When helping people, if I don’t know the answer I will be honest. I state that I am not 100% sure and maybe they could try XYZ with an example. Format your response well, check your spelling and remove ambiguity. A poorly formatted comment or opinion can lead to time wasted by all maintainers and consumers, remember why you are trying to help so be helpful.
If you find an interesting repository, simply star it, watch it and then start interacting with that community. Join the conversation and bring value to the people who are already contributing.
3) Start small, build trust
When I first start contributing to people’s projects I focus on low hanging fruits. Tidying up documentation and spell checks are nearly always accepted. Usually, the projects I contribute to are projects I use. This means I am a consumer of the documentation and when I come across missing information I simply add it in. This can include adding a Table of Contents, expanding on an example, adding additional links to other documentation pages, spell checking, adding missing parameters to methods or adding a README.md to an example folder which simply explains how to run the project locally. As a consumer of the documentation, you can easily spot shortcomings and this is a great place to start contributing.
4) Avoid huge rewrites
I think some people can become easily offended and code can be personal on smaller repositories. Imagine you head out to do some grocery shopping and you come home to find someone has removed your driveway and placed a pond in the middle of the garden. The pond may be extremely beautiful but it was unexpected and not requested. Until you are a trusted member of the community doing large changes may cause feelings of discomfort, stick to smaller open issues and avoid huge rewrites. Huge rewrites can create huge bugs and additional work for maintainers. If it’s not broken don't fix it. If you plan to make a larger change then it saves time to start a discussion first, then you can gather requirements and not waste time writing a change which will never be accepted.
Open very clean, small commits, separate concerns with different commits. Look for open issues and start talking to the repository owners before making big changes. You need to build trust and show you are professional. Ideally, you use the library personally so that you can help maintain it over time.
Spend extra time on writing a decent pull request message. Explain why you think the change is needed and what problem you are solving. Include images and video if need be. A seemingly random code change may be misunderstood by the maintainers and ignored.
Double-check everything, adding bad code to a project may mean future endeavours will be ignored, take responsibility for your changes and think about possible side effects. It can be quite awkward if you unintentionally break things.
5) Be a decent human being
This one should be obvious but when commenting and interacting with the community double-check how your mood is, are you frustrated and being angry towards the person you are replying to? Remember the person behind the screen may be having a really bad day, frustrated by an issue they believe is connected to your software.
Just because someone is being hard work doesn't mean you should respond negatively to them. Try harder to come across as friendly and try to remember the person you are talking to may only have 1 week of coding experience behind them.
Some days if I notice I am writing a response with a bad tone or being a little annoyed I often just stop replying and I revisit the topic the next day when I am in a better more helpful mood. Often someone else has responded and the issue resolved with an apology from the original poster. Remember you do not have to get involved in every single topic that is being discussed.
Proudly sharing my GitHub contributions for the past year, private and public... Visualised by this awesome open-source project on GitHub Isometric contributions plugin
The final word
I hope this post has given you some ideas on how you can become part of an open-source community. If you liked my post please give me some love and if you have any questions please drop a comment below. If you are already contributing, let me know any other ideas or tips you have, plus if you are looking for contributors to help maintain your projects please feel free to shout out the project below.