Grant Application: Maintaining Perl 5
Sun, 19-May-2013 by
Karen Pauley
edit post
<![CDATA[
We have received the following grant application, under the "Perl 5 Core Maintenance Fund":http://www.perlfoundation.org/perl_5_core_maintenance_fund, from Tony Cook.
Before we vote on this proposal we would like to get feedback and endorsements from the Perl community. Please leave feedback in the comments or send email with your comments to karen at perlfoundation.org.
**Project Title**: Maintaining Perl 5
**Name**: Tony Cook
**Synopsis**
Free up one of the Perl 5 core's contributors to work non-stop on making Perl 5 better.
**Benefits to Perl 5 Core Maintenance**
This grant provides the pumpking with a development resource to target as he or she wills, while still providing for more general bug fixes and other improvements to the perl core.
**Deliverables**
I propose to adopt the same model as Dave and Nicholas's successful ongoing grants.
Like their grants, there are intentionally no pre-defined deliverables for this project. I intend to devote around 260 hours (about 20 hours a week) over the next 3 months to work on improving the core, paid by the hour at the same below-commercial rate as Dave and Nicholas. Some weeks I may be able to more than 20 hours, if acceptable this will consume more hours and end the grant earlier.
Like them, I would post a weekly summary on the p5p mailing list detailing activity for the week, allowing the grant managers and active core developers to verify that the claimed hours tally with actual activity, and thus allow early flagging of any concerns. Likewise, missing two weekly reports in a row without prior notice would be grounds for one of my grant managers to terminate this grant.
Exactly as Nicholas and Dave do, once per calendar month I would claim an amount equal to $50 x hours worked. I would issue a report similar to the weekly ones, but summarising the whole month. The report would need to be signed off by one of the grant managers before I get paid. Note that this means I am paid entirely in arrears.
At the time of my final claim, I would also produce a report summarising the activity across the whole project period.
Also, (the "nuclear option"), the grant managers would be allowed, at any time, to inform the board that in their opinion the project is failing, and that the TPF board may then, after allowing me to present my side of things, to decide whether to terminate the project at that point (i.e. to not pay me for any hours worked after I was first informed that a manager had "raised the alarm").
I view this grant as a proof of concept - if it goes well for everyone involved, I expect to apply to extend it.
**Project Details**
I think that the work that I would do to improve Perl 5 would mostly fall into one of four main classes: code reviews, bug fixing, helping other contributors, and adding features - with bug fixes the most prominent and adding features the least.
In one major sense what I'm offering is different to Nicholas's or Dave's grant: the current pumpking would be able to assign tasks directly.
Ideally this would be done with some consultation with myself, so a large complex task involving parts of the core I'm unfamiliar with isn't assigned (or is assigned with reasonable expectations on time). Of course, if too many tasks are negotiated into non-existence, the grant can be terminated.
Some possible tasks, based on discussions over the last several months:
* readpipe(@list)
* core exception objects
* a git hook to prevent changes in the left of a merge
Success metric: completion of tasks assigned.
Otherwise I'd work on:
* Reviews of patches submitted to perlbug, possibly committing them
This will improve my core knowledge, and provide more timely feedback to non-committers using their time to help perl.
Metric: number and complexity of patches applied or commented on.
* Fixing bugs I select from the perl5 Request Tracker queue.
While I wouldn't necessarily be working on the the harder bugs that Dave targets, this would help bring the total bug count down, and reduce the noise in the Request Tracker queue.
Metric: number and complexity of issues fixed.
* Fixing systemic issues in perl, such as the mis-use of I32 and U32 in the perl core.
Metric: complexity of issue solved.
* Contributing to discussion on the perl5-porters mailing list.
For the grant, I'm specifically not proposing to:
# Be a release manager. This doesn't prevent me volunteering to act as a release manager, but that wouldn't be counted towards this grant.
# Act as language designer - I don't feel that I'm good at this.
**Project Schedule**
I expect that I can deliver 260 hours of work in approximately 3 months.
I am available to start work on this project immediately.
**Bio**
I'm a freelance programmer living in Australia. I've been irregularly contributing to perl since 2008 and a committer since 2010. My contributions have varied from build system fixes, to UTF-8 handling, to portability fixes. I've been programming in C for 25 years and in perl for 20.
**Endorsed By**
Ricardo Signes, Nicholas Clark, H.Merijn Brand
**Amount Requested:** $13,000
**Suggestions for Grant Manager**
Ricardo Signes, Marcus Holland-Moritz
]]>
Category:
(none)
Comments (14)
I am enthusiastically in support!
Given Rick, Nick ,and Merijn's endorsement, this seems like a no-brainer to support.
Hi
I'm definitely in favour of Tony doing this work.
Tony:
Please also clean up usage of 'utf8' versus 'utf-8'. I'd like to see the extra '-' dropped everywhere (within Perl).
Cheers
Ron
Sounds good to me! Applicant has been helpful and responsive to my questions.
I believe that this grant should be approved. Tony has significant expertise, skills, and, not least, good judgment. It would be a mistake to turn this down.
If Rick, Nick, and Merijn endorse then so do I
+1
+1
Getting more of Tony's time will be a great benefit.
Nicholas Clark
Core exception objects? That would be awesome.
My support is qualified: I believe the priority of tasks is wrong and I don't support the grant unless the priority is revised.
We don't need more hours on bug fixing. Not to discount the heroics of Nick, Dave and many others, but many of the bugs being fixed have existed for years, have been worked around, and will take years to reach widespread production even if fixed.
There is a repetitive complaint by some on p5p (and fiveperl) that "we" don't do good code review, that the learning curve to contribution is a vertical cliff, that patches warnock, and that new contributors are treated shabbily for various reasons and thus get discouraged.
Until the dysfunctional contribution problem is addressed, we will not improve the bigger bus number problem.
Meanwhile, people work on features because they get excited about them and we've had no shortage of features implemented in the last few years. I don't think TPF should fund work that is already happening (albeit suboptimally without holistic language design).
What is *not* happening is code review and making perl easier (and friendlier) to contribute to.
I think the priority should be on code review and helping contributors (both directly on the list and indirectly by making the code/repo easier to work with).
If that doesn't take 20 hours a week, then any remaining time could go to bug triage or bug fixing.
+1
The order in the proposal was intended as a priority order, but it looks like I didn't state that.
So pumpking tasks first, then reviews, then bug fixes, etc.
I'm a late-comer. I blame vacation.
I've known about Tony considering applying for such a grant for some time and have been eagerly waiting for it to become reality. Tony has proven that his both qualified and trustworthy for such an open grant. Particularly, I am excited that Tony wants to work on what the pumpking considers most important. (Though I assume and hope that this, in practice, results from a dialogue between the two.)
I do not agree with the objections raised regarding the topic of the grant.
