Some cases of poor quality
Eric Rosen
erosen at cisco.com
Wed Mar 5 13:20:34 CET 2003
I see from the discussion on this list that there is concern about the poor
quality of many documents. I haven't seen much mention of some of the
things which I regard as the root causes of the poor quality:
- The authors have no idea how to write a good quality specification.
- The authors do not want to write a good quality specification, because
that would be providing knowledge to people who aren't paying for it. (Or
perhaps the authors just don't care; after all, improving the quality
doesn't really help them any, it just takes more of their time.)
- There are too many authors, and each wants to write something ("let's
agree on the outline, and then we'll assign a section to each of us").
- To obtain consensus, too many compromises and combinations of options
needed to be added. This tends to happen (in my experience) when a lot of
the folks who are active in the WG don't know what they are talking about;
to obtain consensus, the folks who do know what they are talking about
need to placate the others somehow.
(The root cause of this root cause is that the notion of "consensus"
doesn't make much sense unless it means "consensus among people who know
what they are talking about", but WG chairs don't usually want to rule
that not every opinion is well-informed. In fact, it is not clear whether
this is even allowed by process.)
- The authors are overly pig-headed early in the process, not understanding
that the further along you get, the harder it is to ignore valid
objections; further, the WG chair fails to make this clear to them.
People with no experience bringing a draft to PS may have an especially
difficult time with this. The result is that valid objections pile up and
must be dealt with late in the process.
- The authors don't care about getting their draft to PS; they care only
about making it a WG draft, or about getting it to RFC in some form or
other, because this is all that their employers' marketing departments
require.
- The authors are entirely focused on their own little slice of the
technology, and don't care at all how their work relates to other work,
even in the same WG.
This particular reason seems to be the one that gets a lot of focus. I
would add that attempting to micromanage the WG by carefully constructing
its charter is not a very effective method of dealing with this. I see
this happening mostly within individual WGs. Some authors even regard it
as a positive that they are ignoring everything else, otherwise they would
have to "introduce dependencies", thereby further slowing down the
process.
Now, to look at the other side of the coin, sometimes documents are branded
as 'poor quality' by the "old boys' network" for reasons that have little to
do with technical quality:
- The document specifies a solution which presupposes that IP networking
service is not necessarily a commodity. This will lead to vague
assertions that the document "doesn't scale to the Internet" or "violates
the end-to-end principle", followed by a discussion which appears to be
entirely religious or agenda-based, rather than technical.
Once something like this happens, the authors and (prospective future
authors) may conclude that what is important to advancing a document is
not its technical quality, but what their agenda is, or perhaps in how
well they succeed in hiding their agenda.
- The document addresses an area which, in the opinion of some AD, is not in
accord with the IETF's mission. Since one of the problems is that there
is no common understanding of the IETF's mission, this is not really a
quality problem and it is difficult to make progress once this happens.
- The document specifies a solution which is not the solution which some AD
would have preferred. This may be exacerbated if the AD-preferred
solution is not of interest to the WG. ADs sometimes try to avoid this by
adding their preferred solutions to the WG charter, which leads of course
to later claims that the WG is not following its charter.
- The document specifies a solution involving technology that is outside the
AD's area of expertise. This must be poor quality solution, on the
grounds that "if I don't understand it, it can't be important".
More information about the Problem-statement
mailing list