Subject: Concrete example of editor/WG inefficiencies

From: Pekka Savola <[email-masked]>
Date: Tue, 18 Nov 2003 17:55:42 +0200 (EET)

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

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 18 Nov 2003 10:08:10 -0700 (MST)

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.