Mailing List Archive: Perl: porters

spending other people's money

1 2

View All

Index | Next | Previous | View Threaded

nick at ccl4

May 30, 2009, 5:55 AM

Post #1 of 30 (957 views)
Permalink

spending other people's money

It's almost 6 months since booking.com 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.

http://www.hsyndicate.org/news/4039070.html
http://news.perlfoundation.org/2008/12/bookingcom_makes_a_major_contr.html

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, vienna.pm still has around $35,000 surplus from YAPC::EU 2007 to spend
on "advancements of Perl": http://use.perl.org/~domm/journal/39013

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
virtues:

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*

http://rt.perl.org/rt3/Search/Results.html?Query=Queue%3D%27perl5%27AND(Status%3D%27open%27ORStatus%3D%27new%27)

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
needed.

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".

http://rt.perl.org/rt3/Public/Bug/Display.html?id=66092

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
http://perl5.git.perl.org/perl.git and is not reverted within 14 days.
(or a release, whichever comes sooner)

"marked as duplicate" or "closed" should be done in rt.cpan.org 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. :-)

craig.a.berry at gmail

May 30, 2009, 10:12 AM

Post #2 of 30 (922 views)
Permalink

Re: spending other people's money [In reply to]

On Sat, May 30, 2009 at 7:55 AM, Nicholas Clark <nick [at] ccl4> wrote:

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

I like it. We could call it the Perl 5 Stimulus Package of 2009. Fix
those potholes in the code and put the people to work.

> 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
> needed.

The 5.10.1 blockers could be given a reserved budget or have a bonus
assigned to make them most likely to get worked on.

> "marked as duplicate" or "closed" should be done in rt.cpan.org 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]

Shouldn't that be rt.perl.org, not rt.cpan.org?

> "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)

I think recruiting judges is going to be the hard part, especially if
you are not one of them. Perhaps make all committers judges
automatically. Additional judges could volunteer or be nominated. If
getting fixes adjudicated becomes the limiting step, then at least
we're better off than we are now without the fixes available. Dunno,
just thinking out loud.

schwern at pobox

May 30, 2009, 10:11 PM

Post #3 of 30 (918 views)
Permalink

Re: spending other people's money [In reply to]

Nicholas Clark wrote:
> And the crazy scheme is: Offer bug bounties on every open Perl 5 bug*

Argh! Why didn't this come up two months ago when I was broke and unemployed
and not committed to a full time job?

--
The interface should be as clean as newly fallen snow and its behavior
as explicit as Japanese eel porn.

schwern at pobox

May 30, 2009, 10:15 PM

Post #4 of 30 (913 views)
Permalink

Re: spending other people's money [In reply to]

Nicholas Clark wrote:
> 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.

Awww. I was going to code myself a new car.

--
54. "Napalm sticks to kids" is *not* a motivational phrase.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/

nick at ccl4

May 31, 2009, 1:59 AM

Post #5 of 30 (913 views)
Permalink

Re: spending other people's money [In reply to]

On Sat, May 30, 2009 at 12:12:23PM -0500, Craig A. Berry wrote:
> On Sat, May 30, 2009 at 7:55 AM, Nicholas Clark <nick [at] ccl4> wrote:
>
> > And the crazy scheme is: Offer bug bounties on every open Perl 5 bug*
>
> I like it. We could call it the Perl 5 Stimulus Package of 2009. Fix
> those potholes in the code and put the people to work.

If it works, I'd like it to keep working in 2010, 2011 etc.

> > 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
> > needed.
>
> The 5.10.1 blockers could be given a reserved budget or have a bonus
> assigned to make them most likely to get worked on.

Given that sometimes getting things approved adopts a regal pace, I'd not
like to hard code any assumptions in that this would be usefully up and
running before then.

(Also, I'd not like anyone to defer working on things, or create a strategic
patch reserve, so that *if*, not when, it gets approved, they can immediately
produce a lot of valid work and thereby claim money)

But, it seems a sensible addition to allow the judges the flexibility to vote
to add an additional bounty amount to any bug, and publish such a list.

