Tim Starling wrote:
In my experience, volunteer developers don't like
being told what to do.
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.
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.
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.
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.
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.
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. [...]
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.
In our project, this role of oracle is filled by
Brion, and I'd like to
think to a lesser extent myself.
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