Re: Front-end delays

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> There has been a fair amount of effort in accelerating the tail end  
> of the document process, i.e., after IETF last call. It is unclear  
> whether this has succeeded (as there don't seem to be any published  
> measurements), but I believe that the main problem with timeliness is  
> now in the WG process itself. Each case is unique, but there are a  
> disturbing number of modest-size documents that have taken 3 to 5  
> years from first individual draft to RFC. In a separate message, I'll  
> have more process- and people-oriented suggestions, but here are some  
> simple things that would at least allow us to measure, and thus  
> manage, delays:
> 
> (1) Problem: Currently, the mapping between charter items and drafts  
> is often vague and those not intimately involved with the process are  
> often left to guess which draft(s) meant to address which charter item.

IMHO, at WG charter time we typically don't understand the problem
well enough to be specifying things like how many documents there should
be in the final product or what should be in those documents.    That,
and "published an I-D describing X" is not a very useful charter
milestone. To the extent we make milestones out of documents we should
require that the WG get rough consensus on those documents before they
are considered complete. 

The milestones we most need to track aren't the WG's final products,
but the preliminary steps, because the failure of a WG to address
important details early its lifetime is what seems to cause WGs to bog
down later.  

I don't see anything wrong with creating milestones like this:

- the WG needs to reach consensus on a document describing its
  scope in detail - design goals and non-goals, and identifying
  any effects that the WG's work might have on other concerns.
  this doesn't have to be published as an RFC, and it might 
  actually be better if it's not published as an RFC.  but it does
  need to get WG consensus.

- the WG needs to solicit external review of that document and 
  respond to that review and revise the document as appropriate

- the WG needs to entertain and review proposals for a solution
  (including soliciting external review)

- the proposers need to respond to review and revise their
  proposals

- the WG needs to choose one or more candidates for a solution
  from among the revised proposals

etc.

If we took pains to select useful milestones, a WG progress
tracker might be quite useful.

Keith

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]