Re: Alternative proposal: focus on term limits rather than turnover
Hi, On Thu, 20 Nov 2014, Josh Triplett wrote: > > I would suggest introducing a transitional clause that would state > > something like: > > > > As a transitional measure, the terms of all current members that > > exceed 4 years will only expire every 6 months, in order of > > seniority. > > > > This would need some refining, but I hope you get the point. > > Seems reasonable, yes. I think that having the simplest possible > functional expression of term limits seems like a feature, with a > transitional measure *solely* to stage the turnover of the *current* TC > over time (and thus set up for future staged term expiry as well). That > makes more sense to me than baking in a "2 members" or "2-R members" > rule going forward. Well, even if you bootstrap correctly, the TC members are free to resign before their term and you can't ensure that the turnover rate will remain constant. What happens if we have a GR that contradicts a TC decision and that half the TC resigns because they no longer feel empowered to take more decisions? You're back to your initial situation and we will have regular large batches of changes. I think that I prefer a rule where we target a regular turnover of the longest-serving members. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141121075431.gb17...@home.ouaza.com
Re: Alternative proposal: focus on term limits rather than turnover
On Jo, 20 nov 14, 13:23:04, Josh Triplett wrote: > Andrei POPESCU wrote: > > [private reply on purpose, since I'm not a DD] > > [Neither am I; replying publically since your reply was actually public.] Oh, always had the impression you are a DD :) > -8<- > The Constitution is amended as follows: > > --- constitution.txt.orig 2014-11-20 13:14:40.018610438 -0800 > +++ constitution.txt 2014-11-20 13:15:23.714844659 -0800 > @@ -301,6 +301,9 @@ > appointment. > 5. If the Technical Committee and the Project Leader agree they may > remove or replace an existing member of the Technical Committee. > +6. 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. > >6.3. Procedure > > > 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. > -8<- Since I've already messed up with the private/public replies I'll just make one more post and then shut up. IMVHO: 1. hard-coding a date (any date) might provide "interesting" side effects, probably easier to just use the date of the adoption of the GR, with some grace period (e.g. one month), to allow planing for the first expiry. 2. The above reads to me (as a non-native speaker) like it would apply to *all* TC members, not only those with terms longer than imposed by the (amended) Constitution. Slightly more complicated, needs review from a native speaker: As a transitional measure, the terms of any current members of the Technical Committee that exceed the limit above at the time of adoption of this General Resolution shall instead expire every 6 months, starting one month after adoption of this General Resolution, in descending order of seniority. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: [DRAFT] Maximum term for tech ctte members
Anthony Towns writes: > On Thu, Nov 20, 2014 at 07:51:16PM +, Philip Hands wrote: >> Lucas Nussbaum writes: >> > - only resignations from people who would have been expired count in S >> FWIW I think either of those deals with the concerns I raised, as it's >> going to be way too much effort to game that, and I cannot see why >> anyone would want to bother to do so. > > I think: > > 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. > > would work as a description of that approach. Seems like a pretty good > compromise between '2' and '2-R'. > > Also, it makes the arbitrarily chosen constant 42, which is always a > good thing. That's clearly The Answer :-) The fact that people will get a year's notice, means that they can make sure that they leave at a time that minimises disruption, which seems like a very worthwhile idea. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgpB2vbdYTXaf.pgp Description: PGP signature
Re: [DRAFT] Maximum term for tech ctte members
* Anthony Towns , 2014-11-20, 21:17: 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. would work as a description of that approach. Seems like a pretty good compromise between '2' and '2-R'. 10/10, would second. Also, it makes the arbitrarily chosen constant 42, which is always a good thing. Hurrah! -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141120215130.ga9...@jwilk.net
Re: [DRAFT] Maximum term for tech ctte members
On Thu, 20 Nov 2014 21:17:11 +, Anthony Towns said: > On Thu, Nov 20, 2014 at 07:51:16PM +, Philip Hands wrote: >> Lucas Nussbaum writes: > - only resignations from >> people who would have been expired count in S FWIW I think either of >> those deals with the concerns I raised, as it's going to be way too >> much effort to game that, and I cannot see why anyone would want to >> bother to do so. > I think: > 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. > would work as a description of that approach. Seems like a pretty good > compromise between '2' and '2-R'. > Also, it makes the arbitrarily chosen constant 42, which is always a > good thing. Yes, due to the use of the constant 42, this wording is clearly preferable to the wording I proposed in another email. (I think it's a clearer wording too.) -- Hubert Chathi -- Jabber: hub...@uhoreg.ca PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87lhn5imlr@desiato.home.uhoreg.ca
Re: Alternative proposal: focus on term limits rather than turnover
Anthony Towns wrote: > On Thu, Nov 20, 2014 at 11:25:10AM -0800, Josh Triplett wrote: > > This approach seems like it focuses too much on aggregate committee > > turnover, rather than just setting a term limit. > > Term limits rather than turnover was what I proposed originally; the > response to that was that people were concerned about it risking too > much churn. > > https://lists.debian.org/debian-project/2014/05/msg00054.html > https://lists.debian.org/debian-project/2014/05/msg00057.html > https://lists.debian.org/debian-project/2014/05/msg00059.html >From the second mail you linked: > 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? >From the third: > - 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. Distinguishing those two aspects is precisely what I'm trying to do here; the second proposal I sent incorporates a transition measure inspired by Andrei's suggestion, which is effectively the FIFO suggested above. - Josh Triplett -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141120213114.GA7172@jtriplet-mobl1
Re: Alternative proposal: focus on term limits rather than turnover
Andrei POPESCU wrote: > [private reply on purpose, since I'm not a DD] [Neither am I; replying publically since your reply was actually public.] > On Jo, 20 nov 14, 11:25:10, Josh Triplett wrote: > > > > """ > > 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. > > """ > > > > Exact numbers open for bikeshedding, but does the principle seem sound? > > It does to me, but given the current "age" of the TC members[1] the > practical effect would be that the terms of all TC members except Keith > Packard would expire as soon as the GR passes and assuming no member > ever retires the same will happen every 4 years (as per your suggest > numbers). > > [1] https://lists.debian.org/debian-vote/2014/11/msg00199.html (And https://lists.debian.org/debian-project/2014/05/msg00054.html in particular for the specific term lengths.) I'd forgotten that Colin was the only other member with less than a 4 year term (and he's leaving the TC); I'd thought there was one more. > I would suggest introducing a transitional clause that would state > something like: > > As a transitional measure, the terms of all current members that > exceed 4 years will only expire every 6 months, in order of > seniority. > > This would need some refining, but I hope you get the point. Seems reasonable, yes. I think that having the simplest possible functional expression of term limits seems like a feature, with a transitional measure *solely* to stage the turnover of the *current* TC over time (and thus set up for future staged term expiry as well). That makes more sense to me than baking in a "2 members" or "2-R members" rule going forward. Stefano Zacchiroli wrote: > On Thu, Nov 20, 2014 at 11:25:10AM -0800, Josh Triplett wrote: > > That also eliminates any issues of relative seniority, since we > > evaluate each member's term limit in isolation. It also eliminates > > any transitional issues, both because we don't link the expiry to any > > particular calendar date, and because by the time we pass this we'll > > have enough developers on the committee whose terms will *not* > > immediately expire that we won't have to appoint more in a rush. > > I wonder how you could be so sure about that. We just had three people leave the committee, and the TC put out a call for nominations; they plan to start evaluating nominated candidates on December 1st, so it seems fairly likely that we'll have at least three more new members roughly by the end of the year. I'd had the impression there were a couple more members with terms less than 4 years, but even a 4-person committee is enough to function and appoint more members. However, it seems easy enough to add a simple transition mechanism, and in particular (as stated above in reply to Andrei), it seems preferable to have a very simple term limit rule applied to *individual* members orthogonally rather than a rule applied to the committee as a whole. > But even if that is the case, replacing the whole (or mostly of) the > current CTTE with a freshly appointed one at the same time is very > likely to induce the problem that after another full term period (4 > years or whatever else the bikeshed says) from now you'll have another > large wave of batch replacements. Yes, that could happen anyhow, but is > much more likely to happen if you start enforcing a strict term limit > abruptly to all members, instead of doing so gradually. > > So, while your proposal is appealing in the abstract for its simplicity, > it is not really practical (in the current situation) without a > relatively complex transitional measure that make its initial > application gradual. > > > So, the complete diffstat of this proposal is +3-0, rather than +15-1. > > :) > > Yes, but to achieve a similar effect you'll have a much larger diff to > apply to the transitional measure, that you're trying to sweep under the > carpet :-) Not particularly. Incorporating a transitional measure like Andrei's suggestion: -8<- The Constitution is amended as follows: --- constitution.txt.orig 2014-11-20 13:14:40.018610438 -0800 +++ constitution.txt2014-11-20 13:15:23.714844659 -0800 @@ -301,6 +301,9 @@ appointment. 5. If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee. +6. 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. 6.3. Procedure 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. -8<- Three lines of diff to
Re: [DRAFT] Maximum term for tech ctte members
On Thu, Nov 20, 2014 at 07:51:16PM +, Philip Hands wrote: > Lucas Nussbaum writes: > > - only resignations from people who would have been expired count in S > FWIW I think either of those deals with the concerns I raised, as it's > going to be way too much effort to game that, and I cannot see why > anyone would want to bother to do so. I think: 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. would work as a description of that approach. Seems like a pretty good compromise between '2' and '2-R'. Also, it makes the arbitrarily chosen constant 42, which is always a good thing. As far as gaming goes: the only way your resignation forces someone else's term to expire earlier is if you resign at least a year before your term would otherwise have expired; there's no way for less senior members to affect your term expiry, whether you try to annoy them or bribe them. Cheers, aj -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141120211711.gb27...@master.debian.org
Re: [DRAFT] Maximum term for tech ctte members - 2-R model
On Thu, 20 Nov 2014 21:46:06 +0100, Stefano Zacchiroli said: > +++ constitution.2-R.txt 2014-11-20 21:37:17.030425658 +0100 ... > +or 0 (if R >= 2). R is the number of former members of the > +Technical Committee who have resigned, or been removed or > +replaced within the previous 12 months. FWIW, for the proposals where only the senior members are counted towards reducing the expiries, this could be changed to something like: ... R is the number of former members of the Technical Committee who have resigned, or been removed or replaced within the previous 12 months, and who were last appointed to the Technical Committee at least four and a half years (54 months) ago. or ... R is the number of former members of the Technical Committee who have resigned, or been removed or replaced within the previous 12 months, and who were among the two most senior members of the Technical Committee. -- Hubert Chathi -- Jabber: hub...@uhoreg.ca PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ppchio16@desiato.home.uhoreg.ca
Re: [DRAFT] Maximum term for tech ctte members - 2-R model
On Thu, Nov 20, 2014 at 05:56:47PM +0100, Stefano Zacchiroli wrote: > [ As a more general status update: as it seems that both the "2" and > "2-R" model has significant support, I'm working on integrating "2-R" > in my Git repo as a separate proposal, so that we can easily vote on > both if they both receive enough seconds (or are proposed by the > DPL. More on this in a separate mail. ] FWIW, this is now available at http://git.upsilon.cc/?p=text/gr-ctte-term-limit.git;a=tree I've adapted the text of the "2-R" model to match other wording changes that seemed orthogonal to me to the model, and that have in the meantime been applied to the "2" model. I attach to this mail the 2 GR text proposals, as well as the diff between them, which is (as expected) restricted to how the amount of expiries are calculated. I do not plan to propose or second this as an amendment myself, but having it ready might help others doing so. So if you care about it, please have a look. 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 » The Constitution is amended as follows: --- --- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100 +++ constitution.2-R.txt2014-11-20 21:37:17.030425658 +0100 @@ -299,8 +299,25 @@ Project Leader may appoint new member(s) until the number of members reaches 6, at intervals of at least one week per appointment. -5. If the Technical Committee and the Project Leader agree they may +5. A Developer is not eligible to be (re)appointed to the Technical + Committee if they have been a member within the previous 12 months. +6. If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee. +7. Term limit: + 1. Membership of the Technical Committee is automatically +reviewed on the 1st of January of each year. At this time, the +terms of members who were appointed at least four and a half +years (54 months) ago automatically expire. Expiry occurs in +order of seniority, most senior members first, and is limited +to at most N members per year. N is defined as 2-R (if R < 2) +or 0 (if R >= 2). R is the number of former members of the +Technical Committee who have resigned, or been removed or +replaced within the previous 12 months. + 2. A member of the Technical Committee is said to be more senior +than another if they were appointed earlier, or were appointed +at the same time and have been a member of the Debian Project +longer. In the event that a member has been appointed more +than once, only the most recent appointment is relevant. 6.3. Procedure --- As a transitional measure, the first automatic review of membership of the Technical Committee will happen 1 month after this GR is passed. The Constitution is amended as follows: --- --- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100 +++ constitution.2.txt 2014-11-20 21:09:26.394934866 +0100 @@ -299,8 +299,22 @@ Project Leader may appoint new member(s) until the number of members reaches 6, at intervals of at least one week per appointment. -5. If the Technical Committee and the Project Leader agree they may +5. A Developer is not eligible to be (re)appointed to the Technical + Committee if they have been a member within the previous 12 months. +6. If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee. +7. Term limit: + 1. Membership of the Technical Committee is automatically +reviewed on the 1st of January of each year. At this time, the +terms of members who were appointed at least four and a half +years (54 months) ago automatically expire. Expiry occurs in +order of seniority, most senior members first, and is limited +to at most 2 members per year. + 2. A member of the Technical Committee is said to be more senior +than another if they were appointed earlier, or were appointed +at the same time and have been a member of the Debian Project +longer. In the event that a member has been appointed more +than once, only the most recent appointment is relevant. 6.3. Procedure -
Re: Alternative proposal: focus on term limits rather than turnover
On Thu, Nov 20, 2014 at 11:25:10AM -0800, Josh Triplett wrote: > This approach seems like it focuses too much on aggregate committee > turnover, rather than just setting a term limit. Term limits rather than turnover was what I proposed originally; the response to that was that people were concerned about it risking too much churn. https://lists.debian.org/debian-project/2014/05/msg00054.html https://lists.debian.org/debian-project/2014/05/msg00057.html https://lists.debian.org/debian-project/2014/05/msg00059.html Cheers, aj -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141120204551.ga27...@master.debian.org
Re: Alternative proposal: focus on term limits rather than turnover
On Thu, 20 Nov 2014 21:45:11 +0200, Andrei POPESCU said: > On Jo, 20 nov 14, 21:43:03, Andrei POPESCU wrote: >> [private reply on purpose, since I'm not a DD] > Which I did not, sorry... I think you'll find that constructive messages (as yours was) are generally welcome on this list, whether it comes from a DD or a non-DD. -- Hubert Chathi -- Jabber: hub...@uhoreg.ca PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87tx1tiqce@desiato.home.uhoreg.ca
Re: [DRAFT] Maximum term for tech ctte members
> "Stefano" == Stefano Zacchiroli writes: Stefano> On Thu, Nov 20, 2014 at 12:33:28PM +, Sam Hartman wrote: >> While I do think that 4-5 years is a good term length, I do think >> a lot of churn can be bad, and 2-r makes a lot of sense to me for >> the reason you give above. Stefano> Not sure if you've read it Sam, but just in case: I find Stefano> Phil's example in <871toz16nz@hands.com> to be most Stefano> convincing against the 2-R model in general. If, OTOH, your Stefano> objective is avoid churn in the *short* term, then dropping Stefano> the transitional measure as mentioned by Scott and Lucas Stefano> would be more than enough. (And, in fact, we can even have Stefano> intermediate solutions like bumping the transitional Stefano> measure from 1 months to 6.) My concern is long-term churn. I don't find that message compelling and would definitely second an amendment with 2-r. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/0149cec89e49-54cb5205-435d-4755-8411-c0d960173cb0-000...@email.amazonses.com
Re: [DRAFT] Maximum term for tech ctte members
Lucas Nussbaum writes: > On 20/11/14 at 13:04 -0500, Hubert Chathi wrote: >> On Thu, 20 Nov 2014 17:59:31 +0100, Stefano Zacchiroli >> said: >> >> > On Thu, Nov 20, 2014 at 12:33:28PM +, Sam Hartman wrote: >> >> While I do think that 4-5 years is a good term length, I do think a >> >> lot of churn can be bad, and 2-r makes a lot of sense to me for the >> >> reason you give above. >> >> > Not sure if you've read it Sam, but just in case: I find Phil's >> > example in <871toz16nz@hands.com> to be most convincing against >> > the 2-R model in general. ... >> >> I think someone had already mentioned this option, but one way to avoid >> the effects of that issue, for those who want to avoid always expiring 2 >> members, is to expire 2-S members, where 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. So the >> resignation of a junior member would not affect the expiry process, but >> the resignation of a senior member would mean that we would have one >> less expiry. > > It was proposed by Anthony in <20141119220621.ga31...@master.debian.org>: > >> However, another option would be "2-R'" where only retirements of people >> who would otherwise be candidates for expiry count. So Russ quitting >> after serving 5.8 years would count, but Colin resigning after serving >> "just" 3.2 years wouldn't. That doesn't seem like it's especially easy >> to specify either though. > > Note that there are two subtle variants: > - only resignations from people > 4.5y count in R' (Anthony's) > - only resignations from people who would have been expired count in S > (yours) FWIW I think either of those deals with the concerns I raised, as it's going to be way too much effort to game that, and I cannot see why anyone would want to bother to do so. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgpj0TgR54iJJ.pgp Description: PGP signature
Re: Alternative proposal: focus on term limits rather than turnover
On Thu, Nov 20, 2014 at 11:25:10AM -0800, Josh Triplett wrote: > That also eliminates any issues of relative seniority, since we > evaluate each member's term limit in isolation. It also eliminates > any transitional issues, both because we don't link the expiry to any > particular calendar date, and because by the time we pass this we'll > have enough developers on the committee whose terms will *not* > immediately expire that we won't have to appoint more in a rush. I wonder how you could be so sure about that. But even if that is the case, replacing the whole (or mostly of) the current CTTE with a freshly appointed one at the same time is very likely to induce the problem that after another full term period (4 years or whatever else the bikeshed says) from now you'll have another large wave of batch replacements. Yes, that could happen anyhow, but is much more likely to happen if you start enforcing a strict term limit abruptly to all members, instead of doing so gradually. So, while your proposal is appealing in the abstract for its simplicity, it is not really practical (in the current situation) without a relatively complex transitional measure that make its initial application gradual. > So, the complete diffstat of this proposal is +3-0, rather than +15-1. > :) Yes, but to achieve a similar effect you'll have a much larger diff to apply to the transitional measure, that you're trying to sweep under the carpet :-) 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
Re: Alternative proposal: focus on term limits rather than turnover
On Jo, 20 nov 14, 21:43:03, Andrei POPESCU wrote: > [private reply on purpose, since I'm not a DD] Which I did not, sorry... Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Alternative proposal: focus on term limits rather than turnover
[private reply on purpose, since I'm not a DD] On Jo, 20 nov 14, 11:25:10, Josh Triplett wrote: > > """ > 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. > """ > > Exact numbers open for bikeshedding, but does the principle seem sound? It does to me, but given the current "age" of the TC members[1] the practical effect would be that the terms of all TC members except Keith Packard would expire as soon as the GR passes and assuming no member ever retires the same will happen every 4 years (as per your suggest numbers). [1] https://lists.debian.org/debian-vote/2014/11/msg00199.html I would suggest introducing a transitional clause that would state something like: As a transitional measure, the terms of all current members that exceed 4 years will only expire every 6 months, in order of seniority. This would need some refining, but I hope you get the point. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Alternative proposal: focus on term limits rather than turnover
Stefano Zacchiroli wrote: > -5. If the Technical Committee and the Project Leader agree they may > +5. A Developer is not eligible to be (re)appointed to the Technical > + Committee if they have been a member within the previous 12 months. > +6. If the Technical Committee and the Project Leader agree they may > remove or replace an existing member of the Technical Committee. > +7. Term limit: > + 1. Membership of the Technical Committee is automatically > +reviewed on the 1st of January of each year. At this time, the > +terms of members who were appointed at least four and a half > +years (54 months) ago automatically expire. Expiry occurs in > +order of seniority, most senior members first, and is limited > +to at most 2 members per year. > + 2. A member of the Technical Committee is said to be more senior > +than another if they were appointed earlier, or were appointed > +at the same time and have been a member of the Debian Project > +longer. In the event that a member has been appointed more > +than once, only the most recent appointment is relevant. This approach seems like it focuses too much on aggregate committee turnover, rather than just setting a term limit. In particular, I don't see any obvious reason to limit expiry to 2 members per year (given that we have a process for appointing new members, and that we're about to do so), or to tie expiry to the calendar year (rather than the member's appointment), and I think the break before re-election could be incorporated into the term limit. What about something like this: """ 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. """ Exact numbers open for bikeshedding, but does the principle seem sound? We can leave it implicit that a developer whose term would immediately expire is not eligible for appointment, since doing so would be pointless. We don't need rules allowing a developer to stay on the committee despite their term expiring; we can easily predict such dates and plan on appointing new members by that time, just as we do for DPLs. That also eliminates any issues of relative seniority, since we evaluate each member's term limit in isolation. It also eliminates any transitional issues, both because we don't link the expiry to any particular calendar date, and because by the time we pass this we'll have enough developers on the committee whose terms will *not* immediately expire that we won't have to appoint more in a rush. So, the complete diffstat of this proposal is +3-0, rather than +15-1. :) - Josh Triplett -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141120192253.GA6120@jtriplet-mobl1
Re: [DRAFT] Maximum term for tech ctte members
On 20/11/14 at 13:04 -0500, Hubert Chathi wrote: > On Thu, 20 Nov 2014 17:59:31 +0100, Stefano Zacchiroli said: > > > On Thu, Nov 20, 2014 at 12:33:28PM +, Sam Hartman wrote: > >> While I do think that 4-5 years is a good term length, I do think a > >> lot of churn can be bad, and 2-r makes a lot of sense to me for the > >> reason you give above. > > > Not sure if you've read it Sam, but just in case: I find Phil's > > example in <871toz16nz@hands.com> to be most convincing against > > the 2-R model in general. ... > > I think someone had already mentioned this option, but one way to avoid > the effects of that issue, for those who want to avoid always expiring 2 > members, is to expire 2-S members, where 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. So the > resignation of a junior member would not affect the expiry process, but > the resignation of a senior member would mean that we would have one > less expiry. It was proposed by Anthony in <20141119220621.ga31...@master.debian.org>: > However, another option would be "2-R'" where only retirements of people > who would otherwise be candidates for expiry count. So Russ quitting > after serving 5.8 years would count, but Colin resigning after serving > "just" 3.2 years wouldn't. That doesn't seem like it's especially easy > to specify either though. Note that there are two subtle variants: - only resignations from people > 4.5y count in R' (Anthony's) - only resignations from people who would have been expired count in S (yours) Lucas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141120191022.ga19...@xanadu.blop.info
Re: [DRAFT] Maximum term for tech ctte members
Hi Phil, On 19/11/14 at 16:44 +, Philip Hands wrote: > Stefano Zacchiroli writes: > > ... > >> The '2-R' schema could even result in an internal TC discussion: "OK, > >> the Project wants us to change two members. Are there people that feel > >> like resigning now? Or should we just fallback to the default of expiring > >> the two most senior members?" > >> I think that if this happened, it would be very healthy for the TC. > > > > I agree that this would most certainly happen. But my judgement on it is > > that it would be a *bad* thing, not a good one. In fact, I would see > > that as a tactical behavior on the part of the CTTE to work around an > > agreed upon judgement on the fact that turn-over is good, and that > > remaining in charge too long is bad. > > Quite. > > This reminds me of a rule that for the EU's framework programs, where > they must make sure that (IIRC) 30% new blood is brought into the review > process every year to try to avoid cronyism. > > That sounds like a decent rule, in that it seems to imply that one > replaces the reviewers every 4 years or so, but that's not what actually > happens for various reasons. > > The actual outcome is that the same 60+% tend to do reviews year after > year, with the 30% each year mostly replacing the 30% from the year > before. > > Of course, with the TC it doesn't matter as much, because the TC is not > allocating millions of Euros of funding. I struggle to understand if this is a point against the '2-R' rule, or a general comment about the possible risk that the TC might decide to just re-appoint members expired at year n-1. I don't see what '2-R' changes compared to '2' about that. > Even so, if someone wanted to stay in post on the TC for whatever > reason, this '2-R' rule would just encourage them to be difficult to > work with in the hope that a couple of less senior members became fed up > enough to leave early. > > It doesn't seem wise to have such an incentive to behave badly. I'm unconvinced that this is an actual problem. Being difficult to work with is one thing; but being difficult to work with in the hope that it will cause other members to resign so that one can stay one more year on the Debian TC seems quite a stretch. Lucas signature.asc Description: Digital signature
Re: [DRAFT] Maximum term for tech ctte members
On Thu, 20 Nov 2014 17:59:31 +0100, Stefano Zacchiroli said: > On Thu, Nov 20, 2014 at 12:33:28PM +, Sam Hartman wrote: >> While I do think that 4-5 years is a good term length, I do think a >> lot of churn can be bad, and 2-r makes a lot of sense to me for the >> reason you give above. > Not sure if you've read it Sam, but just in case: I find Phil's > example in <871toz16nz@hands.com> to be most convincing against > the 2-R model in general. ... I think someone had already mentioned this option, but one way to avoid the effects of that issue, for those who want to avoid always expiring 2 members, is to expire 2-S members, where 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. So the resignation of a junior member would not affect the expiry process, but the resignation of a senior member would mean that we would have one less expiry. -- Hubert Chathi -- Jabber: hub...@uhoreg.ca PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/874mttkatj@desiato.home.uhoreg.ca
Re: Not being very involved in the term limits proposal
On 2014-11-20, Sam Hartman wrote: > I'm also considering whether I want to throw my name in the hat to be > considered as a TC member. I'd love to throw your name in that hat. /Sune -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m4labd$tn2$1...@ger.gmane.org
Re: [DRAFT] Maximum term for tech ctte members
On Thu, Nov 20, 2014 at 08:20:44AM -0500, Scott Kitterman wrote: > Given that we've just had significant turnover in th TC, might it not make > sense to have the first term expirations set for a year or two from now? > That > would keep this discussion well separated from any current turmoil and I > think > it's reasonably clear that we don't, at the moment, suffer from a lack of > turnover in the TC (which AIUI is the motivation for this). I was reluctant to propose this myself, but I do agree with you. The *preexisting* problem of basically 0 turnover in the ctte is basically solved and AFAICT for reasons completely independent from the ongoing work on this GR. What still needs to be put in place is some rule that avoid the problem reappears in the future. So I would personally be in favor of dropping entirely the transitional measureFWIW Lucas (original proposer of the measure) has also hinted at that possibility in <20141119210924.ga28...@xanadu.blop.info>. I do not understand the reason why AJ in <20141119220621.ga31...@master.debian.org> stated that he would favor either of the "2" and "2-R" model over "2 without transitional measure". So I might be missing something. I welcome comments on whether people would be against having the "2" model without the transitional measure, as suggested by Scott (and Lucas). It certainly is an option that scores very well on the Occam's Razor scale. I will note down this in TODO. Cheers. [ As a more general status update: as it seems that both the "2" and "2-R" model has significant support, I'm working on integrating "2-R" in my Git repo as a separate proposal, so that we can easily vote on both if they both receive enough seconds (or are proposed by the DPL. More on this in a separate mail. ] -- 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
Re: [DRAFT] Maximum term for tech ctte members
On Thu, Nov 20, 2014 at 12:33:28PM +, Sam Hartman wrote: > While I do think that 4-5 years is a good term length, I do think a > lot of churn can be bad, and 2-r makes a lot of sense to me for the > reason you give above. Not sure if you've read it Sam, but just in case: I find Phil's example in <871toz16nz@hands.com> to be most convincing against the 2-R model in general. If, OTOH, your objective is avoid churn in the *short* term, then dropping the transitional measure as mentioned by Scott and Lucas would be more than enough. (And, in fact, we can even have intermediate solutions like bumping the transitional measure from 1 months to 6.) 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
Re: [DRAFT] Maximum term for tech ctte members
On Thursday, November 20, 2014 12:33:28 PM Sam Hartman wrote: > > "Lucas" == Lucas Nussbaum writes: > Lucas> (Elaborating on the context a bit given the discussion spread > Lucas> over some time -- two options have been proposed: - expire > Lucas> the 2 most senior members - expire the 2-R most senior > Lucas> members, with R the number of resignations over the last 12 > Lucas> months) > > Lucas> What we want to encourage is, I think, a sane and healthy > Lucas> turnover in the TC. Ideally, this would happen automatically: > Lucas> members would just resign when they feel that bringing fresh > Lucas> manpower is profitable to the TC overall. However, there's a > Lucas> number of social reasons why this doesn't work so well. > Lucas> which might weaken the TC a bit too much. With the '2-R' > Lucas> schema, I have an additional incentive to resign: if I > Lucas> resign, I 'save' someone else more senior than me from > Lucas> getting expired. (And given I'm not so active anymore, > Lucas> instead of weakening the TC further, my resignation might > Lucas> even reinforce the TC). > > > Lucas> The '2-R' schema could even result in an internal TC > Lucas> discussion: "OK, the Project wants us to change two > Lucas> members. Are there people that feel like resigning now? Or > Lucas> should we just fallback to the default of expiring the two > Lucas> most senior members?" I think that if this happened, it > Lucas> would be very healthy for the TC. > > I think such discussions would be good. > > I don't think this conflicts with what I said about term limits earlier > this morning. > While I do think that 4-5 years is a good term length, I do think a lot > of churn can be bad, and 2-r makes a lot of sense to me for the reason > you give above. [responding here because it's the end of the thread right now, not sure where better] Given that we've just had significant turnover in th TC, might it not make sense to have the first term expirations set for a year or two from now? That would keep this discussion well separated from any current turmoil and I think it's reasonably clear that we don't, at the moment, suffer from a lack of turnover in the TC (which AIUI is the motivation for this). Scott K -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1451239.ITZlMzDDEA@kitterman-optiplex-9020m
Re: [DRAFT] Maximum term for tech ctte members
> "Lucas" == Lucas Nussbaum writes: Lucas> (Elaborating on the context a bit given the discussion spread Lucas> over some time -- two options have been proposed: - expire Lucas> the 2 most senior members - expire the 2-R most senior Lucas> members, with R the number of resignations over the last 12 Lucas> months) Lucas> What we want to encourage is, I think, a sane and healthy Lucas> turnover in the TC. Ideally, this would happen automatically: Lucas> members would just resign when they feel that bringing fresh Lucas> manpower is profitable to the TC overall. However, there's a Lucas> number of social reasons why this doesn't work so well. Lucas> which might weaken the TC a bit too much. With the '2-R' Lucas> schema, I have an additional incentive to resign: if I Lucas> resign, I 'save' someone else more senior than me from Lucas> getting expired. (And given I'm not so active anymore, Lucas> instead of weakening the TC further, my resignation might Lucas> even reinforce the TC). Lucas> The '2-R' schema could even result in an internal TC Lucas> discussion: "OK, the Project wants us to change two Lucas> members. Are there people that feel like resigning now? Or Lucas> should we just fallback to the default of expiring the two Lucas> most senior members?" I think that if this happened, it Lucas> would be very healthy for the TC. I think such discussions would be good. I don't think this conflicts with what I said about term limits earlier this morning. While I do think that 4-5 years is a good term length, I do think a lot of churn can be bad, and 2-r makes a lot of sense to me for the reason you give above. --Sam -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/0149cd3169e7-839865c5-ba1e-47ff-8a16-d3ccc169496f-000...@email.amazonses.com
Not being very involved in the term limits proposal
Hi folks. A few weeks ago I indicated strong interest in helping drive the term limits proposal. I no longer feel comfortable doing that, and also have found something else that is taking up my Debian energy. As a result of that message and some other discussions I gained a much better understanding of how a lot of people I care about in the project were hurting. I've tried to lend my support to helping with that and to thinking about how we might be able to work together in the future. I care more about that work than the term limits proposal. Also, I see areas where being a strong advocate for the term limits proposal might conflict with other work I'm doing. I can see some situations where it might make my compassion and respect work harder. I'm also considering whether I want to throw my name in the hat to be considered as a TC member. I think that getting heavily involved in the term limits discussion might be an entanglement if I decide to do that. So, I'm going to respectfully step away from my commitment to be involved in that process. I'll offer a couple of suggestions like I did in my most recent message. I will also likely second a proposal because I do believe this is an important issue. --Sam -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/0149cce58436-fa347208-e49c-407c-82e9-dd0c3ac3198e-000...@email.amazonses.com
Re: [DRAFT #2] Maximum term for tech ctte members
Watching other volunteer organizations, I've found that having turnover somewhere between 3-5 years tends to work fairly well. I've seen this in student organizations where the turnover tends to be somewhat encouraged by graduation although in the cases I'm thinking of that did not force the issue. By 3 years someone is very good at what they do. However, they start to burn out and start to not notice or take advantage of good ideas. The burn out is becoming a significant issue by 5 years. I've seen the same thing in the IETF. There, two years is really just enough to learn some of the leadership roles and to get into the stride of things. Those roles are fairly intense. Four years tends to work quite well, but by 6 years (two year terms), people really do tend to be burned out. Even the best people are showing significant signs of being jaded and abrupt. They don't pursue things with the dedication they used to, they don't dedicate as much time to working with folks to understand all sides, consensus decisions seem to be more forced. Keep in mind that TC members can seek wizdom and institutional memory from outside the TC. There's nothing stopping a TC member next year from writing to Russ, Ian, collin, or even older TC members to get advice. The point should be to have people with good technical judgment and current willingness to come up with solutions that make the project stronger. That doesn't require a huge memory of being on the TC. --Sam -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/0149ccdf9746-1d35b433-b0a5-4589-9623-6de0a0a06bac-000...@email.amazonses.com
Re: [DRAFT #2] Maximum term for tech ctte members
On 20/11/14 at 08:21 +, Anthony Towns wrote: > On Thu, Nov 20, 2014 at 08:01:54AM +0100, Lucas Nussbaum wrote: > > > > I don't think that the TC is a stress-full role. Obviously the recent > > > > past > > > > proved how the role can be incredibly stressful at times. But there has > > > > also been long periods without much activity, [...] > > FWIW, I agree with Steve here. The nature of the tech ctte is that it > only does things when there's some sort of significant enough problem > that can't be dealt with by other means, and that's pretty much always > going to be stressful. If the problem's not significant, no one cares > enough to take it to the ctte; if it's easy, it just gets dealt with. If > it's hard and important, dealing with it will be stressful... > > That said, the breaks without activity make it easier, certainly -- > I can't imagine someone lasting as DPL or release manager for 16 or 13 > or 9 years, for instance. I think that this is a (quite useless) discussion about the exact meaning of 'stress-full'. To be clear, I fully agree that the stress level of TC members has probably been super-high for the last 3 years or so. But I hope that this is just an anomaly, and that at some point it will return to being super-high only from time to time (when there are decisions to make), so that on average it isn't such a stress-full role. Lucas signature.asc Description: Digital signature
Re: [DRAFT #2] Maximum term for tech ctte members
On Thu, Nov 20, 2014 at 08:01:54AM +0100, Lucas Nussbaum wrote: > > > I don't think that the TC is a stress-full role. Obviously the recent past > > > proved how the role can be incredibly stressful at times. But there has > > > also been long periods without much activity, [...] FWIW, I agree with Steve here. The nature of the tech ctte is that it only does things when there's some sort of significant enough problem that can't be dealt with by other means, and that's pretty much always going to be stressful. If the problem's not significant, no one cares enough to take it to the ctte; if it's easy, it just gets dealt with. If it's hard and important, dealing with it will be stressful... That said, the breaks without activity make it easier, certainly -- I can't imagine someone lasting as DPL or release manager for 16 or 13 or 9 years, for instance. Cheers, aj -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141120082146.ga21...@master.debian.org
