Nat and I argued parts of this (I think this is included) at some length.
Actually, I think I drove him crazy getting specifics out of this.
Adam Turoff <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 14, 2000 at 05:59:40PM -0500, Dan Sugalski wrote:
> > 6) Only a WG chair, pumpking, or one of the principals (i.e. Me, Nat,
or
> > Larry, or our replacements) can mark a PDD as developing, standard,
or
> > superceded.
>
> This doesn't sound right.
I'm still waiting to find out whether a group will be submitting a) a
single PDD, b) multiple PDD's, or c) multiple PDD's merged into a single
PDD.
case pdd
a)
this makes sense as stated, I think
b)
this makes no sense
submitters would control their own PDD's except
only leader could stamp accepted
c)
submitters would control their own PDD's except
only leader could stamp PDD accepted and
only leader could stamp master PDD anything
esac
Okay, my bash is a bit off, but you get the idea.
If anyone is interested, I think that within groups, b or c sounds like a
logical approach to solving the problems at hand, since each person would
likely have a very very very specific problem area in mind. Method a
sounds a bit like a ... hmmm ... cluster-Muck, with everybody trying to
come up with bits and pieces of the same document rather than coming up
with ideas that end up in a single (or multiple) PDD to be submitted even
higher outside the working group. I'm thinking project management terms
here.
> 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.
FWIU, "Developing" would be after an initial proposal, and means it wasn't
tossed out at the first mention of it. It makes sense that it's a status
of its own.
> The RFC process accidentally required single-authorship for all RFCs.
> We should allow RFCs to be maintained by a group of collaborating
> authors (without forcing them to start a mailing list first). Any of
> these authors should be able to make updates and update the status
> as appropriate (e.g. Developing, Withdrawn, Superceded).
I think this is similar to what I'm suggesting with my a-b-c's above. I do
agree that single-authorship would be a management problem. But then,
multiple management could cause tangenting, but (according to EFNet #perl)
there's nothing wrong with discussing winnie the pooh from time to time
when burnout sets in. ;-))
Maybe sub PDD's (SPDDs) can be conceived of as "discussion", but I think
that perhaps in groups with big jobs, actual proposals about how minutiae
might be accompilshed could help set ideas in stone more than just
discussion, then discussion could have its proper place. If SPDD's are
used, it would be the responsibility of a team leader to collect the ideas
and come up with a main one that everyone needed to agree on, which should
be a simple diplomatic process and less overall work for the team leader
himself, and more thoughtful (full of thoughtoutedness) effort from the
team members.
> This is a community process. I'm uncomfortable leaving such decisions
> to such a small number of people. How about nominating/electing a
> core team that will be responsible for the API design, whereby a vote
> of 3/10 is needed to reject a PDD and a vote of 5/10 is needed to
accept
> a PDD? (The numbers 3, 5 and 10 are arbitrary, and used to demonstrate
> that this doesn't need to degenerate into review by committee.)
This is where Nat and I, I think, had a hurdle, and is the reason for my
reponse to this email. The concern that was expressed was the development
of the interests of a small group overriding the interests of the whole,
the creation of another perl-elite caste, etc. Nate, correct me if I have
it wrong PLEASE...
It is, within a single group, the responsibility of the team leader to
moderate discussion and lead the team to a unanymous decision. Within the
team, the leader could be removed by majority appeal, but otherwise has
authority in that area, and could not override the group. With the groups
as a collective, general election of a core team was shot down (I proposed
that), and I'm agreeing to the reasons for it... it's potentially
caste-building (that wasn't the reason, but I have my own reason too).
Since one team would not be familiar with issues within another group, it
would be a tremendous thing to ask of a "core team" to decide on all PDD's
including both their own and ones they aren't directly working with.
All in all, I think Dan's doing a good job making this make sense. I'm
just curious about the inner workings of a group.
