(repeating my comment on the main section)
Although it is not a sexy area, Archive::Zip really needs the help that the proposal details.
I am the maintainer, but I am not in a position to contribute anything to the module other than to maintain the package itself and do some structural refactoring, when it comes to the actual zip specification I'm of little help.
I agree with Adam, not very sexy work, but extremely valuable to lots of people and projects (TAP::Harness::Archive being one of them).
The basic idea seems useful. But it would be good to have a better idea of the scope of the grant. At first glance, $1,500 for fixing two bugs seems off.
But maybe a lot more bugs will be fixed. Some clarification would be good.
There is almost certainly more than 2 bugs that need fixing. :)
The pyconstruct methodology alone should churn up a bunch more.
I for one would add #24036 "WinXP Explorer Exposes Problems" which basically means you can't open a Perl-generating zip file in the native Windows Explorer Zip "directory" thingy properly.
Although I am not really interested in knowing if the packages can be or not open with Windows Explorer Zip (it fails with lot of other zips from other sources), I think that to correct bugs on Archive::Zip is important.
But as Dave Rolsky says, I think $1500 is too much for fixing bugs on a module (although an important one).
On one hand I think that the general concept of giving TPF funds to people for fixing bugs in CPAN modules might be good if it helps channel corporate money to open source developers.
On the other hand will this encourage people to wait with their bugs till TPF finances the work?
I think the latter would be better avoided if the amount of money was lower to be only encouragement instead of a
full salary replacement.
$1500 for the two bugs seem to be way to high.
For that amount I would expect fixing more things either in Archive::Zip or in some other module.
I find it conspicuous that the proposal does not mention unit tests at all.
Chris Dolan: the plan is to naturally add regression tests for bugs, and other unit tests when possible. It was an ommission from the original post. We're not going to fix a bug without adding an automated test.
Note that they may not be "unit tests" but also possibly "system tests", "integration tests". I personally tend to write automated tests that test a particular bug as a system test rather than a unit test. That may be a bad habit, but that's what I did until now. Generally, I'm trying to make sure the test tests for meaningful rather than the particular behaviour of the unit.
With respect to encouraging people to leave bugs until they are funded, I note that the applicant has zero existing relationship with the Archive::Zip module, so it would not apply in this case anyways.
Now if _I_ or the original Archive::Zip author applied, that would be a different story.