Developers create and contribute to Free and Open Source Software for various reasons and it seems more and more people are interested in doing it. There are many articles that sound like Start contributing to open source in X steps and Hacktoberfest-like events that aim to increase engagement in FLOSS. It's not that most of these articles offer bad advice and some are actually pretty good. However, they miss a key element that I experienced time and time again when contributing to Elementary OS: sending a Pull Request is the starting line, not the finish. No matter how many magical features you implement, no project is going to accept your code if it's a mess and/or does not follow the projects design/code guidelines. For maintainers, code donation does not help: either a contribution is fit for merging or it isn't. Since fixing other people's code is hard, maintainers prefer to ignore contributors that are not open to getting their code up to the projects' standards.
In my previous article I comment on many PRs I proposed in 2020. The only ones were accepted without modifications were simple bug fixes that were very local and did not significantly impact the apps. Every other PR started (sometimes long) discussions about how to improve the proposed changes, including many design changes and even discussions if the feature should be implemented at all.
To illustrate this I'll comment the process for getting Add option to mirror the webcam image #138 accepted. My first try looked like the GIF below:
Many design issues were raised and I created a second version:
I received some curious feedback on this one:
After some misunderstandings I was finally able to produce an acceptable version. Notice that now there are sliders in the menu! They were introduced after my first attempt and I needed to add my option to the menu without breaking these new modifications.
This conversation highlights a very reasonable principle: unless you are already invested in a project and know it very well, your first PRs are probably not good enough to be accepted without modifications. And that's OK and expected. So instead of thinking that you are helping a project or donating/giving code to a project, it makes more sense to understand that proposing a Pull Request is equivalent to starting a conversation.
The conversation metaphor is interesting because it emphasizes that it takes two (or more) people to get a PR accepted:
- maintainers help newcomers and external contributors to adapt their changes so they are up to the project's standards;
- contributors continue to engage and improve their proposals until they are finally merged.
If any part disengages then the changes won't be merged and part of that effort might be wasted. Since PRs are public this might still be used by some future PR and eventually get accepted, but the odds are not favourable.
One of the good points about viewing PRs as conversations is that it is acceptable, maybe even natural, to reach out if it becomes stale. Sending messages like "Let me know if any changes are needed" or pinging people after addressing their feedback are good ways to keep the conversation alive. Just don't abuse it: maintainers are usually overworked, so sending too many messages actually makes things worse. Be polite, open to improvements and do you best to help them help you become an even better developer.
Top comments (0)