I'm not a maintainer of any popular modules, but I have had patches submitted to one or two of mine. I've also submitted patches to a few modules with some success.

There are a few things I can think of that you should think about when submitting a patch:

• Clear explanation of why a patch is needed.
• Unit tests that show the problem (and fix)
• Example code showing the problem (if no unit tests).
• If changing interface or visible behavior, documentation patch as well.

If I can quickly understand the change, and see the corrected behavior, I'm likely to apply the change quickly. If I'm going to have to spend a lot of time trying to decide if it's an improvement, I may put it off while I work on other things. These are not a make-or-break list. The more of them, I see the better quality I expect from the patch.

One thing to avoid is gratuitous code changes (reformatting, re-indenting, changes unrelated to the purpose of the patch). Anything that makes the patch harder to understand (or possibly apply by hand) is likely to slow down the process.

I also try to let the module maintainer know how much I appreciate the module and something (short) about how I'm using it. I am usually surprised and pleased when someone writes me about one of my modules. I find it interesting to see where they turn up.

(Preamble: I wrote this a half hour ago and forgot to hit "create" so I'm not really copying the good advice above.)

I like to get patches very much. So far it's about 70:30, apply and say thanks!, bury in my inbox and avoid saying, well, I don't think you understand what's going on here and dumping 4 hours of work in my lap to sort out this idea isn't really making me happy with the universe.

Best you can do is make the patch easy to apply. Use the latest version from SVN (update: or whatever RCS the author has) or the CPAN. Use good flags for the patch like diff -uN. Include tests that mimic the style of the author. Be clear, brief, and polite in your correspondence.

Probably should file an RT ticket first if there isn't one; bug/wishlist. You can include the patch in the ticket and send a personal note to the author. It's nice to have tracking of the issue both for the author and potential users of the code. Note, some authors use Googlecode or github and ignore their RT queues but I look at tickets when trying to pick a module for something.

And every now and again, I look at send in patches. And apply or reject some. But sometimes, there are years between receiving a patch, and actually making a release that contains the patch.

If you are getting started bugfix patches are a better bet than feature patches, they require less thinking on the part of the maintainer.

Something else occurred to me. Etiquette from the author side.

When receiving a patch that passes muster I think it's important that the author acknowledges it formally in the docs. Not necessarily in the main Pod but in the Changes file at least. This helps show Perl hackers who are active, productive, and important but maybe don't have a CPAN presence to put on their resumes. I've seen some of the most popular CPAN authors do this and it is one of the things I like about the Perl community; a real sense of reciprocity and friendliness.

I put a '=head1 THANKS TO' section in the module documentation that lists all the contributors.

As for how to persuade an author to apply your patch quickly:

• Create the patch against the author's public source code repository if possible, as that may be more up-to-date than what's on the CPAN;
• Use diff -u to create it;
• Include tests that fail without the rest of your patch and pass with it;
• Include documentation if adding or changing functionality;
• Think carefully about whether anything in your patch might affect anything else, and add more tests to prove that it doesn't, thus saving me the effort of doing so.
The patch for the module itself is the smallest of all these! Mind you, even if you do do all of that, don't get upset if it doesn't get applied quickly. Module authors are busy people, with important things to do like making beer, working on their car, trying to create the perfect pie, and so on.