How to respond to patches

A couple of weeks ago I made a pull request to the documentation of the Symfony framework entitled: Remove reference to copying parameters.yml from Git cookbook (does pretty much what it says on the tin/title).

I had made a mistake in basing my fix on master instead of the release branch (a process error rather than anything wrong with the patch itself), but that was pointed out in a gentle way that helped me improve the process next time whilst still thanking me for the contribution. The pull request was merged a couple of weeks later, again with a brief thank you message.

This is a good example of how projects should respond to all patches, but especially those from a new contributor. First impressions count highly and I’ve lost track of the number of projects where my first patch has also been my last as a result of poor handling.

I’m also pleased that there are projects out there which take documentation fixes seriously – others include Mojolicious and Codeception – as I’ve seen some of my pull requests sit around indefinitely (I closed a few recently which had received no response for several months). I sometimes lack the time to learn enough about a project to fix a coding bug, but if I spot a typo in the documentation I’ll happily spend 10-15 minutes forking, patching and opening a pull request (or the equivalent method by email, though I much prefer GitHub as it makes the process so easy).

Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.