Maximum term for tech ctte members

[Anthony Towns]

Hello world,

Would anyone else be supportive of a proposal to set a term for tech ctte
membership?

The current tech ctte members were appointed:

Ian: May/Dec 1998 (15 years, 5 months) [0]
Bdale: Apr 2001 (13 years, 1 month) [1]
Andreas: Jan 2006 (8 years, 4 months) [2]
Steve: Jan 2006 (8 years, 4 months) [2]
Russ: Jan 2009 (5 years, 4 months) [3]
Don: Jan 2009 (5 years, 4 months) [3]
Colin: Aug 2011 (2 years, 9 months) [4]
Keith: Nov 2013 (6 months) [5]

I think set terms, with no term limits would make sense (ie, you're
appointed to the ctte, you stay on it for X years, then you either say
"thanks, but enough's enough" or "that was fun, I'd like to keep doing
it" and the ctte and DPL considers whether to reappoint you in the
usual fashion.

Personally, I think 3 or 4 year terms ought to be long enough, but
that would mean kicking everyone but Colin and Keith off the ctte
immediately. Terms of 6-8 years would leave half the current ctte around
to reconstitute the ctte. With a term of 16 years (which no member has
exceeded yet), a new member would have to be voted on once every two
years on average to maintain a full 8-member ctte.

I think it'd be healthy if there was a rule something like "an ex-member
may not be reappointed to the committee unless someone else has been
appointed to the ctte since s/he was last a member". That would mean
you couldn'y have "Alice, Bob, Carol, Dave" as the tech ctte with an
agreement that they'll just reappoint each other anytime their term
expires; they'd have to appoint someone from outside the group (Emma,
say) first. Call it an anti-Cabal measure. I'm not sure there's a simple
and obvious way to phrase such a measure though, so maybe it's too hard.

At present, the only way for someone to leave the tech ctte is for them to
disappear, resign, or be hounded out by either their fellow ctte members
or a GR. IMO, it would be nice if there was a way out of the ctte that had
more of a feeling of winning / leaving at the top of the game than those.

YMMV. I think I'd rather second a proposal along these lines than actually
propose it...

Cheers,
aj

[0] https://lists.debian.org/debian-devel/1998/05/msg01546.html
https://lists.debian.org/debian-announce/1998/msg00047.html
[1] https://lists.debian.org/debian-ctte/2001/04/msg00025.html
[2] https://lists.debian.org/debian-project/2006/01/msg00013.html
[3] https://lists.debian.org/debian-ctte/2009/01/msg00053.html
[4] https://lists.debian.org/debian-devel-announce/2011/08/msg00004.html
[5] https://lists.debian.org/debian-devel-announce/2013/11/msg00009.html

[Russ Allbery]

Post by Anthony Towns
Would anyone else be supportive of a proposal to set a term for tech
ctte membership?

I just mentioned this today in our TC meeting, so obviously I've been
thinking along these lines as well and have been wondering if this would
be a good idea.

