[Foundation-l] Developer poll results

Thu Aug 26 15:42:12 UTC 2004

>Anthere-

Hi Erik

>thanks for taking the time to poll the developers and summarize their  
>opinions. It looks like it was a lot of work.

Hmmm, it was, but it was also extremely interesting to know more on what people do and think ;-)

>I think almost all of us agree that a developer conference/meetup would be  
>a good idea. 

Yes, I agree. This is something very important to do.

>> Second, money in exchange of tasks. This would be
>> money directly paid by the Foundation to thank some
>> developers for their work.
>> The board is willing to give it a try.

>I presume that means you, Angela and Jimbo agree. Have you also talked to  
>Michael and Tim? Are they involved in these meetings?

Yes, Tim and Michael are aware of this discussion and did not oppose the trial.

>What amount of money do you anticipate can be allocated for this trial  
>period, if we proceed further on this?

>I would suggest a setup wherein a team (committee) of two or three people  
>within Wikimedia who
>a) do *not* want to be reimbursed for development work
>b) have a solid technical understanding
>decide upon tasks which they consider to be of high priority to the  
>foundation. Developers can *propose* tasks to this team through a defined  
>process (e.g. mailing list or board).

>I would then suggest that the current page "Development tasks" on Meta  
>(which is presently somewhat redundant with the roadmap) be turned into an  
>official Wikimedia page, where only the aforementioned team can put up  
>tasks, and any developer can then state:
>- when they can start working on the task
>- how long they believe they will need to finish the task
>- under which conditions (for free/contract/etc.) they would be willing to  
>complete the task.

>The committee could immediately *decline* certain offers, but they would  
>have to wait at least about 7 days before accepting an offer for any  
>particular task, so that all developers have a chance to volunteer.

>Money is paid depending on the conditions which the developers and the  
>committee agree on. Validation may in some cases occur in stages, but  
>again, this depends on the individual committee/developer relationship.

>Is this general process agreeable to you?

>Regards,

>Erik

Hummmm. What I will say below is my own opinion, which may or may not be the opinion of the board, but which I will give you anyway to get the ball rolling (so to speak).

You made an excellent comment when you suggested that the committee be made in good part of people not willing to ask for those contracts. I absolutely agree with this. It is potentially problematic that one be judge and party. Obviously, we also need the committee to be able to know the project in and out from a technical perspective, to be able to see what is feasible, how long the development will take, whether highly necessary or not...

Problem : most people likely to be part of the committee (ie, knowing very well the application) are potentially interested by contracts.
I would add that it seems much more reasonable, both for *social reasons* and as a *guarantee of quality*, that contracts be rather made with people who know the application well. Though not a mandatory requirement, that makes sense.

So... who would be in that committee ? Would you suggest that we pick up people knowing rather less the application or would you suggest that we ask some experienced developers to voluntarily refuse any contract to be able to be part of the committee ? That seems a bad solution to me.

I have another perspective to offer.

We are in a situation where the Foundation will give money to developers in exchange of work.

This should be beneficial to the developers themselves AND to the Foundation (given that the Foundation shall represent the interest of the project on its whole).
So, in terms of benefits, two parties are interested, and though I trust all the developers will also have in mind the benefits brought to the project itself, we must not neglect the fact that those accepting contracts will also do it for their own benefit.

With regards to this consideration, it was interesting to consider carefully the answers given to the question "what are to your opinion the benefits of the bounty or similar system ?". Many answers were given from the perspective of the developper only. Not from the perspective of the project. Which is just fair ;-)
But we should consider the proposal both from the developer perspective and from the Foundation perspective. A contract is of quality only if both parties have high certainties on the benefits they will get from the contract.

The potential benefits mentionned for the Foundation (ie, essentially for the project) are : 
* Increasing well-being of the developper. Well-being meaning a developper able to pay the rent and buy food, and not needing to do small jobs to pay his studies, will have more time to do development job for Wikipedia
* Increasing happiness of the developper -> possibly more satisfaction and recognition feeling makes a developper more hard working, hence more work done and work done more quickly
* Getting things done which are rarely (if ever) done, because too boring, or too difficult or taking too much time (this essentially is about daily administration of servers, bug hunting, documentation writing, database and co)
* Prioritizing tasks (ie, orienting development toward certain directions supported by the Foundation, e.g. development of internationalization feature of fix of the database rather than fancy but not so necessary tasks)

If the Foundation gives a certain amount of cash to a committee, and have no lever on the money use decisions, then benefit 1 and 2 will probably occur, but benefits number 3 and 4 are absolutely not guaranteed. Even if the developers chosen to be the committee do not make contracts, we have no guarantee they will have the same priorities than the Foundation. No ?

Well... what does that suggest to you ?

---------------------------------
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.