At 12:38 PM 11/15/00 -0500, Adam Turoff wrote:
>On Wed, Nov 15, 2000 at 04:42:58PM +0000, Nicholas Clark wrote:
> > On Wed, Nov 15, 2000 at 11:35:56AM -0500, Adam Turoff wrote:
> > > All PDDs (like RFCs) need to start with 'Status: Developing' by default.
> > > Since statuses like 'Standard', 'Rejected', etc. have Real Meaning (tm),
> > > there should be some review in place (by a WGC, principal,
> etc.). Statuses
> > > like 'Withdrawn' and 'Superceded' should be accepted from PDD
> authors/teams.
> >
> > They don't need to start with "Developing" if they start with status
> > "Experimental" or "Proposed"
>
>The real issue is that there needs to be at least one default status that
>the author can assign. With RFCs, Developing referred to the RFC, and
>with PDDs, they refer to the underlying design/interface/implementation.
>I think I misread Dan's re-interpretation of 'Developing'.
Probably. I don't think I was clear enough the first time around.
> > > This is a community process. I'm uncomfortable leaving such decisions
> > > to such a small number of people. How about nominating/electing a
> >
> > If PDDs start as "Proposed" without needing any approval does this remove
> > the problem of a small group having a stranglehold?
>
>No, because Dan has proposed a 'core team' of sorts, where any one
>of the (at least) three team members cast a final vote (towards
>'standard' or 'rejected').
Yup.
>Keep in mind that this isn't "Dan's Perl API" (or Nat's, or Larry's),
>but "Our Perl API". I'd be more comfortable if at least two people
>(from a group of >4) were involved in making any decision that
>carries weight, or if there were a process of rotating the WGC as
>necessary to avoid Pumpking Burnout (tm).
This only holds while the primary design takes place--what happens when
perl 6 hits maintenance/extended development is still up in the air. (read:
That's *not* my problem... :)
I want perl 6's internal API to have the same sort of artistic integrity
that the language has. That's not, unfortunately, possible with everyone
having equal say. I'd like it to be otherwise, but that's just not possible
with people involved.
The point is definitely *not* to do any sort of consolidation of power.
Anyone reasonably sane, capable, and interested is welcome to chair any of
the internals design lists and/or be responsible for shepherding a PDD to
solidity. That's fine with me. (In fact I'd be thrilled if the design was
handled by a host of folks that weren't me)
My job is to play the Larry role for the backstage stuff. Luckily for me
the task is reasonably partitionable, so I don't have nearly the burden of
consolidating things that Larry does at the language level, and what I'm
trying (perhaps clumsily) to do is farm out pieces to people while making
sure we don't start with the sort of mess we have now with perl 5.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
