develooper Front page | perl.perl5.porters | Postings from May 2009

spending other people's money

Thread Next
Nicholas Clark
May 30, 2009 05:55
spending other people's money
Message ID:
It's almost 6 months since kindly donated $50,000 to TPF

    to aid in the further development and maintenance of the Perl programming
    language in general, and Perl 5.10 in particular.

So far there is no published plan to spend it, as best I can tell from out
here the entire amount remains safely in the bank, and at it stands there
will be no change in the next 6 months either. This aids neither development
nor maintenance.

Also, still has around $35,000 surplus from YAPC::EU 2007 to spend
on "advancements of Perl":

So, without consulting either group, or anyone with commit rights, here's an
impertinent suggestion on how to try to spend other people's money. It has 3

Laziness:   It requires nearly no up front effort to organise
Impatience: It tries to spend as much money as rapidly as possible
Hubris:     It ties to both get bugs fixed, and draw new people in.

And the crazy scheme is: Offer bug bounties on every open Perl 5 bug*

Anyone can claim:

   $25 for correctly identifying* the change that introduced a bug
           or demonstrating that the bug has been present since 5.000
           or explaining why it is not a bug, and should be closed

   $25 for a committed TODO test*
           or for identifying the existing TODO test
             [may well be cheaper to write a new test.
              I don't have a problem with this]
           or for identifying which bug this is a duplicate of, and merging it

[bugs in dual life modules can't earn any more, at this point*]

   $50 for Perl code that is committed to blead that fixes the bug
  $100 for Bourn shell, Makefile or other code that is committed to blead that
             fixes the bug
  $150 for XS or C code that is committed to blead that fixes the bug

  $200 bonus for fixing bugs present in perl 5.000
  $400 bonus for fixing bugs present in perl 1.000

Hence $100 for completely resolving a Pure perl bug, or $200 for completely
resolving a bug in C code.

However, the minimum payout is $500, equivalent to 

  20 git bisect runs
  or 10 bisect + TODO test
  or 10 bisect and de-duplicate
  or 5 bisect + fix pure perl bugs
  or 2.5 bisect + fix C bugs

Right, now the small print, and hence all the *s

Currently there are 1390 new or open bugs. There isn't enough money (yet) to
pay for them all. So there needs to be an initial budget, of some size, and
first-come first-served on claiming it. Once it runs out, more fundraising

To stop anyone gaming the system by injecting bugs that they know can be
closed, or are duplicates of current bugs, "every open Perl 5 bug"
unconditionally means every bug currently open. All new bugs will be considered
by the judges, and may be deemed ineligible, if they suspect that there's a
fraud involved. This seems unlikely, but people need to be aware of this
before investing time and expecting money.

For the sake of defining what's new and what's not, I'll pick bug 66092, the
meta-bug for the 5.10.1 bugs, as the cutoff for "currently open".

Dual life modules aren't (yet) eligible, unless the maintainer wants to join
the scheme. For the rest of the document, "dual life modules" refers to
modules whose maintainers are not involved.

Bugs reported to core but found to be in dual life modules are only eligible
for the first $25, and the second $25 if they are duplicates, or already have
a TODO test in place.

  ie NO MONEY CAN BE PAID OUT for code to be committed against dual life
     modules, because we don't control the codebase.

"committed" means code is committed to one of the release branches in and is not reverted within 14 days.
(or a release, whichever comes sooner)

"marked as duplicate" or "closed" should be done in by the person
claiming - ie you will need to have requested and got bug admin rights.
[See, part of the plan is to suck you in. This isn't quite money for nothing]

"judges" are some group of people, not including me (I'm busy), probably
people with commit rights (or people we've asked but they refused)

any single judge is sufficient to validate a claim, unless

1: he or she committed the test or code in question
2: another judge disputes it within 7 days
3: he or she is also the claimant

in which case all (other) judges should vote.

[Yes, I want the judges to be able to claim too, because I suspect that some
 of the people with a track record of volunteering to find and fix bugs would
 be good for this role,and I don't want them to be barred from getting paid.]

Validated claims will be accumulated until they reach $500, at which point
they can be cashed in. I assume that accumulating claims will be tabulated
by the judges collectively in public.

"Correctly identified" is marked, because it needs to be awarded with some
caution. The output from a git bisect run is not necessarily the change that
caused the bug, particularly for bugs involving memory corruption. The judges
can and should seek advice or reject claims where the change implicated does
not affect code related to the symptoms of the bug.

The judges should make clear their scale of bribes, and publish all bribes
offered, whether accepted, declined or outbid.

Nicholas Clark

PS SuperCollider Programming will not benefit from this scheme. :-)

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About