Raise hell, or bugs, on CPAN Day!
If you've got one or more distributions on CPAN, then on CPAN Day you could go through them and see if there are any ideas you've had which aren't listed in the issue tracker (typically RT or github issues).
If you don't have any distributions on CPAN, then you could go through the modules that you regularly use and see if there are any issues you could raise.
I'll expand a bit on what I mean, and why it might be a good use of your time.
Raising issues on your own distributions
If you're like me, then there are probably a number of things you'd like to do to/with your CPAN distributions, if you ever get the time or inclination.
Older distributions maybe reflect the way you coded and tested (or didn't) back then, and some day you'd like to update things. Maybe you've adopted some distributions and have fixed the obvious / easy things, but there are more things you meant to do.
Maybe you've ideas for new features, but never wrote them down.
Not all authors care about getting CPANTS clean, and that's fair enough. But if you'd welcome that, then you could raise an issue.
Maybe you have CPAN Testers fails on an operating system, or Perl version, that you don't really care about, or have access to.
Why bother doing this? There are plenty of people out there who would like to contribute, but can't think what to do. The more ideas out there, the more likely it is they'll spot something and think "hey, I could do that!".
These issues would also provide grist for the Pull Request Challenge mill.
Raising issues on distributions you use
If you don't have any CPAN distributions of your own, or yours are all perfect, then you could trawl through the distributions you regularly use, and see if there are any issues you could raise.
Maybe there are niggles you've always wished would get addressed, or convenience functions that would make your life easier. Don't demand them, but suggest them, and give your reasons.
Maybe you found a module hard to understand at first? You could suggest some documentation improvements, or the addition of example scripts to the distribution?
Do this from a desire to improve the module though, not to criticise. If you don't like a certain module, you're always free to write your own alternative and upload that to CPAN.
Don't go overboard, Studley
Don't go crazy with this, and don't make it a numbers game. Only raise real issues: things that you truly want to see, for the good of the module / CPAN / users.
And don't expect any issues you raise to be addressed over night. Assume that your issues will be ignored, and anything you get is a bonus. Maybe nothing will happen, then down the road someone will adopt the module, and now they have a bunch of ideas to work on.