Mailing List Archive

Anthere wrote:

> I would like that all developers (others may
> participate as well of course) help setting up a list
> to define how development tasks completed could be
> rewarded.

Heh. I was going to suggest a payment system for developers after my
project deadline next week.

The core idea of my proposal is:

* developers should be paid every month
* developers who received money the previous month receive "voting
power" (i.e. power to influence the proportions how money will be
distributed) for the next month
* how much total money is awarded for the completion of a particular
feature or bugfix is determined by the donors: with every donation,
the donor can say "this-and-this much of this donation (but no more
than, say, 25% of the donation) should go towards rewarding the
completion of this-and-that feature/bugfix".

Then the whole thing would work approx. like this:

* Alice donates $20 and says "$5 of this should go to feature X"
* Bob donates $50 and says "$10 of this should go to feature X"
* Charlie The Developer suggests an implementation plan for X
* Doris The Developer makes a major start towards feature X
* Emily The Developer finishes feature X
* Developers who received money last month vote on what percentage of
the feature was done by Charlie, Doris and Emily
* The votes are averaged out and may yield something like
Charlie - 5%, Doris - 75%, Emily - 20%
* Charlie's Wikimedia account is increased by 75¢
* Doris's Wikimedia account is increased by $11.25
* Emily's account is increased by $3.00

This is my basic idea.

It is in part modelled after the "Bazaar" that LiveJournal once used to
have (albeit only for one month, ironically).
Timwi

On Sun, 25 Jul 2004 02:26:49 +0100, Timwi <timwi@gmx.net> wrote:
> Anthere wrote:
>
> > I would like that all developers (others may
> > participate as well of course) help setting up a list
> > to define how development tasks completed could be
> > rewarded.
>
> Heh. I was going to suggest a payment system for developers after my
> project deadline next week.
>
> The core idea of my proposal is:
>
> * developers should be paid every month
> * developers who received money the previous month receive "voting
> power" (i.e. power to influence the proportions how money will be
> distributed) for the next month
> * how much total money is awarded for the completion of a particular
> feature or bugfix is determined by the donors: with every donation,
> the donor can say "this-and-this much of this donation (but no more
> than, say, 25% of the donation) should go towards rewarding the
> completion of this-and-that feature/bugfix".
>
> Then the whole thing would work approx. like this:
>
> * Alice donates $20 and says "$5 of this should go to feature X"
> * Bob donates $50 and says "$10 of this should go to feature X"
> * Charlie The Developer suggests an implementation plan for X
> * Doris The Developer makes a major start towards feature X
> * Emily The Developer finishes feature X
> * Developers who received money last month vote on what percentage of
> the feature was done by Charlie, Doris and Emily
> * The votes are averaged out and may yield something like
> Charlie - 5%, Doris - 75%, Emily - 20%
> * Charlie's Wikimedia account is increased by 75¢
> * Doris's Wikimedia account is increased by $11.25
> * Emily's account is increased by $3.00
>
> This is my basic idea.
>
> It is in part modelled after the "Bazaar" that LiveJournal once used to
> have (albeit only for one month, ironically).
> Timwi

It seems too convoluted and prone to conflicts to work effectively
IMO. Donors are unlikely to identify all the features/bugs needing
work. Likewise, we're unlikely to reach an agreement to the
percentages. It might also lead to races between developers who start
stepping on each other's work in order to get more money.

--
[[en:User:Dori]]

Dori wrote:

> It seems too convoluted and prone to conflicts to work effectively
> IMO. Donors are unlikely to identify all the features/bugs needing
> work.

Aw, come on now. That's not really a problem. We can certainly give
Jimbo and/or the Board of Trustees the additional power to assign up to
25% of unassigned donated money to development task.

The point is just anyone who personally thinks a particular feature or
bug is really overdue, should be able to directly encourage developers
by saying "I offer you $xyz for this". The more important a bug or
feature is to the community, the greater the amount of money will be.

> Likewise, we're unlikely to reach an agreement to the
> percentages.

