[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Maximum term for tech ctte members



Anthony Towns <aj@erisian.com.au> writes:

> Hmm, that doesn't really get to the point I was trying to reach. How
> about:

>  Which is more important, avoiding sudden upheavals where possible,
>  or ensuring individual ctte members have breaks?

> If the latter's more important, then it's better not to special case
> things now; if the former's more important, shouldn't whatever rule take
> that into account in case we end up in a similar situation in future? If
> so, then there's also no need for special casing now...

I guess I see this as a false dichotomy.  I agree that avoiding sudden
upheavals and rotating people through the committee are both important,
and I'm not sure why we can't just have both via some reasonable
transition plan that spreads out term end for the future.

>>> If we want the opportunity to appoint new members regularly, rather
>>> than expire old members per se, we could just say that: "on July 1st,
>>> the two longest serving ctte members' term expires" to end up with (on
>>> average) four year terms... [...]

> would work for avoiding sudden upheavals where possible (if everyone
> resigned simultaneously, you're still stuck, eg), but still supports
> reviewing or cycling through members, IMO. Any thoughts on that sort of
> approach?

Yeah, that would achieve the same goals I had in mind and might be a
better idea.

I don't know if it makes sense to have two people's terms expire at the
same time or to have one person expire every six months.  After thinking
about it for a bit, I think I'm leaning a bit towards the former since I
think it may help further with bringing a diverse set of people on board,
since it's psychologically easier to look farther afield in terms of
diversity of opinion when you're "balancing" that at the same time.  But I
don't think I have a strong opinion.

> Colin's already at 2.75 years; so if the artificial start-of-term points
> weren't limited to being between, say, May 2010 and Aug 2011, you'd have
> some of the oldbies' terms expiring after Colin, despite being appointed
> before Colin. If you did set them all in that 15 month period, you'd
> still have 6 of 8 ctte members terms expiring in, well, the next 15
> months -- which seems about as bad as having them all expire now to
> me. Less of a problem with longer terms, though.

True.

I'm not sure there's any entirely fair way to do this.  Personally, I'm
happy to have my term expire faster than people who have been on the
committee longer if it helps with the transition.  Having it be fair to me
doesn't really make a lot of difference to me.  But that's just my
personal take, and it's quite possible that we can come up with a fairer
transition plan that doesn't create that problem.

> BTW, I've been using four years because it's a nice round number and
> reasonably short; did you think it was a good number, or were you just
> using it as an example too? Based on how long current folks have been on
> the ctte, I could see 8 years being plausible too, though anything more
> than that seems overly long to me.

I had picked four-year terms because I think adding one member every six
months (or two members every year) is probably near the upper limit of
membership management that the TC can deal with and still get other things
done, and at the same time I think four years is near the upper limit for
meaningful term lengths.  Eight years is an eternity in free software.
That's nearly half the lifespan of the Debian project.  If we're going to
commit to cycling a broader variety of Debian project members through the
TC, I think we need to use shorter terms than that.

Even if one isn't enamored of my idea of cycling more people through, and
instead is just looking to create clear break points where someone can
consider stepping down, eight years is a really long time.  In DPL
conversations, DPLs have often said that they'd hate for the term to be
longer than a year since they want the clear decision point after a year
on whether to run again.  For that decision-point feature, two-year terms
might be a better idea.  Committing to something for eight years is
functionally identical to the current setup, I think; either way, people
are mostly going to be resigning before their term is up rather than being
able to wait to the end of their term.

We could combine both features, though: set a term length of two years,
and then say that people can serve for two terms in succession but then
have to leave the committee for at least one term.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: