ietf-nomcom message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [ietf-nomcom Home]


Subject: Re: publish which list of nominees?


On Mon, Apr 01, 2002 at 02:38:13PM +0200, Harald Alvestrand wrote:
> 
> - The nomcom has an "active" list, which starts out with the current 
> incumbent, and a "rejected" list, which starts out empty.
> The purpose of the nomcom process is to get a single name on the "active" 
> list.
> 
> 1 - Nominations from outside get added to the "active" list - primarily 
> early in the game, but it can occur at later times.
> 2 - Nominations from inside the nomcom get added to the "active" list
> 3 - Nominations move from the "active" to the "rejected" list by several 
> ways:
>   a - The candidate refuses to be considered
>   b - The nomcom finds the candidate unsuitable
>       Reasons may include being considered for another position...
> 4 - At the end, the nomcom picks a single candidate off the "active" list
>   and moves the rest to the "rejected" list.
> 
> Consider the various lists that can be published:
> 
> A - All that comes in from (1)
> B - All that comes in from (1) and (2)
> C - All that comes in from (1) and (2), minus (3a)
>   (also C2 - all nominees that have explicitly said they are willing)
> D - All that comes in from (1) and (2), minus (3a) and (3b)

> List C is an excellent basis for a "beauty contest" or "campaigning".

OK, people keep using the terms "popularity contest" and
"campainging".  I'd like to request that someone who seriously
believes this to define precisely what they mean by this, and why they
don't believe (a) the nomcom won't be able to detect and filter out
"popularity contests", and (b) why they believe anything we do can
prevent (or encourage) popularity contests.

First of all, right now, please note that the confidentiality
constraints in RFC 2727 constrain only the nomcom and the confirming
bodies.  (Although as a side note it does *not* specify what
information nomcom is allowed to share with the confirming bodies when
they start asking questions; that's left very ambiguous at the moment.
But that's a topic for another day.)

Hence, someone who is a candidate is free to let everyone and their
brother know they are running.  There are currently cultural
constraints which prevent this from being much of a problem, but it
does happen from time to time --- and it's not a problem.  Without
violating the nomcom confidentiality rules, I believe it is fair to
say that we received messages from a candidate's colleagues which made
it very clear they knew so-and-so was running, and that he was a Good
Choice.  So to the extent that explicit campainging happens, that can
happen today, reguardless of whether or not we publish lists.

Also, I can't speak for all of the nomcom, but quite frankly, I tend
to discount and completely ignore comments along the line of
"so-and-so is a good candidate", "a good guy", or (as an example of a
useless negative comment) "You must be kidding!".

So in order to be useful, the comments have to give detailed
information about a candidate, and examples of how they have (or have
not) demonstrated good management/leadership skills, etc.  Once we
posit this bar, then getting duplicate comments isn't particularly
important, and can be relatively easily filtered out.  So maybe I'm
being naive, but I honestly don't see why people are so concerned
about the possibility of campaigning.  Personally, I just don't see
this as a problem.

> List A and B are growing lists. They reveal something about the community, 
> but little about the evaluation process of the nomcom.
> 
> List C (non-refused nominations) is a list that may both expand and 
> contract.
> It reveals something more - if people appear, disappear and then reappear, 
> it is clear that someone is twisting arms. If people pop up late, it is 
> probable that they are "headhunted" by nomcom, which tells you something 
> about nomcom's evaluation of the other candidates.
> 
> List C2 (accepted nominations) is also a list that may expand and contract. 
> But it grows later than list C2 - and the result of nomcom "headhunting" 
> will be even easier to detect here.

I would suggest list C2, with the proviso that the list not contract.
(i.e., a name doesn't appear on the list until the person has accepted
the nomination, and once a name appears on the list, it is never
removed.)  

This is a smaller list, which is important from the point of view of
reducing noise.  This is important, because in order for the comments
to be useful, they need to be detailed.  If we make the list too long,
then we deny the nomcom of useful input.

As far as the concern about leaking information about the nomcom
"headhunting", there really is no way of doing that.  Even if we use
list B, realistically the nomcom stops getting outside nominations
after the beginning of January.  So any new names which appear on List
B can just as certainly be taken as "nomcom headhunting".  So, there's
no real value to additional noise List B would have.

Ultimately, the tradeoff here is between establishing some
arbitrary cut-off after which point the list stops getting updated
(which means that nomcom won't get community input on late-breaking
candidates), and revealing information that the nomcom is in
headhunting mode, presumably because that would say something about
how nomcom felt about the other candidates.  

However, once you publish a list at all, if nomcom ends up selecting
another candidate, the information that nomcom decided that the
submitted names were not suitable is going to come out anyway, so
there's no real point trying to hide that fact.  

Secondly, it's just as possible that the reason why the nomcom needed
to go headhunting is because a candidate accepted, but then later
discovers that he/she doesn't have management approval for the 30
hour/weekc commitment.  So there are in fact many reasons why the
nomcom might need to go into headhunting mode, and so you can't infer
that much information the fact that nomcom was headhunting in any
case.

						- Ted


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [ietf-nomcom Home]


Powered by eList eXpress LLC