technical supervisors (was: improving WG operation)

wow...I keep wanting to make terse replies, but there never seems to be 
a way to address the subject with a short answer.
I'm sorry you see these explanations as whining.  I believe that we 
have to recognize that part of our problem is how WGs operate before we 
can be willing to solve that problem.  So I try to describe that 
problem in a way that people will recognize it.  Maybe people already 
realize that we have this problem and I don't actually need to 
illustrate it.
As for solutions - I have been thinking about possible solutions for 
several years.  But I'm much better at protocol engineering than I am 
at engineering management or social structures, so I don't have much 
confidence in my ideas for how to solve the problem.
Recently I've begun to suspect that a good answer to some of these 
problems might involve a layer of management between IESG and working 
groups - a set of people who had responsibility to give some technical 
oversight to working groups, monitor their progress, and keep the ADs 
up-to-date on the state of things.  I say "oversight" rather than 
"direction" because "direction" would be too strong a term.  I don't 
see the supervisor (let's call him a supervisor for now) telling the 
group what technical decisions to make.  I do see the supervisor making 
sure that the group investigates important issues - setting short-term 
milestones and an agenda for the group.
What I'm thinking is that the person in charge of supervising a WG ends 
up consulting with the chair and/or document authors on a regular basis 
(say, every three or four weeks) and agreeing on the next set of 
near-term goals and deliverables for that WG.  The supervisor might say 
"you need to understand and document the nature of the disagreement 
between these two concerns" or "you need to pick a 
mandatory-to-implement encryption algorithm", or "you need to solicit 
cross-area review for this issue" or "you need to analyze whether this 
ABNF grammar can be implemented with only one symbol of look-ahead" or 
"defer that question for now, the thing you have to decide before you 
do anything else is how much you are going to constrain yourself to be 
backward compatible with this legacy protocol that we all know is 
broken".
As I see it, the supervisor would offload some of the present Chair's 
duties and some of the present Responsible AD's duties.  The chairs 
would still be responsible for managing the group discussion and making 
sure process rules were followed.  The ADs would still approve charter 
changes (overall goals, long-term milestones), review documents before 
publication, and be the first level of appeal.
The supervisor would try to make sure that important issues were 
identified and dealt with early, and in plenty of time to get them 
resolved before the specification is finalized; he would also make sure 
that measurable progress was being made every few weeks and report 
progress or lack thereof to the AD.
Another part of the supervisor's job would be to ensure that when the 
document finally goes to IESG, neither the WG nor the IESG are 
surprised by how the other reacts to it.  Along with the specification 
presented to IESG should be supporting material to give the IESG 
confidence in the document, for example: a list of goals and 
requirements (written before the specification); a list of changes to 
those goals and requirements with the rationale for each change; a list 
of issues and contentious design choices that arose, how each was 
resolved, and why; what kinds of review the specification was subjected 
to, the results of that review, and what changes (if any) were made 
based on that feedback; documentation of any analysis that was done on 
the protocol; description of early implementations (prototypes) and how 
they differ from the final specification.  This material would take the 
place of the "writeup" that an AD is now expected to do before a 
document from his working group goes to IESG ballot.
Similarly for face-to-face meetings - the Chair would preside, but the 
supervisor would work out the agendas of face-to-face meetings in 
consultation with the Chair.   The meeting time would be used to reach 
closure on divisive issues.
The supervisor would be expected to NOT have a strong interest in the 
outcome of the WG (other than to see that quality work is done), nor to 
closely follow or regularly participate in group discussion.  His job 
would be to keep a higher-level perspective on things.   When 
identifying issues that must be resolved he could state an opinion but 
must clearly separate his opinion from the description of the issue. 
WGs would be allowed to "push back" on an issue definition if they 
thought it unreasonably constrained the resolution, and suggest an 
alternate way of framing the issue.
The concept of Technical Supervisors could be tried on two or three 
working groups and refined based on experience.  Initially the 
supervisors might be appointed by the AD and confirmed by IESG; 
eventually there might be a separate mechanism for nominating and 
vetting potential supervisors.  Ideally a working group would keep the 
same supervisor as long as it is chartered, though it would be possible 
to change a WG's supervisor - particularly one who wasn't doing his job 
well.
Supervising a WG shouldn't require more than say 2 hours per week.

There would need to be some way to recognize the contributions of WG 
supervisors, and perhaps some incentives for taking on a job with low 
visibility and minimal creative input.
--

so there you have one half-baked idea.  I'm sure it's not too difficult 
to poke holes in it, but I think it's a more promising avenue of 
inquiry than one which tries to move the final technical review outside 
of IESG.  In a world with technical supervisors, the IESG mostly 
continues to do what it is doing now, but its job should get easier 
because it will get better specifications and more supporting material 
with which to evaluate the specifications.  it might let the IETF grow 
larger because ADs will be able to spend less effort keeping up with 
their working groups' progress and less effort reviewing documents - 
IESG's workload would be more closely related to the number of 
documents reviewed than the number of working groups.
Keith


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf