Tim Starling schrieb: BTW, I've seen this mechanism work in Wikipedia many times. :-) Kurt

Erik Moeller wrote: It's a separate issue, but I think a solution to some cases of developer motivation would be to have good documentation and modular code so people can work on parts that interest them. I know I personally have had ideas I'd be willing to implement in the past, but my brief digging led me to the conclusion that I'd basically have to read through and understand the entire MediaWiki codebase before I could usefully add anything to it, and at that point I decided that while I was interested, I wasn't *that* interested. A bunch of the people proposing various extensions and whatnot on meta seem to be in the same boat---they could code up bits and pieces, but don't know how to hook into the larger codebase. Of course, this is another "plan with no implementation" --- writing the documentation and cleaning up the code would require me to read and understand it all first, which is exactly what I wish to avoid, as I have other projects I'm supposed to be working on full-time. =] -Mark

Tim Starling wrote: I half-disagree. In my experience, volunteer developers are discouraged when being told to do something that is difficult, or something they are not particularly interested in. However, I think being asked to do something can be an extremely efficient motivator, if the developer that is being asked personally feels there is potential for success (i.e. if they're interested, if it's easy to do, etc.). If you're asked to do something, then you know that once you've finished it someone will appreciate your work. I'm saying this because on LiveJournal developers used to be very motivated and encouraged even though they've always been told what to do (not just by Brad, but also by fellow volunteers attempting to represent Brad's interets). Fixing bugs or writing smallish features in LiveJournal was easy because their software is well organised, modular, structured, and easy to get into. LiveJournal volunteer development has come to a halt not because people were told what to do, but exactly because they are no longer told: instead, suggestions and even finished patches are ignored and left uncommented-on, developers feel unappreciated, become frustrated and leave. According to this, being told what to do is discouraging on MediaWiki only because there are few things that are easy or interesting. I don't think like that. Some people might, but I don't. Yes, part of the fun of coding comes from creative expression -- but for some people, it might not be the biggest part. For some people, I'm sure the biggest part is the social recognition that results from success (being able to say "I made this!" and hearing other people reply "Well done!"). Both personalities like to publish their plans because, like a finished implementation, a plan is also (1) a form of creative expression, and (2) something that can harvest social recognition ("Nice plan!" etc.). On the contrary, if someone else publishes a plan, there are three possible ways in which I can react. Either I think the plan is bad and I think I can come up with something better; or I think the plan is good and I might only have minor suggestions for improvement or perhaps not even that; or there is something important about the plan that I don't understand (e.g. why it's supposed to be better) or that I can't judge (e.g. its advantages and disadvantages). Unfortunately, the third is the most common; many very competent developers' weakest skill is communication, and often a plan includes just the bare implementation idea, not the information on why it's better and what its advantages are. No, I don't think I fool myself into thinking that my ideas are truly creative and new, but I fool myself into thinking that my ideas are good ones. I explicitly do not pass judgment over plans I read that fall into the third category above, but subconciously it feels like the ideas I understand best (which, inevitably, are my own) are somehow better. Your idea would essentially create a hierarchy. Those that you call "senior developers" would be regarded as having a superior social status, and would seem like they have more say in the development of the software. This isn't necessarily bad with regard to the software; every largish project needs some management and guidance. But whether this is good in the social sense, I'm not sure. Unfortunately, that's not very many people. I have continuous trouble contacting either of you for a conversation. I would have been more than happy to discuss my database schema redesign ideas (or any other ideas, for that matter) with you (or anyone, for that matter), but it never works out. You're either too busy, or have to leave too soon, or you're simply not interested enough. I am not trying to point fingers here; don't get me wrong. This isn't a complaint. This is just where your oracle idea is slightly flawed. We either need more of those oracle people (which defeats the purpose of your idea, because then within the oracle group you have the same issues again), or we need an oracle member that is very much dedicated to listening to and evaluating plans and ideas, and not occupying themselves too much with coding. Such a person is unlikely to be found. Greetings, Timwi