Re: Late review management (Re: [Icar] independence of reviews; variability)

At 2:58 PM -0800 3/10/04, David Meyer wrote:
>  >>  Sometimes, though, we seem to question those assumption,
>  >> and we end up adding structures, policies or processes that are
>>>  intended to protect us from the results of our own consensus-driven
>>>  decisions.  I think that is (and has been) a mistake.
>
>	I couldn't really parse the last sentence in this
>	paragraph, i.e., what do you think is the mistake,
>	questioning the assumptions or adding structures,
>	policies, or processes?

I meant that I believe it is (and has been) a mistake to add new 
structures, policies and procedures at the end of the process that 
are intended to protect us from the less-than-perfect results of the 
WG consensus process, because I don't believe that is the most 
effective way to produce good work.

It's not that I think we should let small, insular WGs run amok and 
then blindly publish everything that they produce.  However, I think 
that we would do better to offer community guidance and input during 
the development of new work (through review, for instance) than to 
try to block that work at the end.

There is really nothing new in what I'm saying...  Most modern 
engineering organizations have reached the point where they know that 
more bugs can be found and corrected, with less schedule impact, 
through early review (such as design and code review) than by quality 
checks at the end of the process (such as traditional 
post-development QA processes).

IMO, we do need some type of evaluation at the end (as a final check 
to detect and correct failures earlier in the process), but the 
current situation where a large percentage of the work of the IETF is 
blocked and modified after the WG believes it is finished, is 
pathological.  IMO, we can't fix this problem at the end (by just 
publishing the work, for example) we need to fix it at the beginning 
(in the WGs). An important way to try to fix this problem is to get 
more community input/review, including review and guidance from IETF 
leaderhship, earlier in the process.

Margaret

_______________________________________________
Icar mailing list
Icar@ietf.org
https://www1.ietf.org/mailman/listinfo/icar