Post by Anthony Towns
I think set terms, with no term limits would make sense (ie, you're
appointed to the ctte, you stay on it for X years, then you either say
"thanks, but enough's enough" or "that was fun, I'd like to keep doing
it" and the ctte and DPL considers whether to reappoint you in the usual
fashion.

Other bodies of this type take a variation on this approach (and of the
reappointment rule you propose below) that I quite like: after each term,
that member may not be reappointed for some period. For example, we could
say that members serve for four years, and after that four-year period
they cannot be reappointed to the TC for at least two years.

The primary goal of this sort of system is to rotate fresh people through
the decision-making body. This has multiple advantages. It gives people
a break and a clean break point where they can stop without any perceived
implications of resigning, so they can either decide they've done enough
or they can come back refreshed and with fresh eyes. It encourages some
of our most senior members to take more time for work on the project
instead of project governance, similar to constantly changing the DPL,
which may also provide improved perspective on some issues. It gives far
more people an opportunity to serve on the TC, which both benefits them
and benefits the project as a whole by providing a constant rotation of
fresh perspectives. It can help break the body out of any subtle
group-think that it may have developed from working together for so long.

Obviously, each of us can independently decide to do this on our own (and
I've been considering doing so regardless), but I think there are some
real benefits in making this our process instead of asking individuals to
do it voluntarily. It makes the whole turnover process more reliable and
more consistent for the project and encourages development of mechanisms
for selecting good people for the committee.

I think our DPL selection process works extremely well and benefits
greatly from having a yearly election. Selecting a new TC member took a
long time, and there are strong incentives in the current system to make
cautious and conservative decisions on new members because members
effectively serve for life. (It's the US Supreme Court justice selection
problem, essentially.) I'm not sure that's best for the project. If we
were rotating members more frequently, there would be less perceived risk
in each member selection, and we would get better at the process.

Post by Anthony Towns
Personally, I think 3 or 4 year terms ought to be long enough, but that
would mean kicking everyone but Colin and Keith off the ctte
immediately. Terms of 6-8 years would leave half the current ctte around
to reconstitute the ctte. With a term of 16 years (which no member has
exceeded yet), a new member would have to be voted on once every two
years on average to maintain a full 8-member ctte.

One approach we could take to this would be to randomly assign each
existing member (except maybe Keith and Colin) to an artificial "start of
term" date distributed across the past three or four years, for the
purposes of deciding when our current term ends. That would build in some
transition time and spread new member selection out in a sustainable way.

[Anthony Towns]

Post by Russ Allbery

Post by Anthony Towns
Would anyone else be supportive of a proposal to set a term for tech
ctte membership?

I just mentioned this today in our TC meeting, so obviously I've been
thinking along these lines as well and have been wondering if this would
be a good idea.

Cool.

Post by Russ Allbery

Post by Anthony Towns
I think set terms, with no term limits would make sense (ie, you're
appointed to the ctte, you stay on it for X years, then you either say
"thanks, but enough's enough" or "that was fun, I'd like to keep doing
it" and the ctte and DPL considers whether to reappoint you in the usual
fashion.

Other bodies of this type take a variation on this approach (and of the
reappointment rule you propose below) that I quite like: after each term,
that member may not be reappointed for some period. For example, we could
say that members serve for four years, and after that four-year period
they cannot be reappointed to the TC for at least two years.

Yeah; I don't think that's a bad rule in general, but I'm not convinced
it's a great fit for the tech-ctte. The thought experiment that makes me
doubt it is "if a compulsory x year break after n years of service makes
sense in general, shouldn't it make sense now?", or equally, "if it's
too painful for us to do things this way now, why won't it be equally
painful in future (eg if we end up appointing four members at the same time,
and having their terms all expire at the same time as a consequence)?".

Even if you set n as high as 13 years, that'd mean Bdale and Ian would be
due for a compulsory break, despite (from my impression) them both being
enthusiastic contributors.

I was thinking of the "have to appoint someone different" rule I suggested
because that would at least mean you could do something like set n=6,
have Steve, Andi, Bdale and Ian's term expire immediately, but still
reappoint up to three of them almost immediately.

I'm not really convinced by the idea either, though.

Another approach might be, say, four year terms, with a compuslory two year
break after eight years.

Post by Russ Allbery
One approach we could take to this would be to randomly assign each
existing member (except maybe Keith and Colin) to an artificial "start of
term" date distributed across the past three or four years, for the
purposes of deciding when our current term ends. That would build in some
transition time and spread new member selection out in a sustainable way.

I would have thought deliberate scaling would make more sense than random
assignment, eg, "tech ctte members have four year terms; for the purpose
of this rule the existing members are deemed to have been appointed at:

Ian, Bdale: 2010-12-01 (expiry 2014-11-30)
Andi, Steve: 2011-12-01 (expiry 2015-11-30)
Russ, Don: 2012-12-01 (expiry 2016-11-30)
Colin, Keith: 2013-12-01 (expiry 2017-11-30)
"

That still rubs me a bit the wrong way though -- "we limit the tech
ctte to 4 years each, which for Ian means 16 years, for Bdale means
almost 14 years, for Andi and Steve it means 10 years, for Russ and Don
it means 8 years, for Colin it means six years, and for Keith it means
4 years". And again, sure, you can't change the past, but if it's good
for tech ctte members to be reviewed or put on a break after X years,
excluding the current members who've served >X years from the rule
just doesn't seem sound to me.

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... Probably needs some tweaking though -- maybe it ought
only apply if nobody's resigned in the previous 12 months or something.

Cheers,
aj

[Russ Allbery]

Post by Anthony Towns

Post by Russ Allbery
Other bodies of this type take a variation on this approach (and of the
reappointment rule you propose below) that I quite like: after each
term, that member may not be reappointed for some period. For example,
we could say that members serve for four years, and after that
four-year period they cannot be reappointed to the TC for at least two
years.

Yeah; I don't think that's a bad rule in general, but I'm not convinced
it's a great fit for the tech-ctte. The thought experiment that makes me
doubt it is "if a compulsory x year break after n years of service makes
sense in general, shouldn't it make sense now?", or equally, "if it's
too painful for us to do things this way now, why won't it be equally
painful in future (eg if we end up appointing four members at the same
time, and having their terms all expire at the same time as a
consequence)?".

Well, I guess my point is that I think it *is* a good idea now. I will
probably do something like this myself regardless of whether we change the
general system or not because I think it's better for the project to
rotate people through the committee.

Post by Anthony Towns
Even if you set n as high as 13 years, that'd mean Bdale and Ian would be
due for a compulsory break, despite (from my impression) them both being
enthusiastic contributors.

I should be clear: for me, it's not about whether the current members are
active and valuable contributors. Let's take for granted that's the case.
The problem remains that as soon as we put together a group of eight
active and valuable contributors, nothing ever changes until one of those
people steps down.

That's obviously not the worst situation we could be in, but I don't think
it's the best either. I'd prefer to see more project members rotate
through the Technical Committee, for a variety of reasons stated in my
previous message. Please don't take this as commentary on the current
membership at all.

Post by Anthony Towns

Post by Russ Allbery
One approach we could take to this would be to randomly assign each
existing member (except maybe Keith and Colin) to an artificial "start
of term" date distributed across the past three or four years, for the
purposes of deciding when our current term ends. That would build in
some transition time and spread new member selection out in a
sustainable way.

I would have thought deliberate scaling would make more sense than
random assignment, eg, "tech ctte members have four year terms; for the
purpose of this rule the existing members are deemed to have been
Ian, Bdale: 2010-12-01 (expiry 2014-11-30)
Andi, Steve: 2011-12-01 (expiry 2015-11-30)
Russ, Don: 2012-12-01 (expiry 2016-11-30)
Colin, Keith: 2013-12-01 (expiry 2017-11-30)
"

I was not particularly clear on what I meant by random assignment. What I
had intended was to designate six artificial "start of term" points in the
past four years and then have all the members who have served for over
four years to just draw those out of a hat. Not completely randomly
generating a start date.

We could also do it in order of seniority. I have no strong opinions
there. The transition method for something like this is always somewhat
tricky, and there's no entirely "fair" way to do it.

[Anthony Towns]

Post by Russ Allbery

Post by Anthony Towns
Yeah; I don't think that's a bad rule in general, but I'm not convinced
it's a great fit for the tech-ctte. The thought experiment that makes me
doubt it is "if a compulsory x year break after n years of service makes
sense in general, shouldn't it make sense now?", or equally, "if it's
too painful for us to do things this way now, why won't it be equally
painful in future (eg if we end up appointing four members at the same
time, and having their terms all expire at the same time as a
consequence)?".

Well, I guess my point is that I think it *is* a good idea now.

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...

Without special casing, it might be hard to reconstitute the ctte from
just Coin and Keith (assuming terms of less than six years) if all the
existing members were unavailable to be re-included. I don't know that
it'd actually be that hard though -- they could just appoint two members
initially to get up to the constitutionally recommended "at least 4",
then add to that over the next few years to get up to a steady state of
8 ctte members with 2 appointed each year...

Post by Russ Allbery

Post by Anthony Towns
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?

Post by Russ Allbery

Post by Anthony Towns
I would have thought deliberate scaling would make more sense than
random assignment, eg, "tech ctte members have four year terms; for the
purpose of this rule the existing members are deemed to have been
Ian, Bdale: 2010-12-01 (expiry 2014-11-30)
Andi, Steve: 2011-12-01 (expiry 2015-11-30)
Russ, Don: 2012-12-01 (expiry 2016-11-30)
Colin, Keith: 2013-12-01 (expiry 2017-11-30)
"

I was not particularly clear on what I meant by random assignment. What I
had intended was to designate six artificial "start of term" points in the
past four years and then have all the members who have served for over
four years to just draw those out of a hat. Not completely randomly
generating a start date.

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.

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.

Cheers,
aj

[Russ Allbery]

Post by Anthony Towns
Hmm, that doesn't really get to the point I was trying to reach. How
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.

Post by Anthony Towns

Post by Anthony Towns
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.

Post by Anthony Towns
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.

Post by Anthony Towns
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.

[Michael Gilbert]

Post by Russ Allbery
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.

8 seems like it would be near ideal: turnover is dealt with only about
once per year, it is close to the average of the existing members
terms (7.385 years), and it's likely close the historical average
(although I haven't calculated that, would be interesting for someone
to research).

A 1 year sabbatical could be imposed every 7 years with the seat
remaining available upon return (the TC still works, and is even
possibly more effective with on average 7 members rather than 8)?

Best wishes,
Mike

[Russ Allbery]

Post by Michael Gilbert

Post by Russ Allbery
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.

8 seems like it would be near ideal: turnover is dealt with only about
once per year, it is close to the average of the existing members terms
(7.385 years), and it's likely close the historical average (although I
haven't calculated that, would be interesting for someone to research).

I don't think this achieves the goal of rotating more project members
through the TC. In other words, matching the average of the past is, for
me, a bug, not a feature: I think the TC turnover should be considerably
higher than it has been, not because there's anything at all wrong with
the people who have served in the past, but because I think this is a
function that should take advantage of the perspectives of, and be
accessible to, a larger spread of people within the project. That's
something that I've been kicking around since the discussions about our
last membership change, after getting a feel for the various constraints
created by the current TC membership system. It felt like the project
would benefit from the TC doing something a bit more outside the box.

Of course, it remains to be seen how many people other than myself think
this is a goal that we should be aiming towards.

[Michael Gilbert]

Post by Russ Allbery

Post by Michael Gilbert

Post by Russ Allbery
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.

8 seems like it would be near ideal: turnover is dealt with only about
once per year, it is close to the average of the existing members terms
(7.385 years), and it's likely close the historical average (although I
haven't calculated that, would be interesting for someone to research).

I don't think this achieves the goal of rotating more project members
through the TC.

You could rotate people in to serve in place of the TC members that
are on sabbatical, which means at least one new perspective per year.

Best wishes,
Mike

[Ian Jackson]

Post by Michael Gilbert

Post by Russ Allbery
I don't think this achieves the goal of rotating more project members
through the TC.

You could rotate people in to serve in place of the TC members that
are on sabbatical, which means at least one new perspective per year.

I really don't like the idea of having two tiers of TC members -
"permanent" ones and these new rotating one-year ones.

Ian.

[Michael Gilbert]

Post by Ian Jackson

Post by Michael Gilbert

Post by Russ Allbery
I don't think this achieves the goal of rotating more project members
through the TC.

You could rotate people in to serve in place of the TC members that
are on sabbatical, which means at least one new perspective per year.

I really don't like the idea of having two tiers of TC members -
"permanent" ones and these new rotating one-year ones.

A simple analogy, people in the rotating seats are to the permanent TC
members as debian-maintainers are to debian-developers.

DM has some definite advantages, people more autonomy and have a whole
lot more to show when going for DDship, and some flaws, it makes the
process of becoming a DD longer and possibly more tedious (depending
on perspective) than the question and answer process.

The same could be said for rotating TC members. So, I think it worth
considering the larger perspective that the project may view the TC as
insular, and that possibly something should be done about that.

Best wishes,
Mike

[Zenaan Harkness]

Post by Russ Allbery

Post by Michael Gilbert

Post by Russ Allbery
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.

8 seems like it would be near ideal: turnover is dealt with only about
once per year, it is close to the average of the existing members terms
(7.385 years), and it's likely close the historical average (although I
haven't calculated that, would be interesting for someone to research).

I don't think this achieves the goal of rotating more project members
through the TC.

If that be a worthy goal (I'm not commenting on this), then how about
increasing the number of seats (maintaining an odd number of course)?

[Anthony Towns]

Post by Michael Gilbert
8 seems like it would be near ideal: turnover is dealt with only about
once per year, it is close to the average of the existing members
terms (7.385 years), and it's likely close the historical average
(although I haven't calculated that, would be interesting for someone
to research).

Going by the CVS history of the www.debian.org/intro/organization page,
past ctte members had terms of:

Manoj Srivastava ~14y
1998-12-14 - 2012-08-30
(* - 1.440)
https://lists.debian.org/debian-ctte/2012/08/msg00028.html

Raul Miller ~ 9y
1998-12-14 - 2007-06-14
(* - 1.244)
https://lists.debian.org/debian-ctte/2007/04/msg00019.html

Guy Maor ~ 7y
1998-12-14 - 2006-01-05
(* - 1.186)
https://lists.debian.org/debian-ctte/2005/12/msg00002.html

Wichert Akkerman ~ 5y
2001-04-23 - 2006-01-05
(1.40 - 1.186)
https://lists.debian.org/debian-ctte/2005/12/msg00000.html

Jason Gunthorpe ~ 5y
2001-06-01 - 2006-01-05
(1.42 - 1.186)
https://lists.debian.org/debian-ctte/2005/12/msg00000.html

Dale Scheetz ~ 4y
1998-12-14 - 2002-10-16
(* - 1.84)
https://lists.debian.org/debian-ctte/2002/10/msg00007.html

Anthony Towns ~ 3y
2006-01-05 - 2009-01-06
(1.186 - 1.312)
https://lists.debian.org/debian-ctte/2009/01/msg00006.html

Klee Dienes ~ 2.5y
1998-12-14 - 2001-06-01
(* - 1.42)
https://lists.debian.org/debian-ctte/2001/05/msg00010.html

I've put the CVS revision id in brackets for the relevant commits to
organization.data in the webwml tree for verification purposes, and based
on the commit dates had a look in the -ctte archives for what seem to
be the relevant removal mails.

That's an average of ~6 years, and a median of 5 years; but that should
probably be scaled down given the lack of involvement of most of those
folks towards the end of their terms...

Cheers,
aj

[Matthias Urlichs]

Hi,

Post by Anthony Towns
That's an average of ~6 years, and a median of 5 years

You did not consider the current members.

Post by Anthony Towns
should probably be scaled down given the lack of involvement of most of
those folks towards the end of their terms...

However, the current really-long-term members fail to exhibit any lack of
involvement. Which more than makes up for that, statistically speaking.

One other idea comes to mind: do we want to have rigid per-member term
limits, or do we allow members to swap? Thus if, let's say (hypothetically
of course), Bdale's term limit comes up; he'd like to stay on the TC; at the
same time, Keith needs to step down due to other looming responsibilities
-- do we dismiss both of them, or do we value continuity and only elect
one new TC member (along with any others whose term ends at that time,
of course)?

[Zenaan Harkness]

Post by Russ Allbery

Post by Anthony Towns
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.

I think > 1 election per year might be worth avoiding, so that
elections do not become tedious rigmarole.

For yearly elections and four year terms:
a quarter of the ctte (oldest serving) expired re seat re-election each year.

For every-2-years elections and six year terms: a third of the ctte etc.

If someone resigns, may be a) hold an election for just that seat, or
b) whoever was next-in-line at the last election, to replace that
person,

but in either case only up until that seat would normally be up for
re-election, that way 'normal' elections continue without the schedule
getting messed up due to resignations. This is how Australian
parliamentary elections work.

Post by Russ Allbery

Post by Anthony Towns

Post by Anthony Towns
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.

If the entire ctte were to resign, randomly assign those persons newly
voted in to the various 'seats' which would ordinarily come up for
election in their usual time period, similar to the 'one member
resigns' case above'

Post by Russ Allbery
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.

I suggest that stability of 'normal' elections is valuable from a
"let's not burnout with excessive election admin overheadd" pov.

Post by Russ Allbery
I'm not sure there's any entirely fair way to do this. Personally, I'm

It does not need to be 'fair' from a time perspective. Of course the
current seats exist from historical perspective.

Decide on an 'ideal' pathway going forward, and if someones get a few
extra years on the ctte, it does not matter at all. Act in the
assumption that everyone is bringing their best to the table, and
there can be no serious complaints.

Post by Russ Allbery

Post by Anthony Towns
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.

The Australian senate (our federal parliament) has 8 year terms. In
the first instance they had half the senate expire in 4 years, so some
of the first elected senators only got a 4 year term. Ever since, it's
almost always half the senate rotating:
at each 4-year election.

I think less than 4 year terms is inadvisable.

Post by Russ Allbery
Eight years is an eternity in free software.

Software is different, but there is something comforting about having
a longer-term body, the tech ctte, where its members have longer
terms. I have always thought that the DPL is almost titular given the
short term, but perhaps that's good too, for that role, in the way
'Debian' works.

I suggest 6 year terms (or 8), with roughly half the seats expiring
each half term, with the first half up for re-election once this
decision making process concludes.

The only suggestions I have for seat counts:
a) choose an odd number of seats, to eliminate the personal
frustrations which may arise at contentious votes - "the chair doesn't
need to vote at all unless there's a tie, and the chair's
(odd-numbered) vote is a normal full single vote which breaks the
tie".

Good luck,
Zenaan

[Anthony Towns]

Post by Zenaan Harkness
The Australian senate (our federal parliament) has 8 year terms. In

(6 year terms; same as the US senate as it happens. We have 3 years
terms the house of reps and hence prime minister as compared to 2 year
terms for the US hous of reps or the 4 year term of the US President)

Cheers,
aj

[Matthias Urlichs]

Hi,

Post by Russ Allbery
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 may be true, but our release cycles also feel like an eternity :-P
and it might make sense to have, say, at least one TC member on board who
has been on the TC at least since the current "oldstable" was released.

So I'd propose a six-year term limit where every 1.5 years the two
longest-serving members step down for a year and a half.

Or, if we want an odd number of members, let three members step down
every two years.

[Anthony Towns]

Post by Matthias Urlichs

Post by Russ Allbery
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 may be true, but our release cycles also feel like an eternity :-P
and it might make sense to have, say, at least one TC member on board who
has been on the TC at least since the current "oldstable" was released.

So the periods between release n and n-2 have been:

4y10m - 3.1 sarge June 6th 2005
4y9m - 4.0 etch Apr 8th 2007
4y3m - 7.0 wheezy May 4th 2013
3y10m - 6.0 squeeze February 6th 2011
3y8m - 5.0 lenny February 14th 2009
3y4m - 3.0 woody July 19th 2002
2y4m - 2.1 slink March 9th 1999
2y1m - 2.2 potato August 15th 2000
1y10m - 0.93R6 November 1995
1y7m - 2.0 hamm July 24th 1998
1y3m - 1.1 buzz June 17th 1996
1y1m - 1.3 bo July 2nd 1997
1y1m - 1.2 rex December 12th 1996

