RE: When to adopt a draft as a WG doc (was RE: "IETF work is done on the mailing lists")

["George, Wes" <[e-mail]>]

> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Barry Leiba
>
> There is no formal process that involves "adopting" anything.  Working
> group chairs appoint document editors (this is in RFC 2418, Section
> 6.3).  There is nothing anywhere that specifies how the first version of
> a WG document is formed.
[WEG] snip
> We seem to have settled into
> a culture of starting with individual submissions and "adopting"
> them, but there's nothing that requires that

[WEG] What this says to me is that we are adhering to an ad hoc or de facto process, and therefore in most cases we're not really thinking about why we do it, or even if we should, we're just going with the flow of past precedent. AKA, "that's the way we've always done it/that's just the way we do things around here". We wouldn't do that with a technical protocol that we defined, we'd update the standard to reflect reality as implemented. So why are we behaving differently with our internal protocol?
If it works and people like it, let's document it so that it can be applied consistently. If people think it's unnecessary and we should stick to the documentation as written (no adoption), let's do that. If we actively *don't* want an IETF-wide procedure here, we can even document that the process for WG adoption of drafts is WG-specific and could document those specifics in a WG policies wiki document maintained by the chairs. There are plenty of WGs that have specific ways that they like to handle document submission, reviews, and requests for agenda time. It might be useful to have that all in one place so that people can know what's expected of them.
>
> So, yes, the chairs get to decide how they want to seed the document
> development process, and they have a pretty free hand in making that
> decision.  Your ADs are always there for further guidance if you need or
> want it.  But there's no formal process for that, and I think that's how
> we want it to be.
[WEG] Barry, I respectfully disagree. The whole point I'm making here (and Geoff underscored nicely) is that it's currently too variable and too reliant on a small group of individual volunteers implementing it correctly. When things are not documented, we are dependent on having leadership who innately know how to do the right thing. But that leadership turns over fairly frequently. so assuming that we'll always have people in leadership who know how to make this process work "correctly" without some guidance is pretty risky, IMO. As the IETF ages and grows, and personnel (participants and leaders) turn over, the oral tradition breaks down in a hurry. Further, no matter how good the individuals are at their "jobs" within the IETF, applying undocumented policy (especially doing it inconsistently) looks to the outside world as arbitrary and capricious, or as centralizing authority, and that's not at all productive in an open standards development process. It can be discouraging to new participants, because it contributes to the overwhelming nature of figuring out how to get started as a new document author, and it can make the process seem more closed than it actually is.

It is quite possible to document a policy or procedure with directional guidance and enough flexibility to allow intelligent adults to think for themselves and adapt to the reality of the situation during implementation. I'm willing to work on an update to 2418 to cover this apparent gap, but I'd like to know whether others agree that this is a problem (and are willing to work on the update with me).

Wes George


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.