Last week I encouraged y'all to fix a bug or two on CPAN Day, either in your distributions, or in someone else's. To help you, I listed the top 20 dists by bugs.

David "never satisfied" Golden pointed out that the table would be more useful / interesting if broken down by severity. So here it is. This also reveals that a lot of tickets don't have a severity set, so on CPAN Day we should sort that out too!

There's a well known saying, "it takes a village to raise a child". I think our equivalent is something like "it takes a community to raise a CPAN distribution". There are very few modules on CPAN that have been purely the work of one person. You get bug reports, pull requests, feature ideas, typos reported by D Steinbrunner, and so on.

All of these interactions nudge your distribution down the road, encourage you, inspire you, and sometimes annoy you. But they all help make your distributions what they are. So on CPAN day, maybe you could acknowledge them in your documentation?

It's all too easy to take CPAN for granted, particularly the modules and distributions that just work, and continue to do so year in, year out. Take a moment to thank the author or maintainer of one of your "go to" modules on CPAN Day (16th August).

I tried this: the recipient seemed to like it, and it made me feel good too.

For CPAN Day, you could check the test coverage for your distributions using Devel::Cover. If your distributions are already covered, or you don't have any distributions, take a look at the coverage results for some other dists on CPAN Cover, and maybe you could submit something for someone else's dist.

The DESCRIPTION section of your module's documentation should come after, and provide the narrative for, the SYNOPSIS. In particular, make sure that the first paragraph is a good summary of what your module does / provides. After the abstract, the first paragraph is your most powerful tool in selling your module to potential users.

For CPAN Day (next Saturday 16th August), make sure all your modules have a DESCRIPTION section in the pod, and that the first paragraph is a good summary. And if you do, tweet about it, using the hashtag #cpanday.

If you're a module author, and looking for something to release on CPAN Day, have a look at your CPAN Testers results. If you've got any failures, check the test report(s) and see if you could release an update to prevent those in the future.

If you're still looking for something to do on CPAN Day (Sat 16th August), you could fix a bug in a CPAN distribution. It might be a bug in one of your own distributions, but it doesn't have to be — you could fix a bug in someone else's distribution. If their dist is on github you could send them a pull request, otherwise attach a patch to the issue in RT.

On Saturday I wrote about naming your distribution, and how that should be based on your (lead) module name. ETHER pointed out that if your module is sub-optimally named, then you should also consider renaming your module (and thus probably the distribution) on CPAN Day.

I thought it would be helpful to expand on that, and give some pointers to resources that might help you with naming.

When you release your module to CPAN, you should make sure that the distribution has the right name. Doing so makes it more likely that all the different tools and systems in the CPAN ecosystem can process your distribution. I'll outline what I mean by that, and how you can get it right. If one or more of your distributions doesn't follow the conventions, maybe you could release a fix on CPAN day?

CPANTS bills itself as a "testing service for CPAN distributions". It calculates a kwalitee score for all distributions. It doesn't test the quality of your code, but instead evaluates whether your distribution follows various conventions.

Being 'CPANTS clean' means that your distribution is more likely to behave well with the CPAN toolchain, the ecosystem of CPAN-related services, and ad-hoc tools that various people write.

If you haven't thought of something to release on CPAN Day (Sat August 16th), have a look at your CPANTS author's page.