Though aiui, the security team only support oldstable for 1 year after
the release date of stable (previously 6 months), so the effective life
of oldstable releases is probably shorter than the times above.

Cheers,
aj

[Ian Jackson]

Post by Matthias Urlichs
Or, if we want an odd number of members, let three members step down
every two years.

We do want an odd number of members, I think. And 9 is better than 7.

This produces a very "lumpy" transition, where a third of the
committee's makeup changes.

There is also the difficulty that our voting system is not good at
multi-seat elections: if out of candidates A1,A2,B1,B2 51% of electors
prefer A* to B*, we repeated Condorcet elects A1,A2 when A1,B1 would
be better.

I think running one election per year would be about right. Doing
that with a committee of 9 would result in, on average, 9 year term
limits.

I would suggest that the rule should be "longest serving member
retires and is ineligible for immediate reappointment".

Ian.

[Anthony Towns]

Post by Russ Allbery

Post by Anthony Towns
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... [...]

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

Okay, let's see where that goes...

Post by Russ Allbery
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.

Or, in general, n people's terms expire every 6n months. You could have
3 people every 18 months, or 4 people every 2 years too.

Post by Russ Allbery
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.

Two year terms would be electing (up to) four people a year. That seems
a lot? Eg, assuming two year term, and one year ineligible after two
consecutive terms, that'd be:

2014: Alice, Bob re-elected; Carol, Dave newly-elected
2015: Emma, Fred re-elected; Greta, Henry newly-elected
2016: Carol, Dave re-elected; Ivy, Jason newly-elected
(Alice, Bob ineligible)
2017: Greta, Henry re-elected; Karen, Larry newly-elected
(Emma, Fred ineligible)
2018: Ivy, Jason re-elected; Miley, Nathan newly-elected
(Carol, Dave ineligible)
...

Given only four tech ctte members have been on the ctte less than
essentially four years (Klee, who was an original member; myself, who
chose to not stay longer than 3 years; and Keith and Colin who are
both still serving), it seems to me like four years is a reasonable
lower-bound.

For the sake of something concrete to improve upon, how about, ummm...

- The committee's membership will be reviewed annually on August 16th.

- At that point, if there have not been at least two members leave
the committee in the past 12 months, the most senior committee member's
term expires immediately.

- In addition, if there are more than five members in the committee, and
no members have left the committee in the the past 12 months, the
second most senior committee member's term also expires immediately.

- A member's seniority is determined by the date of their most recent
appointment to the committee. In the case of multiple members appointed
to the committee on the same day, ties are broken based on their
debian.org uid (lower uid, more senior).

August 16th, because that's Debian's birthday, and choosing an arbitrary
date seemed to make it easier to deal with. Having it be a continuously
rolling 12 months could be a good idea if it can be worded reasonably?

Also possible would be just having the most senior ctte member's term
expire on Aug 16th unconditionally.

To make it two year terms, make the four most senior people's terms expire
each year.

To make it six year terms, you'd probably have to go with a rolling 18
month period.

There's nothing in the above preventing a member from being immediately
reappointed once their term expires, if the remaining committee vote
and the DPL agrees. However...

Possible candidacy rules:

- A developer is not eligible to rejoin the committee if they have
been a member of the committee within the preceeding twelve months.

(One term, then a break)

- A developer is not eligible to rejoin the committee if they have
been a member for more than four of the past five years.

(Max two consecutive terms, roughly)

- A developer is not eligible to rejoin the committee unless another
appointment has been made since they were most recenty a member.

(No term limit per se, but continually enforce some new blood)

- When considering candidates for inclusion in the committee, the ballot
must include at least one candidate who has not been a member of the
committee in the previous four years.

(Enforce considering new members, not necessarily having them)

- Any eligible developer nominated by the DPL or by at least two
developers in the period between August 1st and August 16th will be
considered for appointment to the committee, and be included on the
next ballot. Any developer so nominated may, however, withdraw their
nomination if they so choose.

(Enforce more meaningful consideration of new members, and provide a
nomination mechanism)

(This would work well with always expiring the most senior member's
term, because then there would be a guaranteed vacancy to fill after
August 16th, so nominations would always be relevant; even if none might
actually end up being appointed)

I've got a weak preference for the later options that don't set hard
term limits, personally.

Cheers,
aj

[Russ Allbery]

Post by Anthony Towns

Post by Russ Allbery
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.

Two year terms would be electing (up to) four people a year. That seems
a lot?

I was assuming that continuing on was automatic if you wanted to and most
people wouldn't step down after one term, which after thinking about it
more are both bad assumptions. So yes, I agree with you: four year terms
are probably the minimum.

I'm still skeptical that something built around people typically serving
for eight years is the sort of turnover we want, but it's the conservative
approach and doesn't change too much at once. Which has some definite
merits.

Post by Anthony Towns
- A developer is not eligible to rejoin the committee if they have
been a member for more than four of the past five years.
(Max two consecutive terms, roughly)

I think this is my preference.

Post by Anthony Towns
- When considering candidates for inclusion in the committee, the ballot
must include at least one candidate who has not been a member of the
committee in the previous four years.
(Enforce considering new members, not necessarily having them)

The social pressures here don't work very well. In general, any approach
that has the existing committee decide whether to retain a member who's
already on the committee has the potential for hard feelings, creating
future difficulties working together, and so forth. This is why I favor
some system that requires a pause; that way, no one is put in the position
of having to refuse to reappoint someone that they've worked with for the
last eight years.

Post by Anthony Towns
- Any eligible developer nominated by the DPL or by at least two
developers in the period between August 1st and August 16th will be
considered for appointment to the committee, and be included on the
next ballot. Any developer so nominated may, however, withdraw their
nomination if they so choose.

I'm not sure there's any need to say something about this, unless there's
a perception that the TC's process for selecting new members is somehow
broken.

[Ian Jackson]

Post by Russ Allbery
I'm not sure there's any need to say something about this, unless there's
a perception that the TC's process for selecting new members is somehow
broken.

If we introduce a constitutional term limit, the balance of power
between the DPL and the TC is radically altered:

At the moment, if the DPL says "I will only approve Alice", the TC can
simply say "well we won't appoint anyone then".

With term limits, the DPL can say that and eventually get their way.

Perhaps, though, this is an improvement. After all if the DPL has
such a struggle with the TC and the Developers reelect the DPL, the
Developers should get their way.

Ian.

[Philip Hands]

Post by Ian Jackson

Post by Russ Allbery
I'm not sure there's any need to say something about this, unless there's
a perception that the TC's process for selecting new members is somehow
broken.

If we introduce a constitutional term limit, the balance of power
At the moment, if the DPL says "I will only approve Alice", the TC can
simply say "well we won't appoint anyone then".
With term limits, the DPL can say that and eventually get their way.
Perhaps, though, this is an improvement. After all if the DPL has
such a struggle with the TC and the Developers reelect the DPL, the
Developers should get their way.

Why does this remind me of USA Presidents, and their attempts to stuff
the supreme court with friendly judges? Which then leads me to expect
people trying to game the system by delaying a referral to the TC to
await the departure of someone thought to be unsympathetic to their
cause -- I hope we never get there ... there's enough inertia in Debian
as it is ;-)

I also wonder what is to be done about someone coming to the end of
their term during the middle of an ongoing discussion. How well do you
(Ian) think you'd have coped if you knew that the recent decisions had
to come to a vote by a particular date, otherwise you'd lose your vote?
I doubt that would have made things better.

Perhaps one could say that anyone on the TC at the start of a discussion
gets to stay for the duration (if they want to, perhaps), but what about
a series of votes as we saw recently?

I suppose what constitutes the same discussion could be a decision for
the committee, or perhaps the chair, but that might well just end up
being another thing to argue about if the issue is already contentious.

