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.