Michael G Schwern wrote:
I think you have a different idea of what "being Phalanxed" means from those of us who are already engaged in the project.
Anyhow, point is I know what the Phalanx project is but other authors might not. It may be a good idea to send out a little note to authors who have been Phalanxed explaining what the Phalanx project is all about and letting them know they might see a sudden spike in test and doc patches.
As Andy Lester writes on the main Phalanx web page:
"Phalanx will only work WITH module authors, not against or instead of them. If an author is not interested in our help, then we'll move on to another module. We're not here to take over.
"Also, remember that your modules are not getting singled out as 'needing help'. Every module can use improvement. The Phalanx 100 is based roughly on popularity and importance."
So for me the crucial step in working on Phalanxing a module with my colleagues in Perl Seminar NY was to secure the module author's green light to Phalanx away. (We'll be presenting our proposed test, code and documentation revisions to him this month, so we don't yet know what portion of our work will be accepted into the next version of the module to appear on CPAN.)
The Phalanx 100 is really just a rather crude way of piqueing interest in the Phalanx project. The module we're working on appeared on the first version of the Phalanx 100 but not on the second. So f**king what? We all respected the author so much that we leapt at the chance to contribute to his base. We're now discussing Phalanxing another widely used module (which I think is on the current Phalanx 100) -- but the first concrete step in that will be to establish a relationship with the module's author.
So I don't think module authors are likely to be caught unawares by "a sudden spike in test and doc patches." If only we had that problem! No module will be added to the Phalanx project without the author's or current maintainer's consent. Andy has written a couple of sample letters that Phalanx contingents can use in approaching those module authors.
And now for a bit of personal testimony:
1. In preparation for pitching the idea of participating in the Phalanx project to my fellow NYC Perl hackers, I learned how to use Devel::Cover and then applied it to the test coverage in my own three CPAN distributions. Devel::Cover uncovered bugs that had never been found in several years of personal use of these modules on a daily basis or in repeated testing at testers.cpan.org. And I learned Devel::Cover well enough to be able to give a talk on it at one of our perlsemny meetings.
2. Also as a consequence of my work on Phalanx, I got more serious about test-driven development ... serious enough to preach the gospel when invited to speak at a New Orleans Perlmongers meeting two months ago.
3. I don't work with other hackers -- Perl or otherwise -- on my day job. In fact, I'm not paid to be a hacker at all. So I really cherished the opportunity to spend an afternoon with David H Adler and Marc Prewitt Phalanxing our targeted module a couple of weeks back. (To be honest, I haven't spent so many consecutive hours in a bar since I was in college -- but, then, they didn't have wireless access, iBooks or Perl when I was in college.) In that session I used SubEthaEdit for the first time. Am looking forward to a similar opportunity this weekend. Note: While Phalanxing a module does not require F2F hacking, I think it clearly makes the whole experience more stimulating and enjoyable.
4. As preparation for that hacking session last month, I had to install and learn Subversion -- the first time I ever worked with a version control system. This has had a *big* impact on the way I work. I'm now doing a major overhaul of the modules I use on my day job using version control ... and just today I started to use some of the newer features in Test::More!
jimk
