On friendly contributing policies
Published on
Neil Mitchell gave a talk at ZuriHac about drive-by contributions. I did not attend ZuriHac this year, but Neil published the slides of his talk. While I was skimming through them, one caught my attention:
The quote on the bottom-right is taken from the haskell-src-exts contributing policy, which I wrote back when I was its maintainer.
As I said, I didn’t have the chance to attend the talk, and the video does not seem to be released yet, so I can only guess the message of this slide (perhaps Neil or someone who was present will clarify) — but it looks to me that this quote is an example of an unfriendly message that is contrasted to the first, welcoming, message.
If that’s the case, this doesn’t seem fair to me: the quote is cherry-picked from a section that starts with
So, you’ve fixed a bug or implemented an extension. Awesome!
We strive to get every such pull request reviewed and merged within a month.
For best results, please follow these guidelines:
You could argue whether this is friendly enough or not, but you have to admit that it is at least considerate of contributors’ time and interests.
But what about those two particular sentences on the slide? Are they rude? Is it because they don’t have “please” in them?
I guess that, taken in isolation, they do seem rude for that reason, but they are part of a list of instructions, and you can make a list of instructions only so much polite. In particular, I don’t think that simply adding “please” in front of every imperative would make it any nicer — but I am not a native English speaker and could be wrong.
On the other hand, if I wrote that policy as a list of polite requests (“Could you please not put multiple unrelated changes in a single pull request?”), I feel that it would take more time and effort for a potential contributor to comprehend and extract the essence of what’s written. That would be disrespectful to the contributor’s time. Besides, if you have 10+ polite requests in a row, it starts to look as a caricature.
That said, I am open to constructive criticism. If you have ideas about how I could have written it better, please drop me a line.
Update. Neil has written a nice detailed response, which I greatly appreciate.