Cheers, Phil.

[Ian Jackson]

Post by Philip Hands
I also wonder what is to be done about someone coming to the end of
their term during the middle of an ongoing discussion. How well do you
(Ian) think you'd have coped if you knew that the recent decisions had
to come to a vote by a particular date, otherwise you'd lose your vote?
I doubt that would have made things better.

This is a good point.

Post by Philip Hands
Perhaps one could say that anyone on the TC at the start of a discussion
gets to stay for the duration (if they want to, perhaps), but what about
a series of votes as we saw recently?

Perhaps the answer is to embed the term limit not in the Constitution,
but to agree it by resolution of the TC itself. That way if there is
a particularly controversial vote coming up, the TC could delay the
term expiry. I think this situation would be rare.

Doing the term limit as a standing decision of the TC will also make
it easier to (a) experiment with different approaches (b) deal with
edge cases.

For example, I think it would be very helpful to allow the outgoing TC
member to vote in the ballot on their own replacement. That's
difficult to do with a constitutional term limit.

Post by Philip Hands
I suppose what constitutes the same discussion could be a decision for
the committee, or perhaps the chair, but that might well just end up
being another thing to argue about if the issue is already contentious.

I think we could probably come up with a wording to deal with this
which I hope the TC members as a whole would interpret honestly.

Ian.

[Anthony Towns]

Post by Russ Allbery
I'm still skeptical that something built around people typically serving
for eight years is the sort of turnover we want, but it's the conservative
approach and doesn't change too much at once. Which has some definite
merits.

I'm not sure that two terms would necessarily be the normal case;
I suspect some of that is just that having to quit and appoint a new
member to the ctte is work and it's always easier to just let things be.

Having thought about it some more, I don't think "longest serving ctte
member's term ends on <date>, unconditionally" is a good rule. For one
thing, it means that on day-before-<date>, the longest serving ctte member
can resign and force the second longest serving ctte member's term to end
"prematurely".

I might have another go at seeing if I can word it for rolling twelve
months, to see if that's workable.

Post by Russ Allbery

Post by Anthony Towns
- A developer is not eligible to rejoin the committee if they have
been a member for more than four of the past five years.
(Max two consecutive terms, roughly)

I think this is my preference.

Yeah, it seems plausible.

Post by Russ Allbery

Post by Anthony Towns
- When considering candidates for inclusion in the committee, the ballot
must include at least one candidate who has not been a member of the
committee in the previous four years.
(Enforce considering new members, not necessarily having them)

The social pressures here don't work very well. In general, any approach
that has the existing committee decide whether to retain a member who's
already on the committee has the potential for hard feelings, creating
future difficulties working together, and so forth.

Yeah, that's a fairly persuasive argument.

Post by Russ Allbery

Post by Anthony Towns
- Any eligible developer nominated by the DPL or by at least two
developers in the period between August 1st and August 16th will be
considered for appointment to the committee, and be included on the
next ballot. Any developer so nominated may, however, withdraw their
nomination if they so choose.

I'm not sure there's any need to say something about this,

Me either.

Cheers,
aj

[Anthony Towns]

Post by Anthony Towns
I might have another go at seeing if I can word it for rolling twelve
months, to see if that's workable.

Okay, so I gave it a go, and came up with:

- A Technical Committee member's term will end upon resignation, removal
or expiry.

- A Technical Committee member may resign by stating such in public
email to the committee discussion list.

- If the Technical Committee and the Project Leader agree they may
remove or replace an existing member of the Technical Committee.

- The most senior member of the Technical Committee's term expires
immediately, if in the preceding twelve months fewer than two
Committee members' terms have ended. Seniority is determined
by a member's most recent date of appointment to the Committee,
with ties broken by length of membership in the Project.

That should work okay along with:

- A developer is not eligible to be reappointed to the committee if
they have been a member for more than four of the past five years.

But it sure gets confusing, especially with Colin having to resign
after four years in order to be re-appointed to serve eight years,
rather than maxing out at about six years and not being immediately
re-appointable. Worse still with Keith who (I think) would max out
after 3 and a bit years, get reappointed, and would then have to
resign a few months later and get reappointed in order to max out at
eight years...

Maybe it would be simpler and better to go with something like:

- On August 16th of each year, the terms of any Committee Members who
have served on the committee for six or more years will ordinarily
automatically expire. However an individual member's term may be
extended for the next year, if two or more Committee Members have
either left the Committee in the preceding twelve months, or served on
the Committee for a longer continuous period.

- A developer is not eligible to be reappointed to the Committee if
they have been a member of the Committee at any time in the preceding
twelve months.

Assuming no one resigns or gets reappointed to the committee, that would mean:

- Aug 16 2014 - Ian (16y), Bdale (14y) out; Alice, Bob in
- Aug 16 2015 - Steve (10y), Andi (10y) out; Carol, Dave in
- Aug 16 2016 - Russ (7y), Don (7y) out, Emma, Fred in
- Aug 16 2017 - Colin (6y) out, Greta in
- Aug 16 2018 - [no change]
- Aug 16 2019 - [no change]
- Aug 16 2020 - Keith (7y) out, Henry in

Leaving:
Alice, Bob - 6 years in
Carol, Dave - 5 years in
Emma, Fred - 4 years in
Greta - 3 years in
Henry - fresh blood

Specifying "six years" means you effectively get seven years though,
unless appointments manage to happen on or before Aug 16th. "5.5
years" is probably better, which would bring Keith's term back to
2019, and result in just under six years in practice, I think. "4.5
years" would get to Stefano's suggestion of 5y on / 1y off, which
might look like:

- Aug 16 2014 - Ian (16y), Bdale (14y) out; Alice, Bob in
- Aug 16 2015 - Steve (10y), Andi (10y) out; Carol, Dave in
- Aug 16 2016 - Russ (7y), Don (7y) out, Emma, Fred in
- Aug 16 2017 - Colin (6y) out, Greta in
- Aug 16 2018 - Keith (5y) out, Henry in

Leaving:
Alice, Bob - 4 years in
Carol, Dave - 3 years in
Emma, Fred - 2 years in
Greta - 1 year in
Henry - fresh blood

Cheers,
aj

[Ian Jackson]

Post by Anthony Towns

Post by Anthony Towns
I might have another go at seeing if I can word it for rolling twelve
months, to see if that's workable.

This is a good general approach but I would quibble with a couple of

Post by Anthony Towns
- A Technical Committee member's term will end upon resignation, removal
or expiry.
- A Technical Committee member may resign by stating such in public
email to the committee discussion list.
- If the Technical Committee and the Project Leader agree they may
remove or replace an existing member of the Technical Committee.
- The most senior member of the Technical Committee's term expires
immediately, if in the preceding twelve months fewer than two
Committee members' terms have ended. Seniority is determined
by a member's most recent date of appointment to the Committee,
with ties broken by length of membership in the Project.

Firstly, I think this should be set as a backstop rather than be the
normal case. I think the normal case should be that the TC would
replace a member before the deadline. So I would make some changes:

- Term limit: Every 1st of November, the most senior member of the
Technical Committee's is immediately and automatically removed
from the Committee, if in the preceding 27 months less than two
new Committee members have been appointed. Seniority is
determined by a member's most recent date of appointment to the
Committee, with ties broken by length of membership in the
Project.

But adding non-normative text:

The Technical Committee should arrange to appoint fresh members
on a regular basis, at least as often (and probably more often)
than the minimum specified here. This should normally be done in
a manner that permits the outgoing member to participate in the
selection.

Note that I'm proposing an effective constitutional maximum term of 9
years (assuming we increase the committee size, which seems likely).

But the TC would have the freedom - and the encouragement of the
non-normative text - to have a faster turnover. Also, the TC has the
freedom (if a 9 year term is desired) to, either run one appointment
every year or two appointments every two years, or something in
between.

