Treat Pull Requests are conversations, not code donations
Tags: opensource, elementaryos
Published: 2021-01-25 14:00:54



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](http://elementary.io): **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](https://dev.to/igordsm/my-year-in-review-contributions-to-elementary-os-3amd) 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](https://github.com/elementary/camera/pull/138) accepted. My first try looked like the GIF below:

![First try for #138](https://user-images.githubusercontent.com/221446/93685926-45660980-fa89-11ea-9451-19ff9ae70078.gif)

Many design issues were raised and I created a second version:

![Second attempt](https://user-images.githubusercontent.com/221446/97380069-0788ac00-18a5-11eb-933c-9be9c562b262.gif)

I received some curious feedback on this one:

![ModeButton or ModelButton](https://dev-to-uploads.s3.amazonaws.com/i/p9lmteedv2kejwi7x5r4.png)

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.

![Final screenshot](https://user-images.githubusercontent.com/221446/98941954-09b95000-24cc-11eb-8b85-d8939dda3ed7.png)

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.