Pull request ideas

CPAN Lotterygithubpull requestscommunity Wed 31 December 2014

This is a list of things you might consider doing when you've been assigned a CPAN distribution as part of the CPAN Pull Request Challenge (aka the CPAN Lottery). Before doing anything, please remember that the goal here is to improve CPAN while having fun, possibly learning stuff, and engaging with others. This is not a numbers game: there won't be a prize for the person making the most pull requests, and that would likely annoy the owner / maintainer as well.

Hopefully this list will grow over time. Add ideas in the comments, or email them to me, or the challenge mailing list for discussion. Better yet, write a blog post describing it, and I can just link to it from here!


  1. Fix a bug. Have a look at the distribution's bug list, which you'll find linked off the lefthand sidebar in MetaCPAN.
  2. Use strict and warnings. You may need no strict 'refs' in some cases.
  3. If the distribution uses old school OO, maybe switch it to use Moo. Discuss this with the current maintainer before you start it though, as they may not want the additional dependencies.
  4. Profile the module using Devel::NYTProf and see if you can address any obvious hot-spots.
  5. Look at the other modules that your module is using. Is there a better module that could be used? For example you might replace File::Slurp with the more recent File::Slurper. What other replacements could we suggest?
  6. Are there modules being use'd that could be require'd only if needed?
  7. Re-factor any use of indirect method notation (Foobar->new rather than new Foobar).


  1. Add a test for a bug. If there are bugs listed which aren't exposed by the existing testsuite, then you could add a test for one or more of them. Learn about the TODO block in Test::More, so that your test won't stop the module installing.
  2. Check the coverage of the testsuite, using Devel::Cover. If it's not 100%, add some tests to improve coverage.
  3. If the distribution has any CPAN Testers failures, you could try and fix them. This may only require adding a missing pre-requisite module.
  4. Are there regular tests which should be release tests? For example, failing pod coverage shouldn't prevent a module from being installed, so it should be a release test, not a regular test.

CPAN Conventions

  1. Have a look at the distribution on CPANTS, and address anything identified there. ("get CPANTS clean"). Some of the items covered by CPANTS are listed below.
  2. Ensure the minimum Perl version is specified in the distribution's metadata, and in the code.
  3. Ensure the distribution has a Changes file.


  1. Ensure the module has a good abstract.
  2. Ensure the module has a good SYNOPSIS. The SYNOPSIS doesn't have to illustrate every feature of the module, just canonical usage.
  3. Ensure the module has a good SEE ALSO section in the doc. This can take time, as you'll need to search for similar modules. If some of these other modules are more appropriate to use in some situations, you could update the documentation to reflect that too.
  4. The first paragraph of the DESCRIPTION section should be a concise description of what the module provides / is for.
  5. Fix typos in the documentation.
comments powered by Disqus