problem statement: Engineering practice vs. management practices

[Thomas Narten]

> 2.2 The IETF does not Consistently use Effective Engineering Practices
> 
>    For an organization with 'engineering' in its title and participants
>    who are likely to trot out the statement "Trust me, I'm an engineer!"
>    when confronted with the need to find a solution to a particularly
>    knotty problem, the IETF has, at least in some cases, extremely
>    ineffective Engineering Practices.


> 2.7 Working Group Practices can make Issue Closure Difficult
> 

I have a hard time understanding the difference between 2.2 and 2.7
and parts of 2.6. I _think_ section 2.2 is trying to say something
about how we don't actually use more rigorous and formal internal
processes that would help us avoid the problem of documents taking too
long, etc. But one could argue that a lot of that is related to basic
project management issues (or from Section 2.7 "Working Group
Practices can make Issue Closure Difficult"), and its not always clear
whether a cited issue is the lack of a tool (or lack of its use) or
just lack of use of basic project management techniques, or just bad
WG practice, for which there might be several ways to try and improve
the situation.

Meta issue: Is the "root cause" issue the lack of use of
management/engineering techniques, or would using better techniques be
a _solution_ to existing poor practices (or to _some_ poor practices,
but not others)? This document seems to not make this distinction very
well, because it lists one underlying poor practice (e.g., section
2.7), but calls out a number of others in section 2.2. where they
aren't listed as poor practices, but as consequences of not using
appropriate tools.

Regarding Section 2.7:

>    2.7   Working Group Practices can make Issue Closure Difficult

IMO, Section 2.7 is a bit too narrowly scoped, and there are more
examples that should be added here.  Existing WG practices are also a
root cause issue. In that case, though, the section heading would be
better made more general, e.g.:

>    2.7   Working Group Practices Contribute to Delays

Some additional examples for section 2.7:

 - too many WGs have a adopated a cycle where the bulk of the activity
   is centered around the face-to-face meetings. E.g., Many IDs are
   revised only once per cycle, immediately before a meeting, with too
   little active work going on in the months immediately after a
   meeting.

 - despite IETF mantra that the WG is the mailing list, mailing lists
   are become increasingly ineffective at resolving issues, e.g., too
   many postings for many to keep up with, too many off-topic posts
   (i.e, those not directly related to getting wording changed in a WG
   document), folk being driven away because small number of vocal
   posters, etc.

 - Document authors are often not held accountable enough for
   revising documents in a timely fashion

 - As a WG document is being developed, reviews of WG documents too
   often involve only interested WG members and don't include reviews
   from those outside of the WG, or don't include reviews from subject
   matter experts of topics that are related to the topic in the WG
   document, but are not necessarily the focus of the WG document.
   But when the WG says its done, and those outside reviews come in,
   they are frequently viewed as being "too late" and the cost of
   making changes is "too high". Frustration then results.

If section 2.2 is really aimed at non-management stuff, like tools, I
think it would be useful make 2.2 state that clearly. Or if it is
intended to cover both tools and management techniques, make that more
clear (especially in the opening paragraph). I think it would also be
good to rename/expand section 2.7 to cover more existing bad
practices.

Thomas