Commenting only on the "early decisions on the incumbents":
I think the guidelines could be used to assign "weights" to incumbents
against the potential candidates. Here is an excerpt from one of my
postings on the term limits to the IETF list:
+++++++++++
For the 2nd term, unless there is substantially more negative feedback
than positive, reup the AD (we are told it takes about 1 year to learn
the ropes so to speak, so it is disruptive to keep replacing people
before they learn to do it well).
For the 3rd term, I would place the incumbent at the same level as a new
candidate (assuming neutral feedback on the sitting AD, or even if
he/she is doing a very good job).
For the 4th term, I would favor new candidates than the incumbent (so
unless the sitting AD is excellent and the area absolutely needs
him/her, and no one else can do half-the-job etc. :-)).
++++++++++++
Finally I think these should be like Pirate's code "the *Code* is more
of what you'd call "*guidelines*" than actual rules." :-)
(Apologies for those who haven't watched the movie "Pirates of the
Caribbean").
best,
Lakshminath
Richard Draves wrote:
[I'm sorry to be joining this discussion late.]
I see several different goals in John's draft:
1. Setting guidelines for length of service.
2. Early notification to incumbents.
3. Reducing the nomcom's workload.
I think giving the nomcom more guidance about appropriate length of
service is a fine thing. (And I tend to agree that service beyond three
terms should be unusual.) Having a generally-recognized length of
service would help generate candidates to replace a well-regarded AD who
has served several terms.
I think announcing early decisions regarding incumbents is not good. I
think there's great value in looking at the slate of candidates as a
whole. I don't like the idea of making a decision about an incumbent
without seeing the pool of potential replacements.
The goal of simplifying life for the nomcom is laudable, but in fact if
an AD incumbent is doing a good job, there are generally very few
credible & willing alternatives for the job so it doesn't take many
cycles to sort out the situation. So I don't think this proposal would
reduce the nomcom's workload.
Rich
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf