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.

Well this is a bit embarrassing. My script to tell me the date of the first CPAN/PAUSE upload told me the 16th August, but somehow when writing the first post about it, I changed the date to the 14th. Doh.

The good news is that 16th August is a Saturday this year, which gives us all a better chance at uploading a release or two. And two more days to prepare.

I've updated the previous posts, and regenerated the charts.

The SEE ALSO section in your module's pod is where you direct the reader to other things of interest. In this post I'll briefly outline what constitutes a good SEE ALSO, and why it benefits you to create one.

My thoughts on this topic have evolved over time, and in writing this I've realised that a lot of my modules could do with a brush up. I'll be releasing those on CPAN Day, of course :-)

If the abstract for your module is up to snuff, then have a look at the SYNOPSIS to see whether you could improve that in a CPAN Day release. The SYNOPSIS should briefly show typical usage of the headline features of your module.

Here are some guidelines for a good SYNOPSIS:

If you're looking for something to release on CPAN day, check the abstract for your modules, and make sure they have a good abstract. The abstract should not only be compliant pod, but should succinctly describe what your module does. The name and abstract are often the first thing that potential users see, so make them count.

How many releases were done on previous CPAN Days? I know you've been dying to find out, so here are a few graphs, and I'll also compare with the top days in CPAN history. If 100 people each do one release on this coming CPAN Day (16th August, UTC), then it'd be the best CPAN Day yet. If between us we manager 151 releases, that would be the highest day ever.

CPAN and PAUSE record their timestamps in UTC, as all sane systems do. So if you're planning to release on CPAN, please take that into consideration.

Celebrate the inauguration of CPAN on the 16th August by doing something related to CPAN: release something, blog about your favourite module, or email its author thanking her or him.

The Perl community on gittip has 499 members right now (Wednesday morning, GMT). Who will be the 500th member? It could be you!

Jerome Eteve was the 500th member! Jerome is the author of Alien::ImageMagick, and more.

Does anyone fancy writing a Dist::Zilla plugin that would read a Changes file in YAML and munge it to one in the CPAN::Changes::Spec format?

I'm proposing an explicit community convention where experimental code isn't released to CPAN, but is shared on github, perhaps with an associated blog post, or discussion on PrePAN.

This addresses just one of CPAN's problems, which have also been raised today by Brendan Byrd.

The other day Andy Lester posed a question Where can someone find Perl modules to contribute to? My first answer was to look at the dists with the most bugs. I continued thinking about it, wondering how you could identify a module that is ripe for help.

This post outlines my next idea, and the top 20 dists based on my first implementation.