Hi stevieb,

Check the CPAN Adoption List.

The CPAN Pull Request Challenge is the most organized way to participate. You sign up and then get assigned a distribution each month. You are "required" to make at least one pull request on GitHub in the month. It's all automated and using GitHub is super-easy. No guarantee that your PR will be merged, or even seen, if the author is MIA, but mostly it works.

The downside is that you can be assigned any dist at all, no input from volunteers. So you might get something you have no clue about or are not interested in. Or, as in my case this month, something that is so horribly broken that you just don't have the heart or time to fix it.

If you read the CPAN and PAUSE guidelines you'll see that it is encouraged to contact authors directly and offer to contribute, co-maintain, or take over maintenance. You keep the CPAN gods in the loop and they'll facilitate any changes in auth. Many modules and dists have become obsolete or broken due to simple bugs like incompatibilities with newer perls, and the authors are gone. But they can be refurbished fairly easily.

One question I always have is whether it is a good use of time and energy to fix a broken/old module, or better to cold-heartedly leave it behind. (I wish all the garbage was cleaned out of CPAN. But that's another story!)

brian d foy maintains an orphans list at CPAN, that's another option.

Many older modules lack tests, docs, and localization support. I bet you could improve the docs on any module you use! There's usually always room for improvement.

One thing that is lacking in lots of dists, especially the more complex ones, is a Tutorial -- the docs are thin to begin with and scattered in the larger dists, and the dists that have a well-written tutorial showing the real-life implementation of the package are far superior imo. There was a thread about that here in the last couple of days.

Hahaha I went to look for the node id on that thread and found that you have posted an RFC for a tutorial. Well there you go.

If you don't have a GitHub account, git one. You can fork a branch of any project that is on there (many CPAN dists are, but less so among the older ones) and just start making edits and commits to your copy. When you have something to contribute, one button and your "pull request" is sent to the maintainer and your contributions can be automatically merged with the master. It's pretty slick and makes it 1000% times easier to contribute to CPAN than in the past.

Blah blah blah, I hope these late-night ramblings were useful :-)

Others have pointed you to Neil Bowers' Pull Request Challenge, and that's an excellent suggestion. But another way to do it (the way I've done it), is to use CPAN modules. As you use them, read their documentation, and so on, you may well discover some issues that could be improved upon. Get in touch with the author; github pull requests, email, whatever. Before you know it, you could be submitting patches to the module, or even added as a co-maintainer.

One typically doesn't just set out to find a module to contribute to; that's hard. But it's easy to discover rough edges when using modules, and from there the natural progression is to start finding ways to fix those rough edges.

G'day stevieb,

rt.cpan.org would seem to be what you're after - take a look at About rt.cpan.org:

"This site tracks bugs in every distribution released through CPAN."

I just had a look at the Public Bug Tracker page; typed POD into the "General Search" box; and there's a whole list of POD bugs.

So, try searching for things in your general sphere of expertise and interest: there's probably a reaonable chance you'll find something to contribute to.

You can look at many things on this site as a guest; if you create an account, you can do more.

Also take a look at CPAN Frequently Asked Questions.

write tests

You can see the test coverage results of some modules at: cpancover.com: new web site for CPAN code coverage. Modules with lots of red (especially 0.00) need tests. Unfortunately, a very small percentage of all CPAN modules have results because people need to request to add a module to the list.

Would be cool if CPAN didn't accept dists without comprehensive docs and tests. Or at least, if there were a "top tier" of dists that meet such a criterion. Or that a dist could be relegated to a "second tier" by being downvoted ... not removed, but somehow flagged.

You can always look at the bugtracker, but if a module has no docs and no tests, why should I spend my time writing a bug report? I'd be happy to downvote it, though ...

Remember: Ne dederis in spiritu molere illegitimi!

That is (partly) why CPAN Ratings exists.

Remember CPAN was born in the time of archie, gopher and WAIS, so it was a good way to distribute alpha code or to explore an idea and it may still be providing that function when github decides to charge for all repositories in 2025.

That said, the ratings, reviews, etc mentioned above are the minimum necessary for selecting the module for your needs. I've been having a look at numerical modules and, at over 500, it's a bit of a chore just to figure out what each one does in order to classify it.

Sometimes I can think of 6 impossible LDAP attributes before breakfast.