I think you didn't understand this part. There is no agreement or
consensus required. Everyone specifies percentages of their own (in some
sort of designated user interface; they're kept secret). At the end of
the month, they are averaged out.

Example:
* I say: Alice has done 5% of feature X, Bob has done 10%, Charlie has
done 85%.
* You say: Alice has done 15% of feature X, Bob has done 15%, Charlie
has done 70%.
* Jimbo says: Alice has done 10% of feature X, Bob has done 26%, Charlie
has done 64%.

Then the end-result will be: Alice - 10%, Bob - 17%, Charlie - 73%.

Of course, the averaging could optionally be weighted by the amount of
money the voters received in the previous month.

> It might also lead to races between developers who start
> stepping on each other's work in order to get more money.

I don't think that will be a problem. Such blatantly un-co-operative
people can easily be penalised with very low percentages. People will
know they will get more money if they use their common sense to behave
within proper forms of etiquette.

Timwi

Timwi wrote:

> The point is just anyone who personally thinks a particular feature or
> bug is really overdue, should be able to directly encourage developers
> by saying "I offer you $xyz for this". The more important a bug or
> feature is to the community, the greater the amount of money will be.

The point is that we currently have no decision making procedure for
which features _should_ be implemented.

Encouraging donators to offer money for features they want to be
realized would make the situation even worse since most people not
involved in coding don't "wish" things which would be necessary from a
developer's point of view.

My vision:
* we should clean up these immense lists of feature wishes
* we should establish priorities
* the developers should say what makes sense and what doesn't
* the developers should give an estimate for the most important features:
** how complicated it is to implement
** if someone's willing to do it
** or if there should be a bounty set out for it (because noone wants to
do it or noone can do it)

greetings,
elian

On Sun, 25 Jul 2004 02:51:19 +0100, Timwi <timwi@gmx.net> wrote:
> Dori wrote:
>
> > It seems too convoluted and prone to conflicts to work effectively
> > IMO. Donors are unlikely to identify all the features/bugs needing
> > work.
>
> Aw, come on now. That's not really a problem. We can certainly give
> Jimbo and/or the Board of Trustees the additional power to assign up to
> 25% of unassigned donated money to development task.

I don't know that we could. It might piss off some donors if we said
we'll use this for hardware, and we end up using it for software
features. Although we do have some money that wasn't donated, and we
could certainly advertise that doners could donate toward a specific
feature/bug. However, that's not what I was talking about. I simply
thought that the process had too many rules to be properly understood
and to work well.

>
> The point is just anyone who personally thinks a particular feature or
> bug is really overdue, should be able to directly encourage developers
> by saying "I offer you $xyz for this". The more important a bug or
> feature is to the community, the greater the amount of money will be.
>
> > Likewise, we're unlikely to reach an agreement to the
> > percentages.
>
> I think you didn't understand this part. There is no agreement or
> consensus required. Everyone specifies percentages of their own (in some
> sort of designated user interface; they're kept secret). At the end of
> the month, they are averaged out.

Yes, I did misunderstand that. I still don't see it as a fair method
though. Averages could give some screwey results which might leave
people who made more work, receive less compensation.

>
> Example:
> * I say: Alice has done 5% of feature X, Bob has done 10%, Charlie has
> done 85%.
> * You say: Alice has done 15% of feature X, Bob has done 15%, Charlie
> has done 70%.
> * Jimbo says: Alice has done 10% of feature X, Bob has done 26%, Charlie
> has done 64%.
>
> Then the end-result will be: Alice - 10%, Bob - 17%, Charlie - 73%.
>
> Of course, the averaging could optionally be weighted by the amount of
> money the voters received in the previous month.
>
> > It might also lead to races between developers who start
> > stepping on each other's work in order to get more money.
>
> I don't think that will be a problem. Such blatantly un-co-operative
> people can easily be penalised with very low percentages. People will
> know they will get more money if they use their common sense to behave
> within proper forms of etiquette.

It's not necessarily blatant. It could even be inadvertant, or it
could be as simple as if I am going to do this part I might as well do
that part or I would prefer that part to work like I plan it. Coding
is much harder to do collaboratively than editing (unless we're
talking about unrelated parts).

--
[[en:User:Dori]]

Dori wrote:
> On Sun, 25 Jul 2004 02:51:19 +0100, Timwi <timwi@gmx.net> wrote:
>
>>Dori wrote:
>>
>>
>>>It seems too convoluted and prone to conflicts to work effectively
>>>IMO. Donors are unlikely to identify all the features/bugs needing
>>>work.
>>
>>Aw, come on now. That's not really a problem. We can certainly give
>>Jimbo and/or the Board of Trustees the additional power to assign up to
>>25% of unassigned donated money to development task.
>
>
> I don't know that we could. It might piss off some donors if we said
> we'll use this for hardware, and we end up using it for software
> features. Although we do have some money that wasn't donated, and we
> could certainly advertise that doners could donate toward a specific
> feature/bug.

The prize we had in june has no string attached, so might be spent for
rewarding developers.
Also, I think that membership fees and donation should make it possible
that the donor or the member may be able to indicate how if wishes part
of the money to be spent. For now, I suppose we have three "specials"
* I would prefer that this be assigned to hardware
* I would prefer that this be assigned to software development
* I would prefer that this be assigned to wikireaders production
distribution

ant

Elisabeth Bauer wrote:
> Timwi wrote:
>
>> The point is just anyone who personally thinks a particular feature or
>> bug is really overdue, should be able to directly encourage developers
>> by saying "I offer you $xyz for this". The more important a bug or
>> feature is to the community, the greater the amount of money will be.
>
>
> The point is that we currently have no decision making procedure for
> which features _should_ be implemented.
>
> Encouraging donators to offer money for features they want to be
> realized would make the situation even worse since most people not
> involved in coding don't "wish" things which would be necessary from a
> developer's point of view.
>
> My vision:
> * we should clean up these immense lists of feature wishes
> * we should establish priorities
> * the developers should say what makes sense and what doesn't
> * the developers should give an estimate for the most important features:
> ** how complicated it is to implement
> ** if someone's willing to do it
> ** or if there should be a bounty set out for it (because noone wants to
> do it or noone can do it)
>
> greetings,
> elian

Elian is absolutely correct.

I just had a look at
http://meta.wikimedia.org/wiki/MediaWiki_1.3_comments_and_bug_reports

Ihmo, that is just as a village pump; it might be nice to sweep the
floor sometimes :-)

On top of estimates listed by Elian, I would add estimate of "how long
could it take to be developped".

ant

Anthere wrote:
> I would like that all developers (others may
> participate as well of course) help setting up a list
> to define how development tasks completed could be
> rewarded.
>
> This will be followed by a public poll to define how
> the rewards would be perceived...
>
> and a private poll for developers to know what their
> opinion on the matter is
>
> Please, contribute to
> http://meta.wikimedia.org/wiki/Bounty
>
> thanks :-)

