Frank Tobin has generously given me permission to forward his comments
to this list.

------- Forwarded Message

Date: Thu, 2 Nov 2000 00:31:42 -0600 (CST)
From: Frank Tobin <[EMAIL PROTECTED]>
Subject: Response to Critique of Perl 6 RFC Process
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hash: SHA1

I appreciated reading your critique of the RFC process.  I think one
problem that contributed to the mess of "mishandled" RFC's was that there
were no real written guidelines on what authors should do with RFC's in
various circumstances.

For example, when should an RFC be withdrawn?  How about withdrawn?  Does
withdrawn mean the RFC should be revoked because there is something
inherently bad about (e.g., wanting a perfect data structure), or can it
also mean the RFC is simply heavily disliked?  Does frozen mean "it looks
good, let's go for it", or does it mean "no further changes will improve
the RFC".

>From personal experience, I was the maintainer of RFC 357 (Perl should use
XML for docs instead of POD).  This generated a lot of criticism/debate.  
In general it seemed like the heavy majority of the Perl community was
against it.  I decided to mark the RFC as frozen, while adding a section
in the RFC about how the RFC was against it (although I didn't go into
much detail, I admit).  I decided against withdrawing it, because I felt
there wasn't anything inherently wrong about the RFC; it was just
disliked.  The problem seemed that "withdrawn" and "frozen" weren't
orthogonal choices.

Perhaps one problem was that there was only one field for the status of an
RFC.  Perhaps two were needed.  One of these would be "Closure:
Open/Closed", which would indicate the activeness of the RFC, and the
other would be "Resolution: Popular/Unpopular/AlreadyDone/Impossible/etc".
Maybe this would've given maintainers the ability to better describe the
status of the RFC; I know it would've made my choice easier.

- - --
Frank Tobin           

Version: GnuPG v1.0.4 (FreeBSD)
Comment: pgpenvelope 2.9.0 -


------- End of Forwarded Message

Reply via email to