The difference is less between "process assistant" and
"technical contributor" than it is about timing and issues of
reviewing/ approving one's own work:
No doubt there is a productive line of consideration, using your factoring,
but, no, it is quite different from mine.
Mine is about confusion of roles. Yours is about timing.
What they probably most have in common is prioritization, in terms of wg need.
So, my disagreement with this characterization notwithstanding, I quite like
the rest of your note.
Enough to elaborate on it...
Once a document appears for final "approval" review, if
difficulties are found with the specification, that indicates a
systemic failure. That failure was described during the Problem
Statement work (including, I think, by you) as "late surprise".
Yes. And it is interesting how little credence is given to that particular
problem. We are repeatedly demanded to produce statistics about it. That it
is in the Problem Statement document seems to be of little import.
But it is worse than that because such late surprises typically,
perhaps inevitably, turn the end game of the document approval
process into a negotiation between a WG that thought it was
finished and the IESG about what will be accepted.
Thank you for phrasing it this way.
It is difficult to imagine a much better approach to worker dis-incentive by
"management" than the unpredictability of that part of our process and the
sense of having been sucker-punched when having to go through the late-stage
negotiation, especially when the worker-bees feel like they are mostly having
to either educate the AD -- rather than fix actual problems -- or cater to the
AD's personal whims.
And, as always, I now need to worry that such frank language will, as always,
be taken as some sort of outrageous slap at the IESG. It isn't. It is simply
an attempt at plain characterization of the view that occurs periodically
among the worker bees, notably those who are at the core of the working group
effort
That is,
under the best of circumstances, a lousy way to do
engineering... even when it is unavoidable.
One could argue that it is very nearly always avoidable. But, the irritating
fact of life is that such an argument would require mathematical consistency
in human behavior. Since we ain't likely to get there, the problem is in
agreeing that it SHOULD BE nearly always avoidable and therefore SHOULD BE
treated as a powerful, unfortunate, but necessary tool.
Hence it should be used with surgically care.
And we are a very long way from getting THERE, though I hold out hope that the
Discuss document will move us in the right direction.
But I would not condemn an AD who says, at a similarly early
stage, "please consider the following alternative, which I am
going to outline in technical detail".
Me either.
Would that such gentle language were the way that alternatives were offered.
Would that such suggestions were made early in a design process rather than
after months of effort. (Yes, you said early, but there is quite a bit of
distance between "after months of effort" and what we usually call late-stage,
namely Last Call. I simply want to stress that every day later such
suggestions are made, the more damaging to working group morale and productivity.)
After all, the ADs do have considerable
technical expertise and we should be anxious to take advantage
of it.
You know, as much as we all make a point of saying this, and as much as it is
true, there is a minor problem that shows itself too often to ignore and it
comes in two forms:
1. For many topics, no one is really an expert, or at the least, there are
others in the wg with at least the AD's level of expertise. Hence, an AD's
views are important, but it is not necessarily appropriate to give their views
more weight than those of others. (This is why I consider an AD's expertise
best used at recruiting support to reach rough consensus, rather than in its
more typical current use as a veto or point of personal negotiating leverage.)
2. ADs have the usual human frailty of often not knowing their limitations.
That can lead to strongly voiced views that are just plain wrong.
Not surprisingly, #1 and #2 occasionally combine.
And isn't THAT fun?
The second problem is that these "late surprises" cost us time
and, I believe, quality. Whether the time-cost is in reviewing
documents or in the subsequent negotiation and iterations
(remember that, according to Bill's latest figures, 75% of
documents submitted to the IESG get at least one DISCUSS that
has to be sorted out, often without the quality of consideration
that would go with a WG including the relevant issues in its
normal development process.
Good point, nicely made.
And the third one is the case in which an AD is not _a_
contributor to the work of a WG, but becomes the (or a) primary
source of technical input to the WG.
I am having trouble parsing this.
How can one be a/the primary source without being a contributor?
And the notion of an AD who has contributed
technically to a WG in some significant way then pushing back
during IESG review if the WG reaches some other conclusion is
pretty close to intolerable.
It is worse than that. Even if the AD keeps their mouth (and fingers)
entirely silent during IESG considerations, they will have held undue
influence over the process, if they make substantial technical contribution
AND are the cognizant AD.
The term "conflict of interest" has its definition precisely in the danger
that comes from this sort of confusion of roles.
But that's really for a different discussion thread...
--
d/
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf