Re: Critique available

Your critique is related to an issue that I have thought about
for a while: what exactly was the RFC process to accomplish. If one views
the RFC process as
"brainstorming", then the RFC process unfortunately rolled two entirely
separate functions, the process of brainstorming and the process of
analyzing the results into one difficult and complex process - it is
analogous to making a method or a class do too many things. Brainstorming is
simply to generate a list of ideas and they can be completely crazy or on
the other hand brilliant; ene does not think about implementation issues,
prior art issues etc. It is an exercise in creativity - free association -
it is even fun. The idea is to do it quickly without a lot of thinking.
Thinking comes later!

I submit that no matter what the originators of the RFC process originally
proposed, the process was implicitly a brainstorming process. I say this
because if the entire Perl community could participate then necessarily that
means anyone with an idea ought to submit her idea regardless of her
technical knowledge. So, implementation issues be damned. Separate mailing
lists be damned. Here is a rough outline showing how I would **now** suggest
a process for generating ideas for Perl 6. I think points 1), and 2) are the
important

1)Brainstorm
2)Discuss the ideas for a brief time to get a sense of how the community
feels about the proposed feature.
3)People who are internals and language experts do some initial sorting -
the obviously crazy ideas go - those that can't be implemented for technical
reasons or those that don't work from experience with other languages etc.
Further, ideas such as Mr. Cozens RFC called "Perl should stay Perl" or
something like that would stay in some pile.
4)Mr. Wall takes a look at ALL the piles in 3) and does further sorting as
he deems necessary into categories.
5)The collective expertise of the World discusses further technical
impediments if any remain - implications etc. according to whatever criteria
the experts decide are necessary (eg: - backward compatability etc.  and
also from RFC generated criteria. Note that the ideas/RFCs are in categories
which enables an easier discussion format. It is here that issues of
implemenation are hashed out - and where neophyte developer wannabees learn
something about why X cannot be done or why X is done this way or why X is
brilliant.
6)Refine the process further if necessary.
7)Mr. Wall develops the specification
8)Develop testing strategies QA/QC etc
9)Review
etc.


I agree with Mr. Dominus and Mr. Cozens that the process as implemented was
difficult and frustrating. I commend the efforts of Mr. Torkington and
others to try to establish a process. I would even go so far as to say that
perhaps you all should even consider placing the RFCs aside temporarily and
going through a limited application of the first few steps of the
above-described process. Then go back and see how many of the RFCs and the
more recently generated ideas overlap.

A constructive critique that outlines what can be learned about an
experience many have shared can be very positive. Finesse, diplomacy,
decorum and humility also have their place. It wasn't until I observed the
RFC process start to fly apart a bit that I realized there was a flaw. That
is, the RFC process, as handled by the managers seemed initially like it
would be fine (at least OK) and only from observation did I learn otherwise.
(There are probably many who thought that it would not work at all. But
perhaps I am atypically humble?) The RFC process was set up to do too much,
something I argue that (only?) in hindsight is crystal clear.

----- Original Message -----
From: Mark-Jason Dominus <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
Sent: Thursday, November 02, 2000 9:11 AM
Subject: Critique available


>
> My critique of the Perl 6 RFC process and following discussion is now
> available at
>
>         http://www.perl.com/pub/2000/11/perl6rfc.html
>
> Mark-Jason Dominus                    [email protected]
> I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.html for
details.
>