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.
Your message seems to have two points: that the current brainstorming
phase is so chaotic that it's hard to see how anything good can come
from it, and that nobody is planning the teams and people that will
do the work. I'll address them one at a time.
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.
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.
You're right that it's very unclear how RFCs will be accepted or
rejected. It's become obvious from the variety of RFCs proposed that
Perl cannot be designed by committee. That's why there's one person
designated as the language architect: Larry. He's said he'll be
grouping the RFCs into "definitely accept", "maybe", and "definitely
reject" (perhaps more shades of "maybe" there). I think he'll also
be coming up with suggested changes of his own: he's been working on
formal interfaces, I know.
Perhaps Larry could shed some light on how he's going and what he's
planning to do? (hint, hint, Larry)
Now on to the human side of things. I spent the last few weeks
reading a crapload of project management and software development
books, trying to see what problems other people have identified and
how they've solved them. That's why there wasn't much discussion on
this in the first place: I've been trying to get a baseline of clue on
the subject before starting discussions.
Just lately I've been starting to think about, in greater detail, the
remaining stages of development will go. I've been trying to
articulate those thoughts in email--your "grim future" message was a
reply to one of my messages, in fact. So I feel like we've started
to look at teams and team structure.
I've been thinking about how to structure design and development in
such a way that any given task is being worked on by only a few
people. When the possibility for parallel development comes up (e.g.,
fleshing out the language specification and the test cases), I'm
trying to see how to let lots of people work on it without having the
email flood of the current mailing lists. This isn't something I'm
going to pull out of my ass: I'm sending these messages because I want
everyone to be able to suggest and improve the development process.
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'm trying to shine the flashlight into the future and guess at how
development should/will proceed. If *anyone* has suggestions or
advice for this, let 'em rip. This isn't a vacuum, this isn't
management by fiat, this is a group effort.
So, in short, I agree that the current situation is chaotic, but I
don't think that it could have been improved or that it will be fatal.
I agree that we're going to need to focus on development and people,
and I've been starting to do that over the last week. And piping up
with your concerns is the best thing you could do: problems can't be
solved if there's no communication.
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?]
Risk: That huge amounts of email will swamp developers.
What we're doing about that:
* planning to use small teams in development and design
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.
[this risk won't kill the project, though, merely hurt peoples' feelings]
If you want to propose other risks, please go ahead. I've put this
first list at:
http://dev.perl.org/pm/risks.html
where I'm starting to develop some more of the project management
documents so everyone knows the big picture.
Nat
