Donald Eastlake <d3e3e3(_at_)gmail(_dot_)com> wrote:
> (3) I see no reason for nomcom eligibility to be sticky. Seems like a
I'm not proposing sticky. Definitely not.
I'm proposing too levels: a high bar to become, and a slightly lower bar to
remain.
> (4) Over the years, there has been a marked increase in the stridency
> of efforts to get more and more volunteers. I never quite understood
> this. The claim is almost always made that a bigger pool of volunteers
> is more "representative" and always better but, in an organization
Let me propose one quantitative way in which a larger pool is good: it
reduces the odds of hitting the no-more-than-2 rule, and it also may reduce
the number of 2-from-one-company that occurs. This is something we could
check: compare size of pool each year to how often there was two people from
one entity, or when a person had to be turned away as the third.
> pool (say, less than 42) would be problematic, IETF participants cover
> a vast range of interest and involvement and it seems pretty clear to
> me that we want only those with relatively high interest and
> involvement. Pushing people to volunteer who would not otherwise have
> volunteered, on balance, causes more volunteers with a low level of
> interest or involvement. I have been on 4 nomcoms, once as chair, once
> as past chair, and twice as a voting member. In every case, there was
> a voting member that was pretty much deadwood - either doing notably
> less than any other voting member or doing almost nothing. In those 4
What I reading is: even when the recruiting was less strident, there was
still deadwood --- that seems to dispel this hypothesis:
> Perhaps if the volunteer recruitment was less strident, this [deadwood]
> would be less common, but there is obviously always a chance of it
> happening for a variety of reasons. So it seems to me to make sense to
> have one or two alternates who would not vote unless a voter was
> removed/resigned/...
> (5) I think the current criteria are pretty good, maybe 80% of ideal.
> But, hey, pretty much ignoring my own points 1 and 2 above, I might as
> well say what I would do if I had a magic wand: The attendance
> requirement could be relaxed some to 3 out of 7 or the like and a
> requirement should be added that the volunteer have been either a
> shepherd or front page author/editor of an IETF stream RFC issued
> within the past 4 years or served on the IESG or IAB within the past 4
> years. (I don't see any reason to add WG Chairmanship as, to a first
So, this would further increase the burden: further limit the pool.
And this business with an IESG or IAB member... that sounds like creation of
an old-boys club, which you said you didn't want.
3 meetings out of 7, depending on which three, is more or less 1 meeting a
year, but it's not actually 1 meeting a year.
We know that the random selection is going to happen in June/July, ideally
prior to meeting #2 of the year. So the past 7 meetings will be the March
meeting, plus the three meetings in the past two years.
{The only reason I was nomcom eligible in 2012 after a child restricted my
ability to travel was because in 2012, the selection was in early August,
after meeting #2. The only reason I argued to attend the next meeting was
because I was on nomcom... I was a very common remote attendee. You should
all try it a couple of times.}
We need people who can attend at least the November meeting to do interviews.
So in order to be willing/able to volunteer in May/June, if you have only
funding to attend once a year, you need to not attend in March.
But that means that you won't be eligible, so you can't even volunteer.
What that rule did is make sure that the IETF Nomcom only never comes from
well funded entities, most of whom are vendors. If we want more operators,
we might want to recognize that they have other meetings
(ARIN/NANOG/RIPE/Apricot) that many of them struggle to get funded to attend.
If we want more academics/students, we might also recognize that as well.
If we want more young people represented... I could go on.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] mcr(_at_)sandelman(_dot_)ca http://www.sandelman.ca/ | ruby on
rails [