[Wikitech-l] The difficulty of collaborative design in a volunteer enviornment

Magnus Manske wrote: Forgive me for being jaded from past experience with MediaWiki development, but I care very little for plans. We have unbelievable numbers of plans piled up on meta and on the mailing list. The people who propose them generally overestimate the available developer workload, and fail to consider an important part of developer motivation. In my experience, volunteer developers don't like being told what to do. Part of the fun of coding comes from creative expression -- the joy that comes from having an idea, and carrying it through until you see it realised. By publishing plans, you destroy that motivation for anyone else who had the same idea, or might have had it in the future. What developers do when faced with this problem is they attempt to ignore all plans which have gone before. They invent their own, and fool themselves into thinking that their idea is truly creative and new. This allows them to regain the motivation that was lost. It's not surprising then that every MediaWiki developer has their own plans for database schema redesign. I'm not going to comment on their similarity for fear of negating the reason the reason for their existence. This curious aspect of volunteer psychology makes collaborative design very difficult. Fortunately there is an alternative which allows us to avoid the most obvious planning mistakes, and that is by the use of an oracle. It works like this. When you have an idea which is complex and prone to errors, you don't publish it, you privately discuss it with senior developers. These developers have been active with the project for a long time. They have had many ideas of their own which they haven't had time to code, they have read many public proposals, and they have had many private planning discussions. Hence they know a great deal about possible design directions. The oracle responds to an idea carefully, either saying that it sounds like a good idea, or explaining why it wouldn't work. They avoid bursting the developer's carefully constructed bubble by giving them mailing list references to identical proposals. The oracle should accept ideas which are slightly different to the way they would have done it -- those differences represent the creative expression which we are trying to preserve. There are a couple of problems with this scheme. One is that project knowledge is concentrated in the senior developers, so their loss is a great loss to the project. The other is that it discourages public discussion, and so limits the pool of collective wisdom. But there is no other way. Many developers simply will not code something that has been designed by someone else. In our project, this role of oracle is filled by Brion, and I'd like to think to a lesser extent myself. The oracle is a model, design knowledge is never truly concentrated in a single person. We have a number of knowledgable people on the project. And even the most senior developers need to discuss their own ideas among themselves. Magnus' plan sounds fine. -- Tim Starling