Hi all,
I am concerned by the following trends:
* Number of outstanding Discusses is growing. (Thanks to Jari's data)
* The extent of text changes as part of Discuss Resolution is increasing
(I have only anecdotal evidence on this; perhaps others have statistics).
* In some cases, members of the IESG are pretty much writing core parts
of documents (or worse yet make authors iterate until the text is
satisfactory), overruling WG consensus, based on personal opinions or
citing solicited reviews.
There are a number of derivative trends as well:
* ADs who cannot convince working groups seem to use the threat of
DISCUSS to get their way.
* I would have thought document shepherds represent and defend working
group consensus and shepherding ADs defend the completeness, accuracy,
relevance of the drafts and defend their assessment of the IETF
consensus. But, increasingly, it seems to fall on an AD holding a
DISCUSS position, and authors to discuss and agree on text which becomes
finalized without any other review.
(Note: I am a guilty party in some of these cases, as document author
and document shepherd. In all cases, I seem to have looked for an
expedient way out rather than find a solution to what seems to be
problematic).
* One of the new trends seems to be to use DISCUSS to include
applicability statements in current drafts to avoid potential DISCUSS
positions on future drafts.
That or some variation of that is status quo. It should not be that
way. I would like to see a better definition of the roles of the WG,
authors of a document, document shepherds, shepherding ADs and other ADs
in our standards process.
I would like to hear others' opinions (I was going to put together a
draft with some ideas on how we might define these roles, but I want to
hear others' thoughts before I do that) on this topic.
thanks,
Lakshminath
On 6/25/2008 4:37 AM, Jari Arkko wrote:
<deleted text>
That being said, it is beneficial to understand what is happening and
what changes are occurring in the process. Or understand where
improvements might have a negligible vs. visible impact.
One of the things that the IESG has been concerned about recently is
that the number of outstanding Discusses is growing. We talked about
this in our May retreat and identified some actions to help reduce this
problem. For instance, better tool support so that the ADs would better
see the different things that are waiting for their action, getting the
document shepherds better involved in the resolution process, informing
authors how they should respond to Discusses, using RFC Editor notes to
make small changes when the authors are slow in producing a new version,
better checks of documents before they come to telechats (e.g., to
ensure that formal syntax in a document is free of errors), etc. These
would be in addition to the usual things we'd do, like debate whether
the Discuss was within the Discuss criteria, whether the issue is real,
try to ensure that the AD and the authors are being responsive over
e-mail, etc.
Another interesting area to think about is the time that our processes
take. For instance, documents that go through me take on the average
five months from publication request to approval. But there is a lot of
variation. This time includes everything from AD review, IETF Last Call
to IESG review and waiting for document revisions, etc. One interesting
piece of information is that documents that require no revision during
this process are very rare, but they go through the system about five
times as fast. If we look at the (unreliable) substates, they appear to
indicate that the IESG processing time is divided roughly 1:2:1 for
waiting on AD, authors, and mandatory process waits like last call periods.
I am working to extend the analysis a little bit further by including
individual draft and WG document stages. You see some of the results of
this in the third URL above, but I'd like to understand what fraction of
the overall draft-smith-00 to RFC time is taken by the different stages
for all IETF work, and how the stages have developed over time.
Comments and suggestions on what would be useful to measure are welcome.
Jari
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf