Subject: document approval speed [Re: [newtrk] last call on newtrk draft charetr]

From: Pekka Savola <[email-masked]>
Date: Wed, 28 Jan 2004 23:16:02 +0200 (EET)

On Wed, 28 Jan 2004, Spencer Dawkins wrote:
> > saying that the rules for Non-Statandards track documents should also
> > be improved.  You are saying these are not directly addressed by
> 
> I would like to see us be able to publish Informational documents
> within one IETF meeting cycle. I think that's realistic (or should
> be) - within a month is not, and I don't think it's required, and
> taking two or three meeting cycles for an Informational document just
> sucks the life out of the authors (please feel free to disagree,
> anyone).

Sure, publishing things faster would not hurt.  But it's useful to try 
to identify the bottlenecks; they necessary aren't those one might 
think they are.

I'm not sure if a solution to these problems, unless we're willing to 
sacrifice quality of the documents, can be found by revising the 
standards (or non-standards) tracks.

[[ OK -- now we're getting a bit off-topic for this list but I'm not 
sure where this would better belong -- maybe the solutions, but this 
seems to be important so I'll continue here ]]

Personally, I've seen that at least in many cases you actually *can*
frast-track a publication if you really want (i.e., you're willing to
*personally* sweat to work on the document).  Of course, the
RFC-editor queue is still quite long, so you can't get (basically)
anything out in a meeting cycle, but I assume you'd be satisfied with
an approval of getting published.

Example: a BCP (about 15 pages of meat) document I co-authored; the 
history:

2003-05-22 -00 version
[trying to come up with people to review it, with little success]
2003-07-10  IETF 4 week LC initiated
2003-08  -01 version to fix issuess raised at LC
2003-08  -02 version to fix further fix issues raised at LC
[waiting for about 3 months for one person to send feedback he 
 promised, which never arrived; finally we gave up trying]
2003-12-18 on IESG telechat (the -02 version)
2003-12-23 produce -03 version which addresses IESG feedback
2003-12-31 IESG members have checked that their issues have been addressed
2004-01-06 approved for publication

Actually, the IESG review was the fastest part in the publication!  
The slowest was waiting for a reviewer to supply text (but didn't), 
and trying to find folks who could review the document giving 
something else as feedback than something like "yeah, looks good".

Other things I've noted which usually cause a lot of delay:

 - DOCUMENT EDITORS.  Some folks seem to be enjoying (well, actually
not -- they probably have different priorities etc. -- but it shows
this way) sitting on a document for a couple of months and doing
nothing about revising it or resolving the issues.  Sometimes this is
not the editor's fault though -- see "WG / reviewer input" below.

 - Authors or the design teams.  Tried to create a document with a 
group of people, where the number of people is greater than 3?  Forget 
about it.  After the initial interest, nobody (except maybe 1-2 
people) put any hours in the document anymore, and even more time is 
wasted for the 1-2 people waiting for the rest of the "responsible" 
folks to provide their feedback on the pending revisions of the 
document.

 - WG or reviewer input.  When you publish a document, you should get 
input from reviewers or the community quite fast, and the most 
important thing about the input is a go/no-go decision, whether to 
continue with the work.

  In the presence of WGs and conflicting interests in general, the
lack of active participation when having to do several tough decisions
(which should be reflected in the document) often results in either a)
those decisions being delayed, delaying the document revision,
delaying the document, or b) going by a couple of persons' input on
the subject, which may be counterproductive, and may result in
re-opening "closed" issues later on.

...

This is a bit pessimistic view, but unfortunately, it seems to be 
pretty close to the mark in most cases! :-/

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html