Although I'm not sure of the maximum amount. $300 would allow them to make
a single C bug have sufficient bounty that identifying and fixing it would be
$500, and hence claimable.

> > "marked as duplicate" or "closed" should be done in rt.cpan.org 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]
>
> Shouldn't that be rt.perl.org, not rt.cpan.org?

Yes, it should.

> > "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)
>
> I think recruiting judges is going to be the hard part, especially if
> you are not one of them. Perhaps make all committers judges

I have some ideas on who I want to beat up until they say yes.
Unfortunately, timing wise, a couple of them have in the past made a
significant dent on the numbers in the bug database, and aren't going to
get any reward for it from this plan.

> automatically. Additional judges could volunteer or be nominated. If
> getting fixes adjudicated becomes the limiting step, then at least
> we're better off than we are now without the fixes available. Dunno,
> just thinking out loud.

I don't actually know who all the current committers are. There are 23 home
directories on camel, and not all of them have commit access.

I'd prefer 5 or 7 active judges than 23 semi-active, particularly as some
things require a vote from the judges. A vote with a deadline can close
early if everyone who could vote has voted. That's not going to happen with
23 people.

Also, getting fixes "adjudicated" is two-step already - person A (with commit
rights) has to commit it to core, and person B (on the list of judges) has to
double check. I suspect the bottle-neck will still be A, particularly as A
has the right (and the "duty") to revert it, if it turns out to spew smoke.

Nicholas Clark

nick at ccl4

May 31, 2009, 2:32 AM

Post #6 of 30 (913 views)
Permalink

Re: spending other people's money [In reply to]

On Sat, May 30, 2009 at 10:11:15PM -0700, Michael G Schwern wrote:
> Nicholas Clark wrote:
> > And the crazy scheme is: Offer bug bounties on every open Perl 5 bug*
>
> Argh! Why didn't this come up two months ago when I was broke and unemployed
> and not committed to a full time job?

Well, there are various reasons why *I* didn't suggest anything then.

1: It was looking like Richard was going to have the time to look into
spending booking.com's money usefully
2: Whilst I was aware that Vienna.pm still had money to spend, I wasn't aware
how much it was
3: I wasn't fully aware of the number of bugs that Dave thinks he wants to
investigate before 5.10.1

Nicholas Clark

nick at ccl4

May 31, 2009, 2:53 AM

Post #7 of 30 (912 views)
Permalink

Re: spending other people's money [In reply to]

On Sat, May 30, 2009 at 10:15:50PM -0700, Michael G Schwern wrote:
> Nicholas Clark wrote:
> > 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.

^^that definition^^

> > 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.

^^applies here^^

> Awww. I was going to code myself a new car.

I don't object to that, and I'm sure car manufactures don't object either.

The reason for explicitly wanting to exclude dual life modules where the
maintainer isn't involved is that the rules for claiming include having
the code committed. Sadly, we can't guarantee that for all dual life modules.
Also, I didn't want to create the social pressure of us (for some value of us,
but it will seem to be semi-official), creating a scheme, which has the
potential to causes random third parties to start mailing dual life authors,
roughly like this:

J Random Third Party: Here's a patch to fix bug #42 in rt.perl.org
Module maintainer: I don't think that it's the right way to fix it
J Random Third Party: But it fixes bug #42 in rt.perl.org
Module maintainer: And introduces these other problems
J Random Third Party: But bug #42 is part of the bug bounty scheme
Module maintainer: That doesn't make this the right fix
J Random Third Party: They're going to pay me $200, but you're blocking it.
[insert abuse to taste]

or

J Random Third Party: Here's a patch to fix bug #42 in rt.perl.org
J Random Third Party: Did you get my e-mail?
J Random Third Party: Does this e-mail address work?

J Random Third Party: Dear core committers, please apply this patch, as I've
put the work in and YOU OWE ME $200 because YOU SAID
YOU WOULD PAY ME.

I decided not to try to flesh out how to make it work with dual life modules
where the maintainer wants to participate. The issues were roughly:

The intent was to make something simple and transparent enough to allow
everyone to claim money from it, even the people committing and judging.

There are enough core committers, and other people generally involved, that
it's possible to find (at least) two other people with sufficient technical
background to adjudicate if someone's patch is suspect. I think it can be
made to work, and be seen to be working, even if the bug, test and patch are
all created by the same person, and that person is one of the judges.

For the toolchain modules, for example, I'm not sure that there are
sufficient knowledgeable people to make this work. But if we think there are,
and the maintainers want to opt in and participate, it's good.

Nicholas Clark

nick at ccl4

May 31, 2009, 3:30 AM

Post #8 of 30 (911 views)
Permalink

Re: spending other people's money [In reply to]

On Sat, May 30, 2009 at 01:55:08PM +0100, Nicholas Clark wrote:

> 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
> virtues:
>
> 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.

That should be "tries", not "ties".

Also, as "Hubris" was the virtue that I had to figure out how to fit, I'm not
sure that that's the best definition. The idea comes from me thinking
"How I can I spend the money as quickly as possible, with the least effort"
but actually that's not a problem. To quote Corion:

Hey, for 50k, I'll step forward and say "I can do big things if you pay me
for a while.

"Big things", like moving place, getting a new phone number, and not coming
to my Perl Mongers group anymore ;)

It's actually "How can I spend the money as quickly as possible, with the
least effort, and then be given more money to repeat the trick?"
So the revised scale of virtues is

Laziness: It requires nearly no up front effort to organise
Impatience: It tries to spend as much money as rapidly as possible
Hubris: People will actually give *more* money to keep it going

