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

[SUMMARY] Maximum term for tech ctte members



Hi,

I'm trying to summarize the thread here, so that others have an easy way
in.

Reminder: all pointers are to message-ids. You can read the mails using
https:///lists.debian.org/MESSAGE-ID .

There's an agreement that more turnover inside the TC would be a good
thing, by favoring the replacement of the more senior members by new
members. The general idea is to have a maximum term length for TC
members.

One question that was discussed is whether a TC member should be able to
do several terms in a row.  I was initially in favor of that (see
<[🔎] 20141119103725.GB9825@xanadu.blop.info>), but changed my mind after
reading the arguments in <[🔎] 20141119191359.GA30428@master.debian.org>.
The solution would be to have a "mandatory vacation" of one year between
two terms.

There's quite a lot of discussions about different models to ensure
turnover.  There's agreement that a term duration of about 4 years would
be good. For 8 members, that means about 2 replacements per year on
average.

Here is a tentative list of the various proposals:

"soft": <[🔎] 20141119220621.GA31739@master.debian.org>
  Technical Committee members are encouraged to serve for a term of
  between three and six years.

"max": <[🔎] 20141120192253.GA6120@jtriplet-mobl1>
  No Developer may serve on the Technical Committee for more than 4
  years out of any 6 year period.  A Developer's term on the Technical
  Committee expires if they would exceed this limit.
The two main drawbacks are:
- replacements are not necessarily well balanced over time
- it requires a transitional measure over the next few years, such as:
    As a transitional measure, the terms of the current members of the
    Technical Committee shall instead expire every 6 months starting on
    2015-01-01, in descending order of seniority; term limits then apply
    to them as normal.  (<[🔎] 20141120212303.GA6945@jtriplet-mobl1>)

"2": <[🔎] 20141120204606.GA30491@upsilon.cc>
    Every year, the two most senior members are expired.
Main drawbacks:
- This ignores resignations, so the turnover might be higher than 2/y
- <[🔎] 20141119091345.GA9825@xanadu.blop.info>: It could be an incentive to
  *not* resign 
In terms of effect in the short term, there is agreement that, given that we
just had 3 resignations, the constitutional change would only apply from
2016-01-01, not 2015-01-01.


There are three different variants that consider resignations/removals:

"2-R": <[🔎] 20141119091345.GA9825@xanadu.blop.info>, formalized in
       <[🔎] 20141120204606.GA30491@upsilon.cc>
  expire the 2-R most senior members, with R the number of resignations/removals
  over the last 12 months)

"2-R'": <[🔎] 20141119220621.GA31739@master.debian.org>
  R' is the number of resignations of people who have been on the TC for more
  than 4.5 years

"2-S": <[🔎] 874mttkatj.fsf@desiato.home.uhoreg.ca>
  S is the number of members who have resigned since the last review period,
  and who would have been expired at the current review period if they had
  not resigned.
  A nice formation for that one is: <[🔎] 20141120211711.GB27466@master.debian.org>
     On Jan 1st of each year the term of any Committee member who has served
     more than 42 months (3.5 years) and who is one of the two most senior
     members is set to expire on Dec 31st of that year.


In terms of amount of resulting churn, the options can be ranked as:
  2 > 2-S > 2-R' > 2-R
"max" would result in the same as "2" on average.

(I hope I didn't miss too much)

Lucas

Attachment: signature.asc
Description: Digital signature


Reply to: