We lost two of three *and* I missed actual discussion. It must not be my
night. :-)
On Tuesday 20 February 2001 20:32, Adam Turoff wrote:
> On Tue, Feb 20, 2001 at 05:42:01PM -0500, Dan Sugalski wrote:
> > At 02:38 PM 2/20/2001 -0800, Ask Bjoern Hansen wrote:
> > >How should the submission process work? As for the RFC's?
> >
> > Sounds good to me.
>
> Any additional constraints on acceptance criteria? PDD 0 describes
> an acceptable baseline on rejection (return incomplete submissions),
> but I daresay that we want something more strict.
I'm working on some automation for the actual format to help with this.
>
> For example, I doubt that we want or need three competing PDDs on
> Async I/O developing in the Standard track, but multiple PDDs on
> the same topic would be welcome if they were Experimental (or even
> Informational).
The idea, unlike the RFC process, wasn't that PDDs were to lead the
discussion. A PDD proposal was more or less a checkpoint in the
development process.
In this case, a thread runs on and on about I/O - sync versus async, roll
our own versus libc, etc. Everyone has their say, until a Deciding Factor
says - "We're going to roll our own async. Can someone write up a proposal
PDD?"
Now, any yahoo can write up a PDD for, say, libc stdio, and submit it. The
librarian (is he knows what is going on) can either reject it outright, or
forward it to the lists. (I think Proposals should be kept internal.)
The PDD Proposal should cover (and this is what I meant by comprehensive)
the previously exhausted arguments of why we're doing our own async i/o
versus other alternatives. (And the title should be "The I/O subsystem" or
something similar, not "async i/o")
If the Proposal is in the ballpark of why it was supposed to have been
written in the first place, the chair can move it to Developing, where it
gets fleshed out until it's a complete picture of what the subsystem should
(or will) be.
It *should* be comprehensive in scope, and applicable content. It should
give folks an idea of what was discussed, and why we came to the conclusion
that we did. (For instance, I didn't itemize every support position for
XML as the PDD format in PDD 0, but I did mention that there are a number
of proponents, that we had a discussion about it, but we are sticking with
POD for these reasons.)
>
> Would any other constraints help to promote discussion moving forward?
> The goal isn't to be burdensome on people actually volunteering their
> time, but to cut down on the crosstalk that doesn't lead to Real Work(tm).
The problem with the RFC expectation, much like the sublists, is that the
bulk of the discussion is done and over with long before someone takes
action. It's natural. It's going to happen. The mailing lists exists for
a reason. Let's discuss amongst ourselves before we speak with one voice.
The PDD should be that one voice - all the arguments should be done and
over with.
PDDs should be born with builtin maturity.
--
Bryan C. Warnock
[EMAIL PROTECTED]
