Skip to content
Roy Storey edited this page Jan 10, 2018 · 12 revisions

Here are some ideas for tackling PR assignments, rehashed from NEILB and IRC - thanks to Sawyer X

Code

  1. Fix a bug. Have a look at the distribution's bug list, which you'll find linked off the lefthand sidebar in MetaCPAN. Check for bugs in both the github repo's issues list, and the distribution's queue in RT. Some dists have bugs in both places.
  2. When fixing bugs, ensure that those bugs are actually not fixed on git master. IOW, they may have been fixed on git master but just not published to CPAN.
  3. Trawl through the code looking for items marked TODO, FIXME or comments in code itself talking about some other way to do something.
  4. Use strict and warnings. You may need no strict 'refs' in some cases.
  5. 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.
  6. Profile the module using Devel::NYTProf and see if you can address any obvious hot-spots.
  7. 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?
  8. Are there modules being use'd that could be require'd only if needed?
  9. Re-factor any use of indirect method notation (Foobar->new rather than new Foobar).
  10. Should any of the modules used have a minimum version specified against them. Check what functionality your assigned dist is using, then look at the Changes file for the relevant modules, to see if there's an important fix or feature that's relied on.

Tests

  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.
  5. Add Travis support to the distribution - simple introduction. You should talk to the distribution' maintainer before doing this.

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.
  4. Run perlcritic (Perl::Critic) and see whether that identifies things you could/should address. Everyone has different preferences for perlcritic, so if unsure, check with the maintainer before making changes which might be a matter of taste.
  5. Older dists often have a testsuite called test.pl in the toplevel directory, unlike the modern convention, which is a collection of *.t files in a t/ directory. If your dist has a test.pl, refactor it.
  6. Older dists will sometimes have the modules in the top directory, rather than in lib/. Move them down.

Documentation

  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.

More thoughts

  1. If you're still hungry for more, search for questions asked on sites like StackOverflow, Perlmonks etc. related to your assigned module. Chances are, if those questions reveal some misunderstanding, that's a documentation or code bug that's yet to be fixed.
  2. See if there's a dedicated IRC channel for the distribution. If so, ask for suggestions in there.

See also: PR Etiquette and Pull Request Ideas (from neilb's blog)