Ok,

Iv'e seen this debate - I will try to put something constructive:-

Richard

=Head1 My opinions of the Perl6 RFC process

=head2 Where do I come from this?  

I am an amauteur perl user who uses it on web sites and for other admin
tasks.  Have I looked at the code? - Yes.  Do I know the insides well? - No. 
Do I know anything about brainstorming? - Yes (I do a lot).  Do I know
anything about regexes? (the topic of most of my RFCs) - Yes when at
University (admittadly years ago) I did some cutting edge work in this
area - so I think I new what I was doing.  I do lurk p5p but have only posted
a few times.  I look after the [EMAIL PROTECTED] mailing list and I am just in
the process of slowly taking over the pumpkin for the riscos port.  I do
however take part in many standards activities in the realm of telecoms (my
day job). 

=head2 Brainstorming -

The first part of any brainstorming is to let any and all ideas flow -
without lots of argument.  By all means ask people what they meant, or point
out other ways to achieve the same, but always allow ideas however silly to
be suggested.

Then, but only after the ideas have flowed some filtering is important, some
ideas will be good, some will be good but difficult, some might have some
good points but also some bad.  Seriously consider each suggestion and
categorise the results to "Yes", "Probably", "Yes but not this way", etc.

Publish those simple results, and if time allows permit a second round (or
more) of discussion.

Brainstorming groups must not need chairs who dictate, but rather moderators
to give every one a chance to speak and maintain momentum. each group
possibly needs a "Scribe" who sits outside the discusions to note anything of
importance that might get missed.  This second role is perhaps less important
with email based brainstorming.

First one needs ideas
Then, they are checked for "Can this be done"
Then, prioitise and / or find volunteers 

It is totally wrong in a brainstorm about the perl6 language to initially
be concerned with implementation.  The second stage of filtering should be
very aware of implementation, but not the first.

=head2 What went wrong with the RFC process?

Too much led by the existing perl5 gurus, rather than people who are good
at managing brainstorming.  (The Gurus should be there as part of the
discussion but they are not the best moderators).

To little of Larry.  

The process has ground to a halt, it needs to keep up some momentum, with
interim conclusions and areas still open regualarly posted. 

The interpretation of the meaning of the status was at best variable, and
there was no defined process to make RFCs frozen.  The definitions and the
process should have been defined CLEARLY.

The process needs to continue in the future so that ideas for perlN.M can
all be submitted by anyone with a good idea, to be incorperated as and when
time and effort are available.  The person with the idea, is unlikely to
have the knowledge and time to push the idea through a p5p swamp - I know
I have given up in the past.

If the groups were in a position to make decisions, they should be formally
proposed, and then formally voted.  The process needs in advance to decide
what constitutes agreement.  Concencus (as at the ITU), Rough concencus
(as in the IETF), 2/3 (as in many standards bodies), 50%+1 (as in a 
many things)?  I hope we do not have to go to this.

Discuss and build ideas - dont argue.

Peace.

Richard



-- 

[EMAIL PROTECTED]

Reply via email to