It may fail on any or all of the above. Of the 3, I'll be most irked if it
fails to spend [other people's] money.

Meanwhile, I'm going to gratuitously mention the 5.10.1 bug list bug just
because I can: http://rt.perl.org/rt3/Ticket/Display.html?id=66092

> 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.

The reason for that number is that it's the same as for the Perl 6 microgrants:

http://www.perlfoundation.org/march_22_2007_best_practical_sponsors_perl_6_microgrants

I believe that those grants have much less approval overhead than the regular
grant committee grants, or the Hague grants (specifically, just 2 people), so
I was hoping that similar small cash numbers could be approved similarly
efficiently.

Also in this plan, [other people's] money is only paid out 100% in arrears,
for work done. There's no assessment needed for "is this person likely to do
what they say they will", or "are they going to take too long". There's no
need to (attempt to) claw back money, or write it off, if a grant is paid
out to someone who then doesn't do things.

The only problem might be that if it's TPF's money we're trying to spend, they
may not be able to pay to nationals or residents of Cuba, Iran, Syria, Sudan,
North Korea, or Burma. So probably we need to make that clear.

Nicholas Clark

schwern at pobox

May 31, 2009, 12:07 PM

Post #9 of 30 (908 views)
Permalink

Re: spending other people's money [In reply to]

Nicholas Clark wrote:
> On Sat, May 30, 2009 at 10:11:15PM -0700, Michael G Schwern wrote:
>> Nicholas Clark wrote:
>>> And the crazy scheme is: Offer bug bounties on every open Perl 5 bug*
>> Argh! Why didn't this come up two months ago when I was broke and unemployed
>> and not committed to a full time job?
>
> Well, there are various reasons why *I* didn't suggest anything then.
>
> 1: It was looking like Richard was going to have the time to look into
> spending booking.com's money usefully
> 2: Whilst I was aware that Vienna.pm still had money to spend, I wasn't aware
> how much it was
> 3: I wasn't fully aware of the number of bugs that Dave thinks he wants to
> investigate before 5.10.1

That was supposed to have a ;) on it and it wasn't supposed to go to the list.
Oh well. Comedy fail.

--
"Clutter and overload are not an attribute of information,
they are failures of design"
-- Edward Tufte

liz at dijkmat

May 31, 2009, 12:11 PM

Post #10 of 30 (912 views)
Permalink

Re: spending other people's money [In reply to]

At 10:39 PM +0100 5/30/09, Nicholas Clark wrote:
>It's almost 6 months since booking.com 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.
>
> http://www.hsyndicate.org/news/4039070.html
> http://news.perlfoundation.org/2008/12/bookingcom_makes_a_major_contr.html
>
>
>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, vienna.pm still has around $35,000 surplus from YAPC::EU 2007 to spend
>on "advancements of Perl": http://use.perl.org/~domm/journal/39013
>
>
>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
>virtues:
>
>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*
>
>http://rt.perl.org/rt3/Search/Results.html?Query=Queue%3D%27perl5%27AND(Status%3D%27open%27ORStatus%3D%27new%27)
>
>
>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

FWIW, I like it!

At 1:17 PM +0100 5/31/09, Nicholas Clark wrote:
>It's actually "How can I spend the money as quickly as possible, with the
>least effort, and then be given more money to repeat the trick?"
>So the revised scale of virtues is
>
>Laziness: It requires nearly no up front effort to organise
>Impatience: It tries to spend as much money as rapidly as possible
>Hubris: People will actually give *more* money to keep it going

Count Dijkmat in!

Liz

pjf at perltraining

Jun 1, 2009, 1:37 AM

Post #11 of 30 (906 views)
Permalink

Re: spending other people's money [In reply to]

G'day Nicholas,

Nicholas Clark wrote:

[snip]

> 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*

I love it. I love it much more than giving a big hunk of money to a single
person. I especially love there's a threshold one needs to hit in order to
cash out.

I'm presuming the bounty will run for a fixed duration, after which the
bounties will be paid?

One rule to consider would be to allow teams to be valid entities for the
purposes of the bounty scheme. This allows (for example) a Perl Mongers
group to collectively get together and spend TPF's money, even though the
individuals inside that team may not reach the $500 threshold.

Cheerio,

Paul

--
Paul Fenwick <pjf [at] perltraining> | http://perltraining.com.au/
Director of Training | Ph: +61 3 9354 6001
Perl Training Australia | Fax: +61 3 9354 2681

nick at ccl4

Jun 1, 2009, 1:53 AM

Post #12 of 30 (907 views)
Permalink

Re: spending other people's money [In reply to]

On Mon, Jun 01, 2009 at 06:37:31PM +1000, Paul Fenwick wrote:
> G'day Nicholas,
>
> Nicholas Clark wrote:
>
> [snip]
>
> > 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*
>
> I love it. I love it much more than giving a big hunk of money to a single
> person. I especially love there's a threshold one needs to hit in order to
> cash out.
>
> I'm presuming the bounty will run for a fixed duration, after which the
> bounties will be paid?

No, the intent was that bounties can get paid as soon as the individual
claiming is over the cash out limit.

There is no intended duration. I'd like to keep going until there are zero
open bugs. All other things ignored, there isn't enough money currently
to do that.

> One rule to consider would be to allow teams to be valid entities for the
> purposes of the bounty scheme. This allows (for example) a Perl Mongers
> group to collectively get together and spend TPF's money, even though the
> individuals inside that team may not reach the $500 threshold.

Payment to an individual who has a bank account. Anything else gets
complicated.

If the individual wants to organise a team, and submit all fixes on behalf
of their team, that's fine. They also get the money, and the responsibility
of splitting it.

If a team wants to create a single outgoing address which all their mail
originates from, that's fine.

I think it's viable to allow individuals to agree to transfer their claimed
balance to another individual, so that that individual reaches the cash-out
limit, which provides de-facto teams. But I don't want to complicate
things with having to track teams, team affiliations, team disputes, etc.

Nicholas Clark

pjf at perltraining

Jun 1, 2009, 3:48 AM

Post #13 of 30 (907 views)
Permalink

Re: spending other people's money [In reply to]

G'day Nicholas / p5p,

Nicholas Clark wrote:

> There is no intended duration. I'd like to keep going until there are zero
> open bugs. All other things ignored, there isn't enough money currently
> to do that.

One of my reasons for thinking about a time duration is so that:

* It provides a point at which the rules can be adjusted without anyone
crying foul.
* It's a convenient time to add/remove judges, if required.
* It's a good time to change the bounty pumpking.
* It's a good time to extend the list of bugs which can be claimed.
* It means we don't have people complaining that they had $450 in unclaimed
bounties from six years ago, but now the bounty is closed / TPF has spent
the money / they want to be a pain.

We can have an expectation that the bounties will continue after each
period, and that bounties earned get rolled-over, but we only guarantee that
people will get their bounties if they reach the cash-out threshold before
the end of the current cycle.

> I think it's viable to allow individuals to agree to transfer their claimed
> balance to another individual, so that that individual reaches the cash-out
> limit, which provides de-facto teams. But I don't want to complicate
> things with having to track teams, team affiliations, team disputes, etc.

This is actually all the level of teaming that I'm after. ;)

Cheerio,

Paul

--
Paul Fenwick <pjf [at] perltraining> | http://perltraining.com.au/
Director of Training | Ph: +61 3 9354 6001
Perl Training Australia | Fax: +61 3 9354 2681

nick at ccl4

Jun 1, 2009, 4:03 AM

Post #14 of 30 (906 views)
Permalink

Re: spending other people's money [In reply to]

On Mon, Jun 01, 2009 at 08:48:33PM +1000, Paul Fenwick wrote:
> G'day Nicholas / p5p,
>
> Nicholas Clark wrote:
>
> > There is no intended duration. I'd like to keep going until there are zero
> > open bugs. All other things ignored, there isn't enough money currently
> > to do that.
>
> One of my reasons for thinking about a time duration is so that:
>
> * It provides a point at which the rules can be adjusted without anyone
> crying foul.

True. I already thought that I needed to clarify that the rules are that the
intent is to get bug fixes into the core, and getting money is a pleasant
side effect but NOT GUARANTEED. This isn't a contract to pay you anything.

> * It's a convenient time to add/remove judges, if required.

That needs to able to happen at any point.

> * It's a good time to change the bounty pumpking.

That needs to be able to happen at any point.

> * It's a good time to extend the list of bugs which can be claimed.

That needs to be able to happen at any point.

> * It means we don't have people complaining that they had $450 in unclaimed
> bounties from six years ago, but now the bounty is closed / TPF has spent
> the money / they want to be a pain.

Arguable. The scheme is already over-committed - there are more bugs than
there is bounty to pay for them. So "you snooze, you loose" applies - you
need to get over the threshold before the current money supply runs out
(current money supply is public and computable), else you will wait until
more money is donated. Possibly forever. But that needs to be clear up front.

If it appears that the scheme has stalled and there will never be more money
coming in ever, it could potentially be wound down with under-threshold
payments.

But there is already a complete lack of guarantee of payment - if you work on
something but it happens that someone else fixes it first, you can't claim.
If you work on something and your patch is never approved (despite feedback
and re-working, repeatedly), you can't claim.

> We can have an expectation that the bounties will continue after each
> period, and that bounties earned get rolled-over, but we only guarantee that
> people will get their bounties if they reach the cash-out threshold before
> the end of the current cycle.

I really don't want to define a cycle. I have no idea how fast this is going
to be.

Nicholas Clark

davidnicol at gmail

Jun 1, 2009, 8:35 AM

Post #15 of 30 (903 views)
Permalink

Re: spending other people's money [In reply to]

Disbursing this alleged eighty grand sounds like a perfect use for
"The Collaboratron" which is what I call my work in progress
governance and accounting system.

http://davidnicol.diaryland.com/090531_6.html

Wins compared with Nick's proposal:

1: p5p gets a business model, which is, we earn interest on our
endowment, and disburse that to our participants

2: p5p (or the endowment-interest-disbursing committee, or TPF:
whatever existing or new entity takes this role) gets a formal
governance system

3: claims can be entered for work already done, work done before the
beginning of the disbursement program.

4: no crappy is-a-contract/isn't-a-contract mishigas. Since there's
no limit on the pool of "hours you worked on this" it becomes
perfectly possible to do bug-fixes on clear contract terms.

(I think Nick's claim that "it isn't a contract" is specious. Working
on something not intrinsically amusing in exchange for an expectation
of money on completion is exactly a contract; the fact that there
isn't yet an internet court of small claims with any standing to file
a lawsuit for an unpaid $500 in isn't going to make someone who thinks
they should have gotten paid and didn't any happier about their
situation)

nick at ccl4

Jun 1, 2009, 8:39 AM

Post #16 of 30 (901 views)
Permalink

Re: spending other people's money [In reply to]

On Mon, Jun 01, 2009 at 10:35:57AM -0500, David Nicol wrote:

> 4: no crappy is-a-contract/isn't-a-contract mishigas. Since there's
> no limit on the pool of "hours you worked on this" it becomes
> perfectly possible to do bug-fixes on clear contract terms.
>
> (I think Nick's claim that "it isn't a contract" is specious. Working
> on something not intrinsically amusing in exchange for an expectation
> of money on completion is exactly a contract; the fact that there
> isn't yet an internet court of small claims with any standing to file
> a lawsuit for an unpaid $500 in isn't going to make someone who thinks
> they should have gotten paid and didn't any happier about their
> situation)

Then I need to be clearer that "you are not guaranteed to get paid" and
"If you don't like this, then don't start".

Your choice of word "expectation" is key here. The correct expectation must
be set.

Nicholas Clark

nick at ccl4

Jun 1, 2009, 8:45 AM

Post #17 of 30 (905 views)
Permalink

Re: spending other people's money [In reply to]

On Mon, Jun 01, 2009 at 10:35:57AM -0500, David Nicol wrote:
> Disbursing this alleged eighty grand sounds like a perfect use for
> "The Collaboratron" which is what I call my work in progress
> governance and accounting system.
>
> http://davidnicol.diaryland.com/090531_6.html
>
> Wins compared with Nick's proposal:
>
> 1: p5p gets a business model, which is, we earn interest on our
> endowment, and disburse that to our participants
>
> 2: p5p (or the endowment-interest-disbursing committee, or TPF:
> whatever existing or new entity takes this role) gets a formal
> governance system
>
> 3: claims can be entered for work already done, work done before the
> beginning of the disbursement program.
>
> 4: no crappy is-a-contract/isn't-a-contract mishigas. Since there's
> no limit on the pool of "hours you worked on this" it becomes
> perfectly possible to do bug-fixes on clear contract terms.

Losses over Nick's proposal:

I see this:

2: thoroughly inventory the amount of time that has been put in, by all
involved, somehow (probably by creating some rough guidelines and having
participants self-account); this amount becomes each person's share. Shares
can be called for instance "porting hours" with a standard one share per
hour allocation

Until "somehow" is defined, your plan is a non-starter.

For the rough and ready version, if we're counting existing work too, we just
pay all the money to Jarkko, and be done. That is even more KISS than than
my plan, let alone yours. Far less administrative overhead.

Nicholas Clark

craig.a.berry at gmail

Jun 1, 2009, 12:11 PM

Post #18 of 30 (902 views)
Permalink

Re: spending other people's money [In reply to]

On Mon, Jun 1, 2009 at 10:35 AM, David Nicol <davidnicol [at] gmail> wrote:
> Disbursing this alleged eighty grand sounds like a perfect use for
> "The Collaboratron" which is what I call my work in progress
> governance and accounting system.
>
> http://davidnicol.diaryland.com/090531_6.html

Thanks for trying to help, but to me this seems almost entirely
opposite of what's needed in the current situation. An endowment model
might make sense in other circumstances but brings a lot of
administrative baggage with it and may not even be compatible with the
terms of the current gifts.

For several reasons, using the money to reward future results is far
preferable to using it to compensate for effort (possibly already)
expended. The goals as I understand them are to encourage volunteer
involvement and obtain tangible improvements in the code. Paying
people by the hour or finding people who've already contributed and
giving them money might sound like wonderful gestures of decency and
fairness but are impractical and don't do anything to meet those
goals.

>�Working
> on something not intrinsically amusing in exchange for an expectation
> of money on completion is exactly a contract;

But it *is* intrinsically amusing, or haven't you fixed any bugs in
the core lately? ;-)

