Training Day

Pull Requests are WELCOME! This is probably the most common sentence in the open-source world. Attending to meetups, conferences, summits, and when somebody writes any comments in Github, usually asking how to do this or that, and make feature requests, that sentence comes back to you as an implacable boomerang.

Most of the time, there is a limited number of core maintainers, for an open-source project, which work for another company trying to get a profit from this open-source project. This reduced amount of maintainers situation leads to an answer like the one mentioned at the beginning of this paragraph. So you, as an open-source enthusiastic person, tell yourself, “ok, why not, I can make it!“.

Starting a collaboration in an open-source project is not easy today and many people are working to improve the experience for future contributors to get to speed as soon as possible into the projects and in the smoothest way. In this article, you will read some contribution tales and proposals to improve the early contribution of new people to open-source projects. Engage!

You Are In The Office, Baby

You go back to the main page of the Github project trying to find where to start your collaboration. At that point, “that” idea comes back to your mind: Will I be able to do the changes that I kindly asked in the issues section of this project?. Not sure actually, because you never saw the insides of the project before, you never even cloned it! Which framework is it using!? Oh my dear, not sure if I will be able to make it.

This is the first barrier that any new contributor faces all the time, even the experienced ones: Your mind. But yes, all is on your mind, which is a good thing. In fact, in the open-source world there are no barriers (Do you think that’s air you’re breathing?) and you can create pull requests no matter what, even though you think your change does not make any sense. The truth is, the core maintainers really need your work, and, for them, is much easier when you push your proposal and they just review it for future approval. Think about it in that way.

All of your changes will be reviewed, which is good, and the community will ask you for more tests, refactorings, or corrections about how the logic should work. Many of your changes and Pull Requests will be rejected, that will happen, and it makes sense because you already know that not all your work is the “best work”. You have to change your mindset and adapt to the new neighborhood, bro!. Release your mind and make that first Pull Request. Just in case, read how to create your first pull request.

It’s Not What You Know, It’s What You Can Prove

At this point, you already know where to start… more or less at least. You cloned the repository from Github and you are ready to make the change you proposed in your initial comment in the issues section of the project. Your change could be at the documentation level, which maybe is the most simple ones when you start in a new open-source project, or something more advanced that involves changes in the code. At this point, you should realize that you are almost there, you are close to pushing your changes to your forked version of the project and create a Pull Request to the original project, and nobody asked you for your technical skills, you did not have to pass any kind of interview or similar. This is because you are now in the open-source world, where you will succeed because of the things that you can get done.

Great! You have your fist Pull Request on this open-source project, congratulations!. Now what?. Wait and listen (read, in fact). Unless you are fixing a typo in the documentation, you Pull Request will take time to be approved and, since it’s your first one into this project, you will have comments to improve your change and, maybe, change it completely. This is a usual thing on open-source project contributions, so do not get frustrated. But nobody told you before, right?.

This is real life, so just follow a common-sense code of conduct and be open to what the reviewers will give you as feedback. Remember, you are helping the core maintainers to maintain better software as an open-source citizen.

What A Day

Was this process for contributing easy? probably it was not. Better contribution guidelines are possible? I’m my opinion, yes, absolutely, but takes more time even though brings faster adoption and engagement. This is real life, as I mentioned before, and in real life, only one single CONTRIBUTE.md file is not enough to engage a developer in a project, you need much more than that.

A way to improve the contribution from new people is by providing shadowing and talks where the core maintainers explain “how to do your first commit”, something like an online or presence talk where the “newcomers” would see how it is and what to expect. Lead by example, someone said. This is what happens when a new co-worker comes into a team, she/he does shadowing and receives talks from peers about the technologies to work with. An example of this is what Iván López did to demonstrate how to contribute to Micronaut and test your changes locally before submitting a PR. Does make sense?.

Another way could be having what I like to call Maintainers Sessions for Newcomers. This would be some kind of Zoom meetings, where you can ask via voice, and receive help and advice directly from the current maintainers of a project, the people that are experts now. In these kinds of sessions, a new contributor would have the space to ask how the project works and how to get involved as a new contributor. Does make sense?

Any idea about how to improve the early adoption of open-source projects by potential contributors? Let’s share on Twitter!