Hello,

Personally, having users happy when I fix a bug or implement a new
feature is enough for me. Imho a simple thanks through irc is more
rewarding than 10 US$.

--
Ashar Voultoiz

Elisabeth Bauer wrote:

> The point is that we currently have no decision making procedure for
> which features _should_ be implemented.

I wouldn't have thought this decision was particularly hard.

> Encouraging donators to offer money for features they want to be
> realized would make the situation even worse since most people not
> involved in coding don't "wish" things which would be necessary from a
> developer's point of view.

Again, as I said, 25% of the money that donors don't explicitly assign
to a bug or feature, should be assignable by someone else. The Board of
Trustees was a suggestion, but if you think the developers should have
some say about this, then certainly we can come up with an
averaging-percentage system for this too (and give the Board of Trustees
permanent voting power). Something like:

At the beginning of Month A,
* I say: Feature X is worth $10, Y is worth $20, Z is worth $25
* You say: Feature X is worth $10, Y is worth $50, Z isn't worth anything
* Jimbo says: Feature X is worth $22, Y is worth $26, Z is worth $11

Then we get: X = $14, Y = $32, Z = $12

Again, the averaging could optionally be weighted by voting power.

Timwi

Dori wrote:

> On Sun, 25 Jul 2004 02:51:19 +0100, Timwi <timwi@gmx.net> wrote:
>
>>>It seems too convoluted and prone to conflicts to work effectively
>>>IMO. Donors are unlikely to identify all the features/bugs needing
>>>work.
>>
>>Aw, come on now. That's not really a problem. We can certainly give
>>Jimbo and/or the Board of Trustees the additional power to assign up to
>>25% of unassigned donated money to development task.
>
> I don't know that we could. It might piss off some donors if we said
> we'll use this for hardware, and we end up using it for software
> features.

We shouldn't be saying we'll be using the money for anything particular.
That just ties our hands.

> I simply thought that the process had too many rules to be properly
> understood and to work well.

"Too many rules"? Are you saying it's too complicated and you don't
understand how it's supposed to work? It's not complicated at all; as I
said, the LiveJournal Bazaar worked similar to this, and developers
there were perfectly happy with it and understood how it worked.

If you have any specific questions about the system, feel free to ask.
Please don't dismiss it solely on the grounds that you don't understand
it; if you have any specific criticism that you think makes the system
unsuitable, I will happily accept that. Otherwise, I would really like
to give this a try, at least for a few month until we can definitely say
that it doesn't work well. I'll do all the necessary coding for the
voting interface, the averaging, etc.

> Yes, I did misunderstand that. I still don't see it as a fair method
> though. Averages could give some screwey results which might leave
> people who made more work, receive less compensation.

It is perfectly fair. Think about it. Who did "more" or "less" work is
completely subjective. Everyone has their own perception of what
percentage of the work was done by certain people. By averaging out the
percentages, we create some sort of "collective subjective judgment",
and everybody's own judgment will be part of it.

If you're afraid that people might cheat the system by giving ridiculous
percentages, this isn't a problem either. Firstly, only people who have
actually done development in the last month, and the Board of Trustees
perhaps, have voting power. You won't get much voting power if you're
not a responsible individual. Hence, when averaging stuff, the
"irresponsible percentages" will be given much less weight.

Additionally, of course, you shouldn't be able to vote for yourself. :)

>>>It might also lead to races between developers who start
>>>stepping on each other's work in order to get more money.
>>
>>I don't think that will be a problem. Such blatantly un-co-operative
>>people can easily be penalised with very low percentages. People will
>>know they will get more money if they use their common sense to behave
>>within proper forms of etiquette.
>
> It's not necessarily blatant. It could even be inadvertant, or it
> could be as simple as if I am going to do this part I might as well do
> that part or I would prefer that part to work like I plan it. Coding
> is much harder to do collaboratively than editing (unless we're
> talking about unrelated parts).

A bug or feature should be assigned to a particular developer (this is a
core feature of BugZilla, which I'm still hoping we will switch to in
the long run). It will be easy to enforce a policy that only the current
assignee of the bug may work on it. (I admit that the fact that this
worked in LiveJournal is no surprise because nobody has CVS access there
and people only submit patches to BugZilla. But even on Wikipedia, I
suppose CVS access should be given only to responsible developers who
will follow this rule.)

Any more questions? ;-)
Timwi