The two sides of a pull request

gitgithubpull requests Mon 5 January 2015

When you submit pull requests, the owners don't owe you a merge, and you shouldn't start hassling them to act on it. The flip side of that: if you're the owner (or maintainer) of a github repo, and someone submits a pull request, please at least communicate, even if you don't plan on acting on it anytime soon.

Submitting a pull request

If you've worked hard on a pull request (PR), perhaps to fix a bug that's causing you problems, or to add a feature you need, then it's understandable that you want to see it merged and released ASAP.

But most CPAN modules, and most open source, is maintained in people's spare time, and people generally have a lot of different calls on their time. And the reality is that what's important to you probably isn't important to them.

Even if they're happy to get your PR, they might be busy, on holiday, stressed, distracted, ill, or something you can't even imagine.

Or they might not be keen on some part of your PR, but feel uncomfortable about saying that.

So give them some time. If a week or two goes by and you hear nothing, then add a comment to the PR on github, asking if there's anything you can do to help. Stay polite and respectful of their work and their time.

Receiving a pull request

Sometimes you get a small / simple PR, and can see right away that it's good. You've got the time, so you merge and release.

Other times you're busy, or you want more time to look at the PR more closely, or you're not sure whether you agree with the change. Or, or, or.

When this happens, it will help the submitter a lot if you at least add a comment. The more specific you can be the better, but at least saying that you don't have time now, and will get to it later, is so much better than nothing.

If they do chase you, and they're rude, understand that they're feeling invested in the PR, and want to get it past the finish line. Be firm but polite. Is there some way you can move things forward? For example:

I realise you're keen to see this acted on. I'm happy with the first part of your change, but really not sure about the second. If you modify your PR to contain just the first part, I'll happily merge that. Then maybe we can discuss the second part.

If there's some part of their PR that you really don't agree on, then tell them. Better they find that out sooner than later, and can decide to truly fork, and release their own modified version of your module, under a different name.

Thoughts?

If you've got experience on either side, particularly that's not reflected above, then please let me know how the above can be improved.

Github is a key part of how the Perl / CPAN community works together, so I think we should try and ensure that runs as smoothly as possible. Not just for new contributors, but for old hands who might be experienced with Perl, but less so on git, github, and associated processes. I certainly fall in to that group, and am hoping the pull request challenge is a chance for me to learn / improve. I certainly need to get better on handling PRs for my dists.

comments powered by Disqus