Developer payment

This page is kept for historical interest. Any policies mentioned may be obsolete. If you want to revive the topic, you can use the talk page or start a discussion on the community forum.

A system for payment to MediaWiki developers was first proposed by Eloquence, to increase the motivation for editors to carry out development tasks which they might otherwise not do or might do in a different order than desired by the Foundation. Supporters hope that such a system might help to get essential development done. The term "bounty" has been used to describe such a [proposed] payment.

In July 2004, Anthere started a discussion on this topic, to identify the benefits and drawbacks of a payment system. Eloquence explained his views on a payment system as well. Anthere then organised a developer payment poll for the developers to answer the question should there be a way to reward developers? If so, which are the possible ways?; the results of the poll were published in August 2004 at Developer payment poll/results.

Following the poll, the Wikimedia Foundation decided to accept a developer payment system for a trial period. The proposed system can be found below.

See also Donations:Putting your money where your mouth is

Made by Anthere. Please comment.

Note : I hope setting up this system is perceived at the same time as an opportunity to improve our organisation :-)

Unapproved edits to this proposal have been made by Tim Starling. For Anthere's original proposal see [1]
Unapproved copyedits have been made by Sj.

This is a trial
The trial period will be 4 months. It will use Wikimedia funds from the ars electronica prize, which had no strings attached. As the payment is potentially controversial, we will avoid using donor money for it, unless this use is explicitly mentioned in donation qualifications.

At the end of the trial period, we will assess the success of the trial. These will be not only technical, but also social, and feedback from the whole community will be welcome. We will wait for feedback now, during the trial, and at the end of the trial. We will not proceed with the trial if there is serious opposition from the whole community

-). We understand that there are both dangers and benefits to this proposal, which is why this is only a temporary decision.

Suggested steps
A proper developer committee should be established.

this is now done.

Development task page
The development tasks page should be updated, prioritized and clarified.
Anyone may add suggestions or comments to that page. It would be best if each suggestion were described in plain English (accessible to non-developers); its stage of development indicated (pending, in development, in CVS, etc...), and the names of the developers involved listed.
The developer committee can single out certain tasks, and call for proposals addressing these tasks.
Wikimedia may also advertise that it needs some task done, for example on the development task page, on wikitech-l, or directly on the developer liaison.

Proposals by each developer
A subpage of the development task page will be created, perhaps development task/payment. On this page, a developer can list a task s/he is ready to develop for money... or for free. All proposals should provide the following information:

• name of the interested developer (or team)
• dates of availability for starting development
• dates of availability for finishing development, if applicable
• estimated length of development (starting date & ending date, or hours or days of work required)
• payment proposed for the task
• method of payment (Paypal, etc.)

For each task listed on this page, there will be a period of at least two weeks during which all developers will have an opportunity to make offers. Tim might say, "I will develop this task at $20/hour, I will probably take 20 hours to complete it." Jens might say, "I will do this for free, but I can only start in February next year." I might say, "I will do this if you give me $400 once I deliver the code."

If there are volunteers who can complete the task within a timeframe acceptable to the steering committee, there will be no need to pay anyone. Payment is only an option when it is needed to accomplish the goals of the foundation.

Feedback from the developer committee
The developer committee should give its opinion on each task proposed (so as to ensure they fit into the general development scheme). The committee may suggest to the board which proposals to accept; the committee's suggestions will in large part be based on past experiences. The developer committee can also give its own prioritization of the tasks proposed.
The way to make these decisions is left up to the committee. One option could be a vote among the committee members, another option (less bureaucratic) could be that those who feel like it give their opinion. (Approval by 3 developers amongst the committee might be sufficient to ensure prioritization, and interest might be proportional to the committee's opinion.)

Making a contract decision
When Wikimedia is interested in paying for a task and one or several developers are interested in doing it for payment, the interested parties (Wikimedia Foundation and the developer(s)) will negotiate a mutually agreeable contract. Once a contract is formed between the developer and Wikimedia, payment is assured, as long as the developer completes the task within the defined timescale. Wikimedia will not be able to terminate the contract at will without payment, for the purpose of giving the contract to someone else or otherwise.

More than one developer or group of developers may offer to complete a particular task, and Wikimedia may well be inclined to accept the cheaper of two competing proposals. To encourage developers to complete tasks contracted to them, rather than to frivolously undercut other developers and then fail to complete the task, there should be a minimum acceptable payment; however, volunteer offers will be accepted.

The minimum payment amount could be suggested by the developer committee or a subset of DC (such as 3 people from the DC).

Requirements from the developer
The developer will engage oneself to finish the task—no payment will be issued for an unfinished task. The finished task should work properly. The developer will be asked to decently comment his code and provide necessary documentation. The developer committee will be asked its opinion on this matter.

The tough issue of bugs
The developer should provide working code. One will have a moral obligation toward the team to fix one's own bugs. The developer should provide testing procedures one has followed to check one's code before its final release. If bugs remain, the bugs will unfortunately have to be fixed by the team. We hope however, that moral pressure from the team will prevent this from happening; and it is unlikely that any additional tasks would be assigned to a developer who allowed this to happen.