I think the bug bounties would be more like award money for contest
winners rather than compensation for employment. Maybe that's still a
contract (I don't know, IANAL), but if it is it's a very narrow one
where the finality of the judges' decisions would be clearly stated in
it.

schwern at pobox

Jun 1, 2009, 1:03 PM

Post #19 of 30 (902 views)
Permalink

Re: spending other people's money [In reply to]

Nicholas Clark wrote:
> On Sat, May 30, 2009 at 10:15:50PM -0700, Michael G Schwern wrote:
>> Nicholas Clark wrote:
>>> 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.
>
> ^^that definition^^
>
>>> 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.
>
> ^^applies here^^
>
>> Awww. I was going to code myself a new car.
>
> I don't object to that, and I'm sure car manufactures don't object either.

I was implying that I can write a bunch of bugs in MakeMaker and then get paid
to "fix" them. This came up in a Dilbert cartoon (that I can't find) a while ago.

There's a conflict of interest there. I don't know how much we have to
practically worry about it. Some language about "in good faith" should be
sufficient.

> The reason for explicitly wanting to exclude dual life modules where the
> maintainer isn't involved is that the rules for claiming include having
> the code committed.

Yep, I've struggled with this before. Either you do what you're doing, make
sure the maintainer is on board, or you commit to maintaining a forked version
of their module. It depends a lot on which, CPAN or perl, is considered to be
upstream.

> There are enough core committers, and other people generally involved, that
> it's possible to find (at least) two other people with sufficient technical
> background to adjudicate if someone's patch is suspect. I think it can be
> made to work, and be seen to be working, even if the bug, test and patch are
> all created by the same person, and that person is one of the judges.
>
> For the toolchain modules, for example, I'm not sure that there are
> sufficient knowledgeable people to make this work. But if we think there are,
> and the maintainers want to opt in and participate, it's good.

Consider this me opting in MakeMaker and Test::More. Toolchain modules are
precisely where tangible love energy (ie. $money$) will do a lot of good.

All in all, +1 with unicorn sparkles!

--
170. Not allowed to "defect" to OPFOR during training missions.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/

nick at ccl4

Jun 1, 2009, 1:11 PM

Post #20 of 30 (905 views)
Permalink

Re: spending other people's money [In reply to]

On Mon, Jun 01, 2009 at 02:11:31PM -0500, Craig A. Berry wrote:

> I think the bug bounties would be more like award money for contest
> winners rather than compensation for employment. Maybe that's still a
> contract (I don't know, IANAL), but if it is it's a very narrow one
> where the finality of the judges' decisions would be clearly stated in
> it.

I've asked for advice on this matter. No news until the weekend.

It's surprised me that the denizens of #p5p are already sufficiently amused
by the whole idea that several have openly started digging into and closing
bugs, despite the realisation that they could build up a strategic patch
reserve. :-)

[ Compare with the first comment on http://use.perl.org/~Alias/journal/38698 ]

There hasn't actually been any money spent yet, and there's already a spike
in the commit rate. This is a great confidence trick - I wonder when they're
going to rumble it.

Meanwhile, I estimate that a mere quarter of a million dollars would be
adequate to put bounties on all existing bugs. That's not infeasible. :-)
Actually paying out might be though :-(

Not that I think that it would be a good idea to commit anything near that
much money to something that hasn't been trialed yet. Nor do I think that
if "we" (for some value of someone else) had $2.5e5 to spend, that would
necessarily be the best use for it.

Nicholas Clark

steve.peters at gmail

Jun 1, 2009, 1:31 PM

Post #21 of 30 (902 views)
Permalink

Re: spending other people's money [In reply to]

On Mon, Jun 1, 2009 at 3:11 PM, Nicholas Clark <nick [at] ccl4> wrote:
>
>
> I've asked for advice on this matter. No news until the weekend.
>
> It's surprised me that the denizens of #p5p are already sufficiently amused
> by the whole idea that several have openly started digging into and closing
> bugs, despite the realisation that they could build up a strategic patch
> reserve. :-)
>

Not too worry. There is strategic patch reserve on an old hard-drive
somewhere in my basement with test scripts of a few hundred bugs ;-)

Steve

nick at ccl4

Jun 1, 2009, 1:37 PM

Post #22 of 30 (901 views)
Permalink

Re: spending other people's money [In reply to]

On Mon, Jun 01, 2009 at 03:31:53PM -0500, Steve Peters wrote:
> On Mon, Jun 1, 2009 at 3:11 PM, Nicholas Clark <nick [at] ccl4> wrote:
> >
> >
> > I've asked for advice on this matter. No news until the weekend.
> >
> > It's surprised me that the denizens of #p5p are already sufficiently amused
> > by the whole idea that several have openly started digging into and closing
> > bugs, despite the realisation that they could build up a strategic patch
> > reserve. :-)
> >
>
> Not too worry. There is strategic patch reserve on an old hard-drive
> somewhere in my basement with test scripts of a few hundred bugs ;-)

