Fwd: Maximum term for tech ctte members
On 26 June 2014 08:18, Ian Jackson ijack...@chiark.greenend.org.uk wrote: Anthony Towns writes (Re: Maximum term for tech ctte members): - 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. 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. 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 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... - 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 ... [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
Re: Maximum term for tech ctte members
On 29 June 2014 19:14, Anthony Towns a...@erisian.com.au wrote: On 26 June 2014 08:18, Ian Jackson ijack...@chiark.greenend.org.uk wrote: Anthony Towns writes (Re: Maximum term for tech ctte members): - 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: 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 previous simulation: 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) 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 a...@erisian.com.au -- 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/cajs_lcuxd00xdbyzlo6_-ubeqpv9rqhapams9herezmh3bj...@mail.gmail.com
Re: Maximum term for tech ctte members
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
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: - 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 -- 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/cajs_lcveknrent4r3zjqdkc1wu0_4ufghun6+emj1ose1wd...@mail.gmail.com
Re: Maximum term for tech ctte members
On Tue, May 27, 2014 at 2:18 PM, Ian Jackson wrote: Michael Gilbert writes (Re: Maximum term for tech ctte members): On Sun, May 25, 2014 at 2:22 PM, Russ Allbery wrote: 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 -- 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/CANTw=mnc3brpt2qnu86kopt3+yhq7po1+nncrscnx57f7ae...@mail.gmail.com
Re: Maximum term for tech ctte members
On Mon, May 26, 2014 at 07:58:45PM -0700, Russ Allbery wrote: 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. Possible candidacy rules: - 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. - 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. - 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 -- 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/20140530093749.ga20...@master.debian.org
Re: Maximum term for tech ctte members
Philip Hands writes (Re: Maximum term for tech ctte members): 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. 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. 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. -- 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/21381.53807.561453.367...@chiark.greenend.org.uk
Re: Maximum term for tech ctte members
Michael Gilbert writes (Re: Maximum term for tech ctte members): On Sun, May 25, 2014 at 2:22 PM, Russ Allbery wrote: 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. -- 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/21380.55028.530943.810...@chiark.greenend.org.uk
Re: Maximum term for tech ctte members
Matthias Urlichs writes (Re: Maximum term for tech ctte members): 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. -- 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/21380.55388.739605.17...@chiark.greenend.org.uk
Re: Maximum term for tech ctte members
Russ Allbery writes (Re: Maximum term for tech ctte members): 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. -- 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/21380.55639.798789.609...@chiark.greenend.org.uk
Re: Maximum term for tech ctte members
Ian Jackson ijack...@chiark.greenend.org.uk writes: Russ Allbery writes (Re: Maximum term for tech ctte members): 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. 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. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://ftp.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgprmqL4HgOwG.pgp Description: PGP signature
Re: Maximum term for tech ctte members
On Fri, May 23, 2014 at 9:16 AM, Anthony Towns wrote: 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 -- 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/caktje6fwkfim75ouexnc5sm5r9utdxzn8sowkxwxjcddrld...@mail.gmail.com
Re: Maximum term for tech ctte members
Paul Wise p...@debian.org writes: No-one in the thread seems to be reading Planet Debian, but here is an alternative proposal: 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 (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87sinutygl@windlord.stanford.edu
Re: Maximum term for tech ctte members
On Wed, May 28, 2014 at 10:43 AM, Russ Allbery wrote: Paul Wise writes: No-one in the thread seems to be reading Planet Debian, but here is an alternative proposal: 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 -- 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/caktje6fpvgrnf4qtmsy1yc-n6lhm5hm5vdv3z0f0ro3vnj+...@mail.gmail.com
Re: Maximum term for tech ctte members
Paul Wise p...@debian.org writes: On Wed, May 28, 2014 at 10:43 AM, Russ Allbery wrote: Paul Wise writes: No-one in the thread seems to be reading Planet Debian, but here is an alternative proposal: 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. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87oayishb8@windlord.stanford.edu
Re: Maximum term for tech ctte members
On Mon, May 26, 2014 at 11:02:17AM +1000, Zenaan Harkness wrote: 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 -- 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/20140526102107.ga15...@master.debian.org
Re: Maximum term for tech ctte members
On Sun, May 25, 2014 at 02:09:35PM -0400, Michael Gilbert wrote: 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/msg2.html Wichert Akkerman ~ 5y 2001-04-23 - 2006-01-05 (1.40 - 1.186) https://lists.debian.org/debian-ctte/2005/12/msg0.html Jason Gunthorpe ~ 5y 2001-06-01 - 2006-01-05 (1.42 - 1.186) https://lists.debian.org/debian-ctte/2005/12/msg0.html Dale Scheetz ~ 4y 1998-12-14 - 2002-10-16 (* - 1.84) https://lists.debian.org/debian-ctte/2002/10/msg7.html Anthony Towns ~ 3y 2006-01-05 - 2009-01-06 (1.186 - 1.312) https://lists.debian.org/debian-ctte/2009/01/msg6.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 -- 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/20140526103955.gb15...@master.debian.org
Re: Maximum term for tech ctte members
Hi, Anthony Towns: That's an average of ~6 years, and a median of 5 years You did not consider the current members. 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)? -- -- Matthias Urlichs -- 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/20140526120633.gc12...@smurf.noris.de
Re: Maximum term for tech ctte members
On Sun, May 25, 2014 at 10:37:05AM -0700, Russ Allbery wrote: 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... 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. 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 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:
Re: Maximum term for tech ctte members
On Mon, May 26, 2014 at 09:02:25AM +0200, Matthias Urlichs wrote: 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 -- 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/20140527025244.ga11...@master.debian.org
Re: Maximum term for tech ctte members
Anthony Towns a...@erisian.com.au writes: On Sun, May 25, 2014 at 10:37:05AM -0700, Russ Allbery wrote: 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. Possible candidacy rules: - 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. - 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. - 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. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87ppj0j5ay@windlord.stanford.edu
Re: Maximum term for tech ctte members
On Thu, May 22, 2014 at 9:16 PM, Anthony Towns a...@erisian.com.au wrote: 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 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 -- 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/CACFaiRw8y=p3k_vvbg056pyac3dgfd3srsfdpsyc+1r-qqv...@mail.gmail.com
Re: Maximum term for tech ctte members
On Sat, May 24, 2014 at 11:37:53AM -0700, Russ Allbery wrote: 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... An approach like: 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? 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) 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 -- 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/20140525073157.GA8558@debian
Re: Maximum term for tech ctte members
Anthony Towns a...@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 (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87oaylhi9q@windlord.stanford.edu
Re: Maximum term for tech ctte members
On Sun, May 25, 2014 at 1:37 PM, Russ Allbery wrote: 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 -- 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/CANTw=mo2aezfkriccisjt13cj1s9odnb8q8ryjxw4mxxn0x...@mail.gmail.com
Re: Maximum term for tech ctte members
Michael Gilbert mgilb...@debian.org writes: On Sun, May 25, 2014 at 1:37 PM, Russ Allbery wrote: 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. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87wqd9g1kw@windlord.stanford.edu
Re: Maximum term for tech ctte members
On Sun, May 25, 2014 at 2:22 PM, Russ Allbery wrote: 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 -- 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/CANTw=mnofybvzozunp6o2sdxh2+t0r4bwaeye_90jgaexqh...@mail.gmail.com
Re: Maximum term for tech ctte members
On 5/26/14, Russ Allbery r...@debian.org wrote: Michael Gilbert mgilb...@debian.org writes: On Sun, May 25, 2014 at 1:37 PM, Russ Allbery wrote: 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)? -- 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/caosgnst_u213hfbk+2rm_xad3pghe1cp_1aerv_u_wh4hwi...@mail.gmail.com
Re: Maximum term for tech ctte members
On Thu, May 22, 2014 at 06:40:22PM -0700, Russ Allbery wrote: Anthony Towns a...@erisian.com.au writes: 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. 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. 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 -- 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/20140524071325.ga8...@master.debian.org
Re: Maximum term for tech ctte members
On Sat, May 24, 2014 at 01:07:11AM +0200, Stefano Zacchiroli wrote: On Fri, May 23, 2014 at 06:58:36PM +0200, Tollef Fog Heen wrote: 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 -- 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/20140524072740.gb8...@master.debian.org
Re: Maximum term for tech ctte members
On Sat, May 24, 2014 at 01:07:11AM +0200, Stefano Zacchiroli wrote: - 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 -- 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/20140524073237.gc8...@master.debian.org
Re: Maximum term for tech ctte members
On Sat, May 24, 2014 at 01:07:11AM +0200, Stefano Zacchiroli wrote: - 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. -- taffit when I want something done quickly, I don't wait for others ;) signature.asc Description: Digital signature
Re: Maximum term for tech ctte members
Quoting Francesca Ciceri (2014-05-24 09:30:26) Also: 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 -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Maximum term for tech ctte members
Anthony Towns a...@erisian.com.au writes: On Thu, May 22, 2014 at 06:40:22PM -0700, Russ Allbery wrote: 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. 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. 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) 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. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87wqdbuiny@windlord.stanford.edu
Re: Maximum term for tech ctte members
Hi Anthony, On Freitag, 23. Mai 2014, Anthony Towns wrote: Would anyone else be supportive of a proposal to set a term for tech ctte membership? yes. 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 signature.asc Description: This is a digitally signed message part.
Re: Maximum term for tech ctte members
On Fri, May 23, 2014 at 06:58:36PM +0200, Tollef Fog Heen wrote: ]] 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. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Maximum term for tech ctte members
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/msg4.html [5] https://lists.debian.org/debian-devel-announce/2013/11/msg9.html -- 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/20140523011634.ga25...@master.debian.org
Re: Maximum term for tech ctte members
Anthony Towns a...@erisian.com.au writes: 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. 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. 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. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/878uptb7cp@windlord.stanford.edu
