Nathan Torkington wrote:
Thanks for that grim view, Alan. I've been looking around for someone
to act as the Devil's Advocate and say what might go wrong, so I was
happy to see this.
Glad to be of service ;-)
I agree that the current brainstorming is chaotic. I feel like that's
the nature of the beast, though. I think it's important to separate
your criticism of this brainstorming from the actual language design,
which hasn't yet been done. Right now we're getting input on what
people want. Then magic happens with Larry (I'll get back to that
soon). After that we can get down to the details of specifying the
language, nailing down the semantics and edge cases. Chaos in the
brainstorming phase won't necessarily (and please dear God don't let
it) be reflected in chaos in the specifications phase.
I don't believe in magic. I'm an engineer by profession, not an
astrologer. However, I will predict endless arguments when some of the
less than coherent proposals are rejected. In the end someone is going
to have to say 'No, it is not going in, now shut up.', Beware, at that
point I see portents of doom and despair
Your suggestion was to have moderated lists with a few people on each
list. That's more appropriate for the specifications phase and
architecture and software design phase, I think. I can't imagine
anything being done if the same free-for-all happened then as is
happening now.
Agreed.
I've been thinking that getting the approach roughed out takes
precedence over picking teams. You wouldn't know what you were being
picked for, for a start. There's definitely an art in deciding who
should work on what. If you have advice and suggestions, give 'em up,
baby!
I wish I had some glib advice to offer, but I don't. You have an
especially difficult task due to the geograpical distribution of the
likely team members, although this isn't in itself unsurmountable. I
suggest you do the blindingly obvious - look at the current p5p'ers,
figure out who has contributed in each area of interest and ask those
folks to form a team to work on the same area in p6. If new people want
to contribute, fine, but they should be integrated into an existing team
rather than be sent off to 'do their own thing'. A possible suggestion
is an apprenticeship approach - ask potential contributers to take on a
substantial but not critical-path part of the work, get them to complete
it and then have it reviewed by the other members of the team (you are
going to code reviews - right?) If everyone is happy then they can be
invited in.
I like the "risks" formulation of these concerns. Each risk is a
potential derailment of our train. So we need to list the risks and
make sure we're addressing them:
Risk: That nothing good will come of the brainstorming process because
good comments from people with experience are being lost in the flood
of messages.
What we're doing about that:
* pushing the output through Larry
[Yes, this addresses only part of the problem. Any suggestions for
other ways to solve this?]
The RFC mountain is way, way too high to be climbed by just one person,
let alone the output of the various mailing lists. What about a litlle
good old-fashioned dictatorship, or at least a Junta?
Risk: That not being selected for a team will offend developers,
causing them to leave.
What we're doing about that:
* identifying tasks (e.g., filling in specifications and test cases?)
can be done by as many who want
* ensuring the development process is open, so that everyone knows in
advance how it will work and nobody feels like it's an arbitrary
"management" (ha!) decision.
Please make strenuous efforts to lay out the ground rules as soon as
possible.
[this risk won't kill the project, though, merely hurt peoples' feelings]
It'll kill it if you hurt enough peoples feelings...
Alan Burlison
