Anthony Towns writes ("Re: Maximum term for tech ctte members"): > On 30 May 2014 19:37, Anthony Towns <a...@erisian.com.au> wrote: > > 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:
This is a good general approach but I would quibble with a couple of the details: > - 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. > 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. 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). > [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. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21419.19134.64225.764...@chiark.greenend.org.uk