Ruh-roh!

At the proposed $25 a pop for a TODO test, that could be worth $5000 if there
are 200 still open. Double that if each can be combined with a valid git
bisect. That's without actually fixing any of the bugs.

Gosh. That means that that hard drive is actually worth something. You'd
better keep it safe.

There's a revised draft for the plan which ends

Remember, we consider running out of money to be a success. We have no
feel for how long it will take to exhaust the money.

Might be quite fast.

Nicholas Clark

acme at astray

Nov 5, 2009, 12:57 AM

Post #23 of 30 (623 views)
Permalink

Re: spending other people's money [In reply to]

2009/5/30 Nicholas Clark <nick [at] ccl4>:

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

I just found a paper at OOPSLA 2009 on "A Market-Based Approach to
Software Evolution"

http://www.eecs.harvard.edu/~malvika/ons00025-bacon.pdf

...which points in the same direction as Nicholas' grand plan.

L�on

Richard.Foley at rfi

Nov 5, 2009, 2:03 AM

Post #24 of 30 (623 views)
Permalink

Re: spending other people's money [In reply to]

This was a damned good idea, to do something concrete for Perl. Nearly 6
months later has anything happened with it? Has TPF:

1. approved the idea?

2. allocated (freely donated) funds?

3. created a procedure/team to handle the administration of this effort?

