Increasing the likelihood of a PR merge

CPAN-PRCgithubpull requestscommunity Mon 27 April 2015

This is a collection of suggestions for how to increase the likelihood of a random pull request (PR) being merged. This particularly applies to the CPAN Pull Request Challenge, where you're trying to come up with a PR on a randomly assigned CPAN distribution. These ideas come from feedback I've had from people on the receiving end of random PRs, and discussions with experienced CPAN authors.

This is based on the assumption that you want your PR to be merged. If you keep doing PRs and they're never merged, you're going to get downhearted and eventually give up. And we don't want that. Plus the idea of the PR Challenge was to get people making useful contributions to CPAN, to improve CPAN for all of us. So we want everyone to be making good PRs and for them to be merged.

The What: do something useful

A PR is most likely to be merged if the maintainer thinks it's useful / valuable. Here's a list of the main types of things you might consider, in decreasing order of value. First, here's a list that I think very few authors would disagree with:

These next two are not quite so black and white:

Profiling code can be tricky. You need to exercise the module in a realistic range of ways, to ensure you don't optimise for one use case at the expense of some others. Or that you don't introduce bugs by rewriting some code for performance, particularly if the testsuite doesn't provide good coverage. In addition to the documentation, have a look at Tim's slides.

Not all authors care about improving their distribution's Kwalitee, so check with the author first, particularly if that's the only change you're proposing to make.

The How

See Also

Previous articles on pull requests:

Previous articles on ideas for the PR Challenge:

There's some overlap between these articles. My excuse is that some points bear repeating.

comments powered by Disqus