Ways that I have considered personally contributing to various Perl modules, etc:

Concrete things, that I would definitely be interested in

• CPAN::Analyze
  • I have a number of MiniCPAN-analysis-tools that I use, that I don't know if other people have access to... it might be good to put these all in one package?
  • things that might be useful:
    • CPAN::Mini::Grep (see below)
    • list all modules, and list all distributions
    • an index of the Perl code and C code, using Exuberant Ctags (and/or maybe Perl::Tags, by way of PPI?)
• MetaCPAN
  • it's fuckin AWESOME, but it's growing really fast... a very dynamic environment right now, probably fun to work on
  • implement the CPAN Zeitgeist idea, possibly propose that it be displayed on its home page
    • WHY THIS IS IMPORTANT: anything that can make the Perl developer community more dynamic (more involved in recent developments), the livelier the community will be.... I really care about Perl usage, and something like this could make a real impact)
  • issue list
    • #86: index standalone scripts
    • #11: which modules are in core
    • #6: dependents — this was closed, but could it be resurrected? I think this is an awfully important feature, it would be good to have more than one website implement it.
  • OMG OMG OMG, it was originally envisioned as an offline-analysis-tool only! (see "domain name" here. So does it have some code in there that isn't accessable from the web front-end? Is that stuff that could be used in my expansive CPAN::Mini::Grep project?
• CPAN::Mini::Grep
  • Upload this module to CPAN... it seems fairly useful. It might be an easier alternative to creating a large patch for ack.
  • It may even be possible to include ack's functionality, by making my own wrapper around App::Ack::Resource, and then calling App::Ack::search_resource().
  • Though calling it "CPAN::Mini" may be too narrowly-focused? The exact same code can really search ANY directory tree of Perl code. Maybe call it something like PPI::Ack, since PPI::Grep is already taken?
    • Would that mean I'd definitely have to use PPI then? Do something like App::Grepl's ability to search quote/heredoc/pod/comment?
    • Or is PPI optional?
• add tarball-search functionality to ack
  • MOTIVATION:
    CPAN::Mini is really fuckin' useful. It makes it easy for the masses to download all of CPAN. But what if they want to 'grep' it? Currently, that takes some amount of work to do. Including this functionality in ack would bring CPAN-grepping to the masses!
  • App::Ack::Repository::Tar is mentioned briefly in the current (v1.93_02) version of the code, but it isn't implemented yet...
    • the latest Git version has it completely unimplemented
  • for dev information, see:
    • background info:
      • "All enhancement requests MUST first be posted to the ack-users mailing list. I will not consider a request without it first getting seen by other ack users."
      • the lead developer has a LOT of different projects they're maintaining at once: activity log, projects they lead
      • wiki
        • ack v2.0 roadmap — very important
        • design rules — VERY IMPORTANT, particularly the bit about plugins and Archive::Tar
    • websites/areas:
      • commit log — yes, it's being actively maintained
      • ack-users mailing list
    • specific things relevant to me:
      • issue #104 — searching in compressed files
      • [talk, Nov2008] Working on the tar plugin
      • [talk, Nov2008] Searching gz-compressed files
        • the 'zgrep' program that they were talking about
  • next steps:
    • Contact petdance, the apparent lead developer, and ask them whether it's feasible for me to implement App::Ack::Repository::Tar now. He said that he wasn't planning on implementing it until v2.0 when plugins are available, but is there any chance I can implement it now, in the core, but have it conditionally check for the presence of Archive::Tar?
      • Or is v2.0 going to be out fairly soon?
• everywhere
  • it's an interesting module, but it's a little rough around the edges
  • The way it tries to quote any extra parameters (see the join(' ', @items) section) is WRONG and dangerous.
  • It would be nice if it gave the option to include ANY bit of text at the top of every module, so it's not restricted to just 'use'. (you can currently work-around that by using SQL injection-like methods, but that's not obvious or documented)
• Devel::Declare::Macro
  • it has never been formally released... it's basically sitting around, waiting for someone to agree to be the maintainer... until then, it's not even available in CPAN
• GRID::Machine
  • This is a REALLLLLLLYYYYY useful module.
  • It would be awfully nice if it could use other transports, namely:
    • $SSH_ASKPASS (oh! the man page mentions this already!!! :)
    • telnet (BIG one for me, unfortunately)
    • rsh (both telnet+rsh MIGHT be possible to implement using the 'command' feature)
  • Depending on various factors, I might end up having to include extra code in a separate module. Proposals for a name:
    • GRID::Machine::Telescoping — allows you to build subsequently-nested GRID::Machine instances on ever-more-distant machines, crossing machine-boundaries and sudo-boundaries alike
• Net::OpenSSH chaining
  • Net::OpenSSH is awesome. You can run GRID::Machine on top of it. You can even do $SSH_ASKPASS with it.
  • It's also pure-Perl. It should be possible to use GRID::Machine's ability to push pure-Perl modules across to then run Net::OpenSSH remotely. And it should be possible to do multiple hops.
  • I don't know if it would be able to traverse su/sudo boundaries while passing in the password for that?

Not concrete ideas

• Create a declarative interface for setting up 1) subprocesses, be they exec()ed, or our own Perl subroutine ala Forks::Super, and 2) a way to connect each of them together, and allowing the user to specify if they want pipe()s, dup'd handles, files/tcp/etc, etc. Maybe use as much pipeline programming syntax as possible.