...yet?

--
Richard Foley
Ciao - shorter than aufwiedersehen

http://www.rfi.net/

On Saturday 30 May 2009 14:55:08 Nicholas Clark wrote:
> It's almost 6 months since booking.com 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.
>
> http://www.hsyndicate.org/news/4039070.html
> http://news.perlfoundation.org/2008/12/bookingcom_makes_a_major_contr.html
>
>
> 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, vienna.pm still has around $35,000 surplus from YAPC::EU 2007 to spend
> on "advancements of Perl": http://use.perl.org/~domm/journal/39013
>
>
> 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
> virtues:
>
> 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*
>
>
http://rt.perl.org/rt3/Search/Results.html?Query=Queue%3D%27perl5%27AND(Status%3D%27open%27ORStatus%3D%27new%27)
>
>
> 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
> needed.
>
> 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".
>
> http://rt.perl.org/rt3/Public/Bug/Display.html?id=66092
>
> 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
> http://perl5.git.perl.org/perl.git and is not reverted within 14 days.
> (or a release, whichever comes sooner)
>
> "marked as duplicate" or "closed" should be done in rt.cpan.org 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. :-)
>

nick at ccl4

Nov 5, 2009, 2:20 AM

Post #25 of 30 (627 views)
Permalink

Re: spending other people's money [In reply to]

On Thu, Nov 05, 2009 at 11:03:57AM +0100, Richard Foley wrote:
> This was a damned good idea, to do something concrete for Perl. Nearly 6
> months later has anything happened with it? Has TPF:
>
> 1. approved the idea?
>
> 2. allocated (freely donated) funds?
>
> 3. created a procedure/team to handle the administration of this effort?

I don't know the answers to any of these.

I do know that I (no longer) have the time to get it started, nor to
organise it. I had spoken to some people privately about 6 months ago, and
I know that subsequently at least one I'd spoken with was aware that I no
longer had time and so wasn't able to carry it forward. A couple of others
have asked since, and I have said that I wasn't able to carry it forward.

I made no application to TPF for funds to run this, because I hadn't got
very far before I ran out of time, certainly not enough to need money.

I would be very happy for anyone else to take the idea and run with it
(I had hoped that that was obvious from the start). Perl shouldn't stall
just because I run out of time.

Nicholas Clark

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads