There is no completely correct or incorrect way to contribute to open source.
As long as your motivations are in the interest of improving the project, or contributing good resources to the community, I recommend going for it!
Contributions come in all shapes and sizes. Even if you’re fixing a small typo in documentation, or refactoring a large section of code, your contribution is valuable and helpful. Keep that in mind.
While keeping that in mind, also be mindful of the project owners and seasoned community members. They may have opinions about the project direction or best way to shape your contribution into a form in which it can be contributed successfully. A good community will have members available for code review and discussion, to help suggest or make any changes necessary to get your pull request accepted.
Those community members are crucial for a number of reasons. They’re critical to keeping the codebase and documentation consisitent, and in line with the projects long term direction. Not every contribution can be accepted, and if you’re requested to make changes, it is import to remember that no-one is trying to stop your contribution, they want to help you mould it into a form that fits that project.
Pride is a tricky monster with software developers, and documentation contributors.. in fact anyone around Open Source in general. We need to have enough pride in the work that we do, so we produce valuable contributions, but also be aware that too much pride can make the review process tricky.
Enter into a contribution with an open mind, and with the willingness to have your mind changed, and learn from those on the project that have been around longer or have a larger stake in the project development.
What kinds of contributions can you make to your favourite project? There are official and non-official routes you can take to contribute to your project’s community:
- Use cases
- Feature implementations
- Bug Fixes
- Upgrades / future-proofing
- … and many more
These contributions would be submitted back to the project’s repository and reviewed by a community member before (hopefully) being merged in and released.
Unofficial mechanisms can be a simpler and less stressful route into contributing to your community:
- Blog Posts on your personal site
- Helping on IRC (or Slack)
- Answer some StackExchange/Overflow questions
- Generally engage the community and help others
I know from my personal experience, I went the unofficial route first, and eventually gained the courage to submit a pull request to the official project’s repository. This eased me into submissions, and allowed me to grow my knowledge a little more before opening an official pull request.
Even today, I will often contribute in a non-official capacity, as it compliments the work I do on official project resources. A great example is this post about Habitat configuration plans that has become a great at-hand resource for anyone wanting to learn this functionality within Habitat.
One final piece of advice. Are you wanting to contribute, but not sure what you should do first, or if your contribution / changes are correct? Just submit a pull request. Part of the review process will be community members helping you know what works, why your change is good / not ideal, and helping you understand how best to improve or change to contribute. You’ll often see me submit strange or stupid pull requests simply because having a discussion around a pull request is a great way to get the right people engaged and talking about a feature.
Submit that pull request!