I think 6 years is probably a better actual term than 9 or 4.5. So I
would be in favour of the TC running an election for 1 place every 18
months.

Post by Anthony Towns
- A developer is not eligible to be reappointed to the committee if
they have been a member for more than four of the past five years.

I would prefer:

- For the purposes of seniority and term expiry, someone who leaves
the committee but rejoins it less than 10 months later, is
treated as having been a member continuously throughout that gap.

I say 10 months to allow for some slop: if the TC runs annual
recruitment it might take more or less time each time so actual
appointments would be slightly offset and terms wouldn't be exactly
whole numbers of years.

You wouldn't want someone who was reappointed after roughly a year's
absence but in a quick process to be immediately retired again (and
indeed the whole appointment to be discounted for the retirement
purposes).

Post by Anthony Towns
[on your earlier non-specified-date scheme:]
But it sure gets confusing, especially with Colin having to resign
after four years in order to be re-appointed to serve eight years,
rather than maxing out at about six years and not being immediately
re-appointable. Worse still with Keith who (I think) would max out
after 3 and a bit years, get reappointed, and would then have to
resign a few months later and get reappointed in order to max out at
eight years...

This is a consequence of the rule running continuously rather than
at fixed intervals.

I think we should have fixed intervals but a minimum replenishment
rate rather than fixed terms. The effect of that is to phase the new
regime in in a sensible way.

Ian.

[Anthony Towns]

Post by Ian Jackson
- Term limit: Every 1st of November, the most senior member of the
Technical Committee's is immediately and automatically removed
from the Committee, if in the preceding 27 months less than two
new Committee members have been appointed. Seniority is
determined by a member's most recent date of appointment to the
Committee, with ties broken by length of membership in the
Project.

27 months prior to November 1st is August 1st two years prior. (Is
there any particular rationale for Nov 1st?)

So by my count, that would result in:

- 2014-11-01: Keith appointed in the previous 27 months, Ian removed;
"Alice" appointed
- 2015-11-01: Keith and Alice appointed in the previous 27 months, no
compulsory removal
- 2016-11-01: Alice appointed in the previous 27 months, Bdale
removed, "Bob" appointed
- 2017-11-01: Bob appointed in previous 27 months, Steve removed,
"Carol" appointed
- 2018-11-01: Bob and Carol appointed in the previous 27 months, no
compulsory removal
- 2019-11-01: Carol appointed in previous 27 months, Andi removed,
"Dave" appointed
- 2020-11-01: Dave appointed in previous 27 months, Don removed,
"Emma" appointed
- 2021-11-01: Dave and Emma in previous 27, no compulsory removal
- 2022-11-01: Emma in previous 27, Russ removed, "Fred" appointed
- 2023-11-01: Fred in prev 27; Colin removed, "Gwen" appointed
- 2023-11-01: Fred and Gwen in prev 27, no compulsory removal
- 2024-11-01: Gwen in prev 27, Keith removed, "Henry" appointed
- 2024-11-01: Henry in prev 27, Alice removed, ...

Total term lengths would then be:
- Ian: 16 years (1998-2014)
- Bdale: 15 years (2001-2016)
- Steve: 11 years (2006-2017)
- Andreas: 13 years (2006-2019)
- Don: 11 years (2009-2020)
- Russ: 13 years (2009-2022)
- Colin: 12 years (2011-2023)
- Keith: 11 years (2013-2024)
- Alice: 10 years (2014-2024)

That seems overly long.

Post by Ian Jackson
The Technical Committee should arrange to appoint fresh members
on a regular basis, at least as often (and probably more often)
than the minimum specified here.

That's only possible when the ctte isn't full; if the ctte's full, the
only way to refresh members is for someone to be removed... If the
idea is to leave have some spare slots on the committee on an ongoing
basis, that may mean even longer terms than implied above, eg an
additional twelve months for Steve:

- 2014-11-01: Keith appointed in the previous 27 months, Ian removed;
- 2015-10-30: "Alice" appointed
- 2015-11-01: Keith and Alice appointed in the previous 27 months, no
compulsory removal
- 2016-11-01: Alice appointed in the previous 27 months, Bdale removed
- 2017-10-30: "Bob" appointed
- 2017-11-01: Allice and Bob appointed in previous 27 months, no
compulsory removal
- 2018-11-01: Bob appointed in prev 27, Steve removed

Post by Ian Jackson
I think 6 years is probably a better actual term than 9 or 4.5. So I
would be in favour of the TC running an election for 1 place every 18
months.

1 place every 18 months would be an average term of 8x1.5 = 12 years,
or 9x1.5 = 13.5 years...

Post by Ian Jackson
- For the purposes of seniority and term expiry, someone who leaves
the committee but rejoins it less than 10 months later, is
treated as having been a member continuously throughout that gap.

I don't think that would have any teeth:

2014-11-01: only one recent appointment, Ian most senior, Ian removed
2014-11-02: Ian reappointed, term treated as continuous
2015-11-01: only one recent appointment, Ian most senior, Ian removed
2015-11-02: Ian reappointed, term treated as continuous
2016-11-01: no recent appointments, Ian most senior, Ian removed
2016-11-02: Ian reappointed, term treated as continuous
...

Post by Ian Jackson

Post by Anthony Towns
[on your earlier non-specified-date scheme:]
But it sure gets confusing, especially with Colin having to resign
after four years in order to be re-appointed to serve eight years,
rather than maxing out at about six years and not being immediately
re-appointable. Worse still with Keith who (I think) would max out
after 3 and a bit years, get reappointed, and would then have to
resign a few months later and get reappointed in order to max out at
eight years...

This is a consequence of the rule running continuously rather than
at fixed intervals.

No, it's a consequence of the rule allowing for approximately one
immediate re-appointment. The combination of:

- The committee's membership will be reviewed annually on August 16th.
- At that point, if there have not been at least two members leave
the committee in the past 12 months, the most senior committee member's
term expires immediately.
- In addition, if there are more than five members in the committee, and
no members have left the committee in the the past 12 months, the
second most senior committee member's term also expires immediately.
- A developer is not eligible to rejoin the committee if they have
been a member for more than four of the past five years.

has a similar effect. If Colin were to resign prior Aug 2015, he could
be reappointed and stay on board until around Aug 2019 or later; but
if he didn't, he and Keith would be the most senior remaining members
by Aug 2017, and only Keith would be eligible to be reappointed at
that point.

I think that leaves me still leaning towards the following or
something pretty close to it:

- On August 16th of each year, the terms of any Committee Members who
have served on the committee for 50 months (4 years and 2 months) or
more will ordinarily automatically expire. However an individual
member's term may be extended for an additional twelve months if there
are two or more Committee Members who have either served on the
Committee for a longer continuous period or left the Committee in the
preceding twelve months.

- A developer is not eligible to be reappointed to the Committee if
they have been a member of the Committee at any time in the preceding
twelve months.

Cheers,
aj

[Anthony Towns]

Post by Anthony Towns

Post by Ian Jackson
- Term limit: Every 1st of November, the most senior member of the
Technical Committee's is immediately and automatically removed
from the Committee, if in the preceding 27 months less than two
new Committee members have been appointed. Seniority is
determined by a member's most recent date of appointment to the
Committee, with ties broken by length of membership in the
Project.

27 months prior to November 1st is August 1st two years prior. (Is
there any particular rationale for Nov 1st?)

I missed the potential interaction with increasing the committee size
to 9. With a two week minimum discussion period and a two week voting
period, the earliest that could be accepted would be July 30th or so,
so it seems likely that would result in an extra appointment in the
period between Aug 1st 2014 and Nov 1st 2014. Combined with the above,
that's something more like:

