Concrete example of editor/WG inefficiencies

Alex Rousskov rousskov at measurement-factory.com
Tue Nov 18 18:08:10 CET 2003


Pekka,

	Thanks a lot for posting a concrete example!

	I strongly disagree with your implication (in the subject line
and in the text) that the problem is with editors, chairs, and other
WG inefficiencies. IMO, your example clearly illustrates a much larger
scope of the problems we are facing:

	- Top reviewers are doing sloppy reviews because
	  they assume that working groups cannot handle tough ones

	- Some working groups produce sloppy documents because
	  they assume that top reviewers are doing sloppy reviews

	- Some working groups waste energy and miss deadlines because
	  they assume that top reviewers are doing their job well

	- Some working groups cannot handle tough reviews because
	  they lack the tools, education, and process

	- There is no top management that can force both
	  layers to do the right thing and that can order
	  the tools development and education

If we just change the top level, the lower levels would complain that
they lack the skills and the tools to match new tougher requirements.
If we just provide tools and education for the lower level, there will
be not enough incentive for them to use the tools and knowledge. Thus,
our biggest problem is that our problems are so interrelated that we
cannot accurately describe (not to mention solve) one of them in
isolation.

I agree that lowering expectations to solve these problems is not a
good idea, but we should not be talking about solution here... :-)

Thank you,

Alex.

On Tue, 18 Nov 2003, Pekka Savola wrote:

> Hi,
>
> When helping Bert/Randy to review documents at the IESG through
> ops-dir, Bert stated that we should focus on major issues (while nits
> etc. would be OK as well, but whether they'd be fixed would be up to
> the authors etc.).  I hope I interpreted that well.
>
> The reasons for this stance were (quoting Bert, with permission):
>
> - some editors/authors seem to need long turnaround times for
>   even the simplest changes
> - when you let them make changes, the WG-chairs and ADs need to check
>   that they made them correctly and did not sneak new stuff into
>   the doc that we did not agree on
> - some people use WORD to produce doc, then do manual editing to
>   remove stupid word-side-effects and so often make stupid errors
>   and so we end up wasting more cycles that needed.
>
> .. I can see the problems here, but this really, really seems to be a
> huge process problem in other fronts: inefficient editors and chairs,
> the use of wrong tools if fixing a few nits is too difficult etc.
>
> For every one of the three points above, you could continue ", but
> this is really a separate problem on its own, that is, XXXXX."
>
> We adjust the work habits and quality to cope for low performance, and
> expect the editors/WG-chairs/etc. to perform badly. Not sure whether
> that's a good idea.
>
> I think this should already be covered in the problem statement draft,
> but bringing up as an explicit example of a seemingly failing document
> improvement process.
>
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>
>


More information about the Problem-statement mailing list