So there's a module on CPAN that has a critical bug, lacks some features,
or is generally under-maintained and you would like to step in?

It's great that you want to help out and we, the PAUSE admins, really
don't want to create any unnecessary barrier to getting involved with
an existing module (or distribution) on CPAN. There are, however,
some precautions we have to take. The following paragraphs outline the
reason for these precautions and the steps you have to take. Please
read them carefully.

The majority of modules on CPAN has active maintainers. If the
maintainer didn't answer the ticket you created in the request tracker,
maybe she doesn't know about the CPAN ticketing system yet? Or she's
just very busy this week and will get back to you in due time. The best
way of helping out is to talk to the current maintainer about what you
can do. Getting the PAUSE admins involved is only a last resort!

In some circumstances, we can grant co-maintenance permissions to you
or others if the current maintainer of a module has entirely
disappeared. You have to understand that is not a decision we make
lightly. We are essentially giving write access to somebody else's work
to third parties without explicit consent from the missing author.
Since almost all code on CPAN has a free license, this is likely
unproblematic from a legal point of view, but any violation of a
contributor's trust in the PAUSE/CPAN mechanisms is a serious blow
against the work of everybody who contributes to CPAN. For this
reason, we try to tread very lightly, make the least possible use of
the administrative privileges and attempt to protect voluntary
contributors like yourself or the author of the module at hand
from any unnecessary burden.

You have to realize that the author has probably invested a
signficiant amount of time into writing the code in the first place
and then gone through the additional work of making it available to
others via CPAN free of charge. Therefore, it is crucial to be very
polite when asking him or her for co-maintenance permissions.
Politeness, however, does not suffice. Particularly when maintaining
a module for which you received co-maintenance permissions from the
admins (as opposed to being appointed by the author himself), you are
*required* to respect the work and design of the author. A common
fallacy is that people think they are much better programmers than
their predecessors and that entitles them to judge others code quality
and refactor everything. Whether or not your style is "better" is
entirely irrelevant as it is not your code. Do not be arrogant, be
respectful and tread lightly!

If you published your code to CPAN, then went on a hiking vacation (or
to hospital) for a couple of weeks only to see that somebody took over,
completely changed the design, and generally wreaked havoc, you would
probably be rightfully upset and lose the good will that made you
contribute in the first place.
In order to prevent from happening, please go through the following
steps and remember to be respectful all along:

1. Use the rt.cpan.org request tracker to submit a bug report. If the
   module's documentation lists another request tracker, try that
   instead.

2. Try to reach the author via mail. At the very least, try
   PAUSE_ID@cpan.org, any mail address the author listed on his
   search.cpan.org/~PAUSE_ID page, and any mail address that's listed
   in his or her module documentation. If there's even a mailing list,
   don't forget that either.

3. Search the web for other ways of contacting the author.
   Send more mail.

4. Try posting in public places such as your use.perl.org journal,
   perlmonks.org or other forums about your looking for the author.

5. Wait for *at least* several weeks. Remember, the author might be on
   vacation, ill, or simply busy.

6. Always keep modules@perl.org in the picture. Send us a copy of your
   mails to the author. After a reasonable period of waiting, send
   another mail to the list explaining how you tried to contact the
   author and pointing at the proof thereof. Do not forget to include
   your PAUSE ID and that of the original module author in this mail.

Usually, after all this hassle, we are reasonably quick at assigning
co-maintenance permissions, but don't hold your breath, we're only
human after all. Most requests won't even get here as many authors
who moved on and don't maintain their modules any more are very happy
to see them taken care of and will assign (primary or) co-maintenance
permissions after you've tracked them down and asked nicely.

Good luck and thanks for stepping up.