2014-09-01 "Zach" appointed as 9th ctte member
2014-11-01 Keith @ 12 months, Zach @ 2 months, no compulsory removals
2015-11-01 Keith @ 24 months, Zach @ 14 months, no compulsory removals
2016-11-01 Zach @ 26 months, Ian removed, "Alice" appointed
2017-11-01 Alice @ 12 months, Bdale removed, "Bob" appointed
2018-11-01 Alice @ 24 months, Bob @ 12 months, no compulsory removals
2019-11-01 Bob @ 24 months, Steve removed, "Carol" appointed
2020-11-01 Carol @ 12 months, Andi removed, "Dave" appointed
2021-11-01 Carol @ 24 months, Dave @ 12 months, no compulsory removals
2022-11-01 Dave @ 24 months, Don removed, "Emma" appointed
2023-11-01 Emma @ 12 months, Russ removed, "Fred" appointed
2024-11-01 Emma @ 24 months, Fred @ 12 months, no compulsory removals
2025-11-01 Fred @ 24 months, Colin removed, "Gwen" appointed
2026-11-01 Gwen @ 12 months, Keith removed, "Harry" appointed
2027-11-01 Gwen @ 24 months, Harry @ 12 months, no compulsory removals
2028-11-01 Harry @ 24 months, Zach removed, "Irene" appointed
2029-11-01 Irene @ 12 months, Alice removed, "Jack" appointed

Total term lengths would then be:
- Ian: 18 years (1998-2016)
- Bdale: 16 years (2001-2017)
- Steve: 13 years (2006-2019)
- Andreas: 14 years (2006-2020)
- Don: 13 years (2009-2022)
- Russ: 14 years (2009-2023)
- Colin: 14 years (2011-2025)
- Keith: 13 years (2013-2026)
- Zach: 13 years (2014-2028)
- Alice: 13 years (2016-2029)

ie, an additional couple of years for each member compared to my

Post by Anthony Towns
- Ian: 16 years (1998-2014)
- Bdale: 15 years (2001-2016)
- Steve: 11 years (2006-2017)
- Andreas: 13 years (2006-2019)
- Don: 11 years (2009-2020)
- Russ: 13 years (2009-2022)
- Colin: 12 years (2011-2023)
- Keith: 11 years (2013-2024)
- Alice: 10 years (2014-2024)
I think that leaves me still leaning towards the following or
- On August 16th of each year, the terms of any Committee Members who
have served on the committee for 50 months (4 years and 2 months) or
more will ordinarily automatically expire. However an individual
member's term may be extended for an additional twelve months if there
are two or more Committee Members who have either served on the
Committee for a longer continuous period or left the Committee in the
preceding twelve months.
- A developer is not eligible to be reappointed to the Committee if
they have been a member of the Committee at any time in the preceding
twelve months.

Cheers,
aj

[Holger Levsen]

Hi Anthony,

Post by Anthony Towns
Would anyone else be supportive of a proposal to set a term for tech ctte
membership?

yes.

Post by Anthony Towns
YMMV. I think I'd rather second a proposal along these lines than actually
propose it...

me, too, sorry.

Thanks for bringing this up on -project!


cheers,
Holger

[Tollef Fog Heen]

]] Anthony Towns

Post by Anthony Towns
Would anyone else be supportive of a proposal to set a term for tech ctte
membership?

Yes, absolutely. I've been chatting to various people about it over the
last couple of months, so..

[...]

Post by Anthony Towns
I think set terms, with no term limits would make sense (ie, you're
appointed to the ctte, you stay on it for X years, then you either say
"thanks, but enough's enough" or "that was fun, I'd like to keep doing
it" and the ctte and DPL considers whether to reappoint you in the
usual fashion.

I'd actually like what Russ talks about with having a «serve for one (or
two) terms, then don't serve for a term, else it'd be easy to always go
«yup». Getting new people in is valuable.

Post by Anthony Towns
Personally, I think 3 or 4 year terms ought to be long enough, but
that would mean kicking everyone but Colin and Keith off the ctte
immediately. Terms of 6-8 years would leave half the current ctte around
to reconstitute the ctte. With a term of 16 years (which no member has
exceeded yet), a new member would have to be voted on once every two
years on average to maintain a full 8-member ctte.

I like Russ' approach here too, assign a random term start so we don't
suddenly have a large number of people being forced to resign and be
reappointed. Maybe just do it as a FIFO with a fixed distribution over
whatever we end up as the term limit?

Post by Anthony Towns
YMMV. I think I'd rather second a proposal along these lines than actually
propose it...

I'd be happy to propose something if we get something approaching
consensus on a proposal.

[Stefano Zacchiroli]

Post by Tollef Fog Heen
]] Anthony Towns

Post by Anthony Towns
Would anyone else be supportive of a proposal to set a term for tech
ctte membership?

Seconded as well.

I've a couple of contributions I wanted to make to this thread, even
though they've largely been superseded by Russ' comments :-). But
anyway:

- in this kind of "reform" discussions I find generally useful to
distinguish two aspects: 1) the ideal model we want to have, 2) how to
migrate from the current model to that. Entangling the two aspects
usually make the status quo win over everything else, just because
migration is hard.

For the migration in this specific case, random assigning start term
dates as suggested by Russ seems to be a brilliant idea.

- continuity is valuable in a body like the tech-ctte, where there
aren't that many decisions on a yearly basis (and hence, for instance,
it takes time to get new members up to speed). There might have been
too much continuity in the current tech-ctte membership, but that's no
reason to exaggerate in the opposite direction when introducing a
turnover process.

Based on examples I've recently witnessed in other organizations, I
agree that a good model for the tech-ctte would be the one already
mentioned by Russ (consecutive year limit + minimum suspension time),
but with less stringent durations. I believe a maximum of 5 years in a
row with a minimum 1-year suspension before being able to join again
would work well for our tech-ctte.

- more generally, I think that all Debian "core" teams (if not *all*
teams...) would benefit from a turnover process that requires
individual members to reaffirm, on a yearly basis, their continued
interest in keeping the role. This is to avoid that people remain on
the team simply for inertia, even though they have no more
time/interest for the corresponding tasks. It will also help
developers in periodically reassessing/retargeting their Debian
involvement, reducing the burnout risk.

This is nothing specific to the tech-ctte, but they could probably
benefit from it too.

My 2 cents,
Cheers.

[Tollef Fog Heen]

]] Stefano Zacchiroli

Post by Stefano Zacchiroli
- in this kind of "reform" discussions I find generally useful to
distinguish two aspects: 1) the ideal model we want to have, 2) how to
migrate from the current model to that. Entangling the two aspects
usually make the status quo win over everything else, just because
migration is hard.

Agreed. I think it's important to point this out and that we haven't
conflated those issues (at least not yet).

Post by Stefano Zacchiroli
- more generally, I think that all Debian "core" teams (if not *all*
teams...) would benefit from a turnover process that requires
individual members to reaffirm, on a yearly basis, their continued
interest in keeping the role. This is to avoid that people remain on
the team simply for inertia, even though they have no more
time/interest for the corresponding tasks. It will also help
developers in periodically reassessing/retargeting their Debian
involvement, reducing the burnout risk.

We in DSA have talked about this, not so much for group involvement, but
to minimize the amount privileges people have. Something like «mail
everybody who's a member of a team once a year, have them cross off the
groups they would still like to be a member of, GPG-sign and return».
Currently, we have things like I'm still a member of webwml, even though
I haven't done anything there for years, simply because nobody cleans
that list.

Cheers,

[Anthony Towns]

Post by Stefano Zacchiroli
I believe a maximum of 5 years in a
row with a minimum 1-year suspension before being able to join again
would work well for our tech-ctte.

I think 5 years would be awkward in an 8-member ctte; you'd end up with:

2010: 2 members appointed
2011: 2 members appointed
2012: 1 member appointed
2013: 2 members appointed
2014: 1 member appointed
2015: 2 members replaced
...

