This is getting silly.
[EMAIL PROTECTED] (Michael Lazzaro) writes:
> Seriously, don't patronize me: it won't get you anywhere productive,
> and it just ticks me off. I am not _unaware_ of the current Perl6
> dynamics and management decisions; on the contrary, I am observing
> that the current approach has resulted in _profoundly_ little progress
> per unit time, given the pool of available labor and talent at our
> disposal, and has resulted in us revisiting decisions *repeatedly*
> whenever previous designs are more fully worked out.
I think you're equating a pool of "available" talent and labor with
a pool of willing talent and labour. Everyone is willing to offer
suggestions, but few people - you being one of the few - are willing
to put the time into thrashing these suggestions out into a coherent
set of documentation.
Here is my suggested solution to the problem.
1) We find a team of volunteers who are willing to "own" the task of
converting each Apocalypse into a complete design. If nobody wants
to write the Perl 6 user manual, then we might as well give up and
go home now. So far we only need to find four, though, so it Might
Just Work.
2) Each Apocalypse gets a mailing list. Questions about a particular
topic ought to be directed to the appropriate list. (Where possible.)
3) Each "subdesigner" is responsible both for monitoring p6l and the
Apo mailing list for discussion of the topics covered, (and pointing
people to the archives where necessary) and also raising questions
when the fleshing-out process gets stuck. Delegation of some of the
process to other mailing list members is encouraged.
4) The subdesigner (or his appointed secretary[1]) summarizes the thread,
ideally in the following manner:
What does this code output?
...
I think it should output XXX, because ...
Joe Bloggs thinks it should output YYY, because ...
5) This summary is taken back to p6l, where interaction between Apocalypses
can be thrashed out. Further points are noted and added to the summary.
An arbitrary moratorium should be set when the summary is posted to p6l.
6) The summary gets sent to Allison, who circulates it to the rest of the
design team, and an arbitration is made.
7) The arbitration gets turned into two things: a test case, and a change
to the user manual.
8) Both are submitted back to Allison for checking.
Does that save any time or make any sense?
[1] You can tell I've been rereading MMM...
--
I'm surrounded by electromagnetic radiation all the time. There are radio
stations broadcasting at lots of kW, other people using phones, the police,
[...] the X-rays coming from my monitor, and God help us, the sun. I figure
I have better things to worry about than getting cancer from the three or
four minutes a day I spend on my cell phone. - Dave Brown.