4 years is easy (2 members per year), as is 8 years (1 member per year),
and 6 years isn't too bad (4 members every three years; or 2 members
every year and half).

Bumping the ctte size to 10 members could make 5 years work of
course. Think it makes sense to have the term proportional to the ctte
size though, so turn over can be regular.

Cheers,
aj

[Anthony Towns]

Post by Stefano Zacchiroli
- continuity is valuable in a body like the tech-ctte, where there
aren't that many decisions on a yearly basis (and hence, for instance,
it takes time to get new members up to speed).

You could get continuity by having past members continue to participate
in tech ctte discussions; they just wouldn't get a vote in the outcome...

Also, new ctte members could have been participating in ctte discussions
previously (or just general Debian development issues on -devel, -policy,
etc), so they kind-of should be mostly up to speed already. Keith
was appointed in December, and engaged in the init system question by
January, eg.

Cheers,
aj

[Francesca Ciceri]

Post by Stefano Zacchiroli
- more generally, I think that all Debian "core" teams (if not *all*
teams...) would benefit from a turnover process that requires
individual members to reaffirm, on a yearly basis, their continued
interest in keeping the role. This is to avoid that people remain on
the team simply for inertia, even though they have no more
time/interest for the corresponding tasks. It will also help
developers in periodically reassessing/retargeting their Debian
involvement, reducing the burnout risk.

This.
We totally need this.

I really feel that burnout is huge risk to be taken in account when
volunteering with a community project and if we can minimize that risk,
then we'll have a healthier community.

This idea has been in my mind for a while, and I know from experience
that when you realize that volunteering in some teams is not a life
sentence, then you feel again enthusiasm toward Debian work.
It's pretty difficult, but taking the time to rethink your involvement
can be vital. Not only for the individual, but also for the teams
involved.

So to be clear: are you tired of doing Debian work? Do you feel it's
your responsibility and not fun at all, like in the beginning?
Then:

1. remember that it's not a life sentence
2. there will be someone else to carry on your work (take that,
Galadriel!¹)
3. look around for other team you'd like to work on in Debian
4. well, if you don't find anything, there are other projects beside
Debian that could use a hand


Cheers.
Francesca

¹ Galadriel: "This task was appointed to you, Frodo of the Shire. And if
you do not find a way, no one will." (no pressure, furry midget. Go and
fix our past mistakes, like letting Sauron create the rings). [Yes, in
the books is Elrond saying this.]
Also:
http://blog.zouish.org/nonupdd/#/22 and the next 2-3 slides.

[Jonas Smedegaard]

Quoting Francesca Ciceri (2014-05-24 09:30:26)

Post by Francesca Ciceri
http://blog.zouish.org/nonupdd/#/22 and the next 2-3 slides.

Very nice slides, the whole set!

(and I mean the content, not the slick wrapping)


- Jonas

[Brian Gupta]

Post by Anthony Towns
Hello world,
Would anyone else be supportive of a proposal to set a term for tech ctte
membership?
Ian: May/Dec 1998 (15 years, 5 months) [0]
Bdale: Apr 2001 (13 years, 1 month) [1]
Andreas: Jan 2006 (8 years, 4 months) [2]
Steve: Jan 2006 (8 years, 4 months) [2]
Russ: Jan 2009 (5 years, 4 months) [3]
Don: Jan 2009 (5 years, 4 months) [3]
Colin: Aug 2011 (2 years, 9 months) [4]
Keith: Nov 2013 (6 months) [5]
I think set terms, with no term limits would make sense (ie, you're
appointed to the ctte, you stay on it for X years, then you either say
"thanks, but enough's enough" or "that was fun, I'd like to keep doing
it" and the ctte and DPL considers whether to reappoint you in the
usual fashion.
Personally, I think 3 or 4 year terms ought to be long enough, but
that would mean kicking everyone but Colin and Keith off the ctte
immediately. Terms of 6-8 years would leave half the current ctte around
to reconstitute the ctte. With a term of 16 years (which no member has
exceeded yet), a new member would have to be voted on once every two
years on average to maintain a full 8-member ctte.
I think it'd be healthy if there was a rule something like "an ex-member
may not be reappointed to the committee unless someone else has been
appointed to the ctte since s/he was last a member". That would mean
you couldn'y have "Alice, Bob, Carol, Dave" as the tech ctte with an
agreement that they'll just reappoint each other anytime their term
expires; they'd have to appoint someone from outside the group (Emma,
say) first. Call it an anti-Cabal measure. I'm not sure there's a simple
and obvious way to phrase such a measure though, so maybe it's too hard.
At present, the only way for someone to leave the tech ctte is for them to
disappear, resign, or be hounded out by either their fellow ctte members
or a GR. IMO, it would be nice if there was a way out of the ctte that had
more of a feeling of winning / leaving at the top of the game than those.
YMMV. I think I'd rather second a proposal along these lines than actually
propose it...
Cheers,
aj

My apologies, I haven't been involved with Debian for that long in the
grand scheme of things, but my understanding was that the relatively
long average length of tenure of our TC was something I understood to
be a feature, not a bug. (IE: I thought the role was fairly limited,
and continuity and wisdom combined with strong technical understanding
were the key attributes that we value in the TC.)

While I would not be opposed to a requirement asking ctte to annually
reaffirm that they have the time and desire to continue, it seems to
my eyes that the current system doesn't seem functionally broken, and
would appreciate examples of actions or decisions made, as to why
change is needed/desired?

Thanks,
Brian

[Paul Wise]

Post by Anthony Towns
Would anyone else be supportive of a proposal to set a term for tech ctte
membership?

No-one in the thread seems to be reading Planet Debian, but here is an
alternative proposal:

http://xana.scru.org/xana2/ranticore/techctte/
--
bye,
pabs

http://wiki.debian.org/PaulWise

[Russ Allbery]

Post by Paul Wise
No-one in the thread seems to be reading Planet Debian, but here is an
http://xana.scru.org/xana2/ranticore/techctte/

I do read Planet Debian, actually. But that's not a proposal. :)

I will say that term limits are not, in my mind, any sort of a magic
band-aid. I think we could be doing a lot better on all the points that
Clint mentioned, and I don't think term limits will fix any of those
things. For me, term limits are a specific change to do a specific thing
that I think would be an improvement: involve more project members in the
Technical Committee.

Obviously, if one's opinion of the Technical Committee is that it's a good
way to cordon off the people who waste everyone else's time and make them
all waste each other's time (an attempted summary of what I believe to be
Clint's basic opinion about the TC), one is not going to agree with the
goal of involving more people in that process.

If I were going to try to meaningfully tackle more of the issues that
Clint mentions, I would do something quite a bit more radical, but I'm not
sure there's really much project enthusiasm for doing that, so I'm not
sure there's a lot of point in talking about it. (The shape is probably
predictable to anyone who knows me and knows how much I dislike the
concept of meritocracy.)

[Russ Allbery]

Post by Russ Allbery

Post by Paul Wise
No-one in the thread seems to be reading Planet Debian, but here is an
http://xana.scru.org/xana2/ranticore/techctte/

I do read Planet Debian, actually. But that's not a proposal. :)

He appears to be proposing "dissolution of the tech-ctte", did I
misunderstand the post?

Oh, that part. I guess I'm so used to that from Clint that I skimmed past
it and thought you were talking about the Herbert reference. I think
that's his point in the first paragraph, though: that he doesn't have a
suitable replacement to propose and just dissolving it won't actually
work.

[Paul Wise]

Post by Russ Allbery

Post by Paul Wise
No-one in the thread seems to be reading Planet Debian, but here is an
http://xana.scru.org/xana2/ranticore/techctte/

I do read Planet Debian, actually. But that's not a proposal. :)

He appears to be proposing "dissolution of the tech-ctte", did I
misunderstand the post?
--
bye,
pabs

http://wiki.debian.org/PaulWise