Re: [DRAFT] Maximum term for tech ctte members
Stefano Zacchiroli writes: > On Sun, Nov 23, 2014 at 09:00:11PM +, Philip Hands wrote: >> Stefano Zacchiroli writes: >> > If people really want to add a tie breaking rule, >> >> I was mostly trying to get rid of the need for one. >> >> How about just saying that appointments must be done one at a time? > > You mean informally as a custom? Yeah, that sounds good enough to me, > it's easy for the DPL to do so --- or to mention in the appointment > email that the order is significant, or answer publicly to nitpickers > who will call them out for having forgot to do so :-) Sounds fine to me. 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 pgpdRtSQoeIKZ.pgp Description: PGP signature
Re: [DRAFT] Maximum term for tech ctte members
On Sun, Nov 23, 2014 at 02:43:46PM +0100, Stefano Zacchiroli wrote: > On Sat, Nov 22, 2014 at 03:46:49PM +, Philip Hands wrote: > > > I think since this is a tie-breaker situation which will presumably > > > rarely happen, it doesn't really matter much. > > > > How about: > > I don't think this is a problem that is worth solving with extra > complexity in the text of the Constitution. > > If a tie ever happens, I think we can count on the responsibility of the > involved CTTE members to agree between them on who should step down; and > possibly on the fact that they will all resign. I would hope that to be possible, too, yes, but I wouldn't gamble the stability of one of our most core institutions on having to change the constitution to fix an issue when people are fighting over it on the street... > But I bite. I don't think it is a good idea to tie the tie breaking rule > to specific technology (the email message used for the appointment, IDs > in the Debian user database, etc). > > If people really want to add a tie breaking rule, the most > straightforward one is specifying that *the DPL* will break any tie. That's probably the best option. It would also seriously reduce the amount of extra complexity for a tie breaking rule. I would feel more comfortable if it were explicitly mentioned, though. If a problem ever occurred due to this, technically the DPL could claim "urgent action" and do it under 5.1.3, but I would find that reasoning strained. After all, the constitution gives the DPL the power to *assign* someone to the committee, but not to remove someone; that is far from the same thing. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 -- 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/20141124085041.ga29...@grep.be
Re: [DRAFT] Maximum term for tech ctte members
On Sun, Nov 23, 2014 at 09:00:11PM +, Philip Hands wrote: > Stefano Zacchiroli writes: > > If people really want to add a tie breaking rule, > > I was mostly trying to get rid of the need for one. > > How about just saying that appointments must be done one at a time? You mean informally as a custom? Yeah, that sounds good enough to me, it's easy for the DPL to do so --- or to mention in the appointment email that the order is significant, or answer publicly to nitpickers who will call them out for having forgot to do so :-) If instead you meant changing the GR to also change the CTTE appointment section, I'm not particularly thrilled at that idea. 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
Stefano Zacchiroli writes: > If people really want to add a tie breaking rule, I was mostly trying to get rid of the need for one. How about just saying that appointments must be done one at a time? 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 pgpaa49E1gulR.pgp Description: PGP signature
Re: [DRAFT] Maximum term for tech ctte members
On Sat, Nov 22, 2014 at 03:46:49PM +, Philip Hands wrote: > > I think since this is a tie-breaker situation which will presumably > > rarely happen, it doesn't really matter much. > > How about: I don't think this is a problem that is worth solving with extra complexity in the text of the Constitution. If a tie ever happens, I think we can count on the responsibility of the involved CTTE members to agree between them on who should step down; and possibly on the fact that they will all resign. But I bite. I don't think it is a good idea to tie the tie breaking rule to specific technology (the email message used for the appointment, IDs in the Debian user database, etc). If people really want to add a tie breaking rule, the most straightforward one is specifying that *the DPL* will break any tie. That would allow to further simplify the text, as we could then drop the rule about "most senior project membership", and only keep CTTE seniority. As the DPL is de facto empowered to break ties in advance (by appointing one member after the other instead of simultaneously) this change won't add any loophole. (The only quirk is that the DPL who will break ties is most likely not the same who did the appointments. But the Constitution should treat the DPL as an institution, not as a specific person, so I don't really see a problem with this difference.) 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 Sat, Nov 22, 2014 at 03:46:49PM +, Philip Hands wrote: > Philip Hands writes: > > > Wouter Verhelst writes: > > > >> On Tue, Nov 18, 2014 at 11:33:10AM +0100, Stefano Zacchiroli wrote: > >> [...] > >>> 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. > >> > >> I think it makes more sense to have someone who was previously a member > >> of the TC have more seniority, before "age" within the project: > > > > I think since this is a tie-breaker situation which will presumably > > rarely happen, it doesn't really matter much. > > How about: > >For the purpose of determining seniority, simultaneous appointments >are deemed to have taken place in the order of names in the mail that >announced their appointment. > > The TC can then decide how they're going to do the ordering at > appointment time, and that's then clear to all -- no need to come up > with lots of words that might still not give a distinct result. That would work too, I suppose. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 -- 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/20141123120453.ga24...@grep.be
Re: [DRAFT] Maximum term for tech ctte members
Philip Hands writes: > Wouter Verhelst writes: > >> On Tue, Nov 18, 2014 at 11:33:10AM +0100, Stefano Zacchiroli wrote: >> [...] >>> 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. >> >> I think it makes more sense to have someone who was previously a member >> of the TC have more seniority, before "age" within the project: > > I think since this is a tie-breaker situation which will presumably > rarely happen, it doesn't really matter much. How about: For the purpose of determining seniority, simultaneous appointments are deemed to have taken place in the order of names in the mail that announced their appointment. The TC can then decide how they're going to do the ordering at appointment time, and that's then clear to all -- no need to come up with lots of words that might still not give a distinct result. 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 pgpHVbmULUPTx.pgp Description: PGP signature
Re: [DRAFT] Maximum term for tech ctte members
Wouter Verhelst writes: > On Tue, Nov 18, 2014 at 11:33:10AM +0100, Stefano Zacchiroli wrote: > [...] >> 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. > > I think it makes more sense to have someone who was previously a member > of the TC have more seniority, before "age" within the project: I think since this is a tie-breaker situation which will presumably rarely happen, it doesn't really matter much. I was tempted to suggest that we deal with it by doing something like combine the appointment date and debian username, checksum that and sort by the result, but actually why don't we just avoid the problem completely by saying that we don't do simultaneous appointments? If we have multiple appointments on the same day, we can select at that moment who is going to be considered the earlier appointment, and appoint them a minute earlier, or some such. That decision can be made on any basis that the people in the TC feel reasonable at the time. The timestamps of the emails where the candidates declare that they're willing to be appointed would be a reasonable default. 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 pgpOHrCyUU85E.pgp Description: PGP signature
Re: [DRAFT] Maximum term for tech ctte members
On Sat, Nov 22, 2014 at 10:34:25AM +0100, Stefano Zacchiroli wrote: > On Sat, Nov 22, 2014 at 09:51:44AM +0100, Wouter Verhelst wrote: > > On Tue, Nov 18, 2014 at 11:33:10AM +0100, Stefano Zacchiroli wrote: > > > 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. > > > > I think it makes more sense to have someone who was previously a > > member of the TC have more seniority, before "age" within the project: > > > > A member of the Technical Committee is said to be more senior than > > another if they were appointed earlier. In the case where two members > > of the Committee were appointed at the same time, then total time > > served on the Committee (including previous appointments in the event > > of a member being appointed more than once) and membership time in the > > Debian Project as a whole will be considered, in that order. > > Considering the likelihood of a situation in which the two alternative > approach lead to different results, is it worth an increase from 60 > words to 77 (including a parenthetical)? I'm not so sure this is very unlikely. First of all, the DAM tends to approve NM applications in batch; sometimes in a large batch. As a result, most people in the Project are a member of Debian for the same amount of time, to the day. Due to the birthday paradox and the higher rate of rotation of people serving on the TC as a result of this change, a situation where two people are in Debian for the same amount of time ar both concurrently serving on the TC is likely to occur at some point. Second, a proposal to review two TC members at the same time will make it likely that the replacement members are appointed at the same time, too. If an odd number of people then resigns from the TC, you will at some point have the situation where the least senior of the two "most senior" people shares an appointment date with someone else. If the originally-resigning people did not serve on the TC for very long prior to their resignation, this situation may persist for a few years, increasing the likelihood of the next item on the list of "things considered to determine seniority" comes into play. If the goal of this proposal is to increase the amount of fresh ideas in the TC, then the difference between "A person having been in Debian for 15 years of which 8 as a member of the TC" and "A person having been in Debian for 15 years of which 4 as a member of the TC" should be in favour of the latter. I do agree that the wording is suboptimal and could use some improvement, though. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 -- 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/20141122121935.gi8...@grep.be
Re: [DRAFT] Maximum term for tech ctte members
On Sat, Nov 22, 2014 at 09:51:44AM +0100, Wouter Verhelst wrote: > On Tue, Nov 18, 2014 at 11:33:10AM +0100, Stefano Zacchiroli wrote: > > 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. > > I think it makes more sense to have someone who was previously a > member of the TC have more seniority, before "age" within the project: > > A member of the Technical Committee is said to be more senior than > another if they were appointed earlier. In the case where two members > of the Committee were appointed at the same time, then total time > served on the Committee (including previous appointments in the event > of a member being appointed more than once) and membership time in the > Debian Project as a whole will be considered, in that order. Considering the likelihood of a situation in which the two alternative approach lead to different results, is it worth an increase from 60 words to 77 (including a parenthetical)? -- 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: Re: [DRAFT] Maximum term for tech ctte members
On Tue, Nov 18, 2014 at 02:44:42PM +0100, Svante Signell wrote: > Hi, > > > 6.2. Composition > > > > 1. The Technical Committee consists of up to 8 Developers, and should > >usually have at least 4 members. > > 2. When there are fewer than 8 members the Technical Committee may > >recommend new member(s) to the Project Leader, who may choose > >(individually) to appoint them or not. > > 3. When there are 5 members or fewer the Technical Committee may > >appoint new member(s) until the number of members reaches 6. > > 4. When there have been 5 members or fewer for at least one week the > >Project Leader may appoint new member(s) until the number of > >members reaches 6, at intervals of at least one week per > >appointment. > > Why not avoid the casting vote problem by stipulating that the number > of members should always be an odd number. The problem with that is that if an odd number of members recuse themselves because they feel that they are involved somehow and wouldn't be able to vote fairly, you again have an even number. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 -- 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/20141122085431.gc8...@grep.be
Re: [DRAFT] Maximum term for tech ctte members
On Tue, Nov 18, 2014 at 11:33:10AM +0100, Stefano Zacchiroli wrote: [...] > 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. I think it makes more sense to have someone who was previously a member of the TC have more seniority, before "age" within the project: "A member of the Technical Committee is said to be more senior than another if they were appointed earlier. In the case where two members of the Committee were appointed at the same time, then total time served on the Committee (including previous appointments in the event of a member being appointed more than once) and membership time in the Debian Project as a whole will be considered, in that order." Other than that, looks good. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 -- 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/20141122085144.gb8...@grep.be
Re: [DRAFT] Maximum term for tech ctte members
On Fri, 21 Nov 2014 12:12:13 +, Sam Hartman said: [...] > 3) 2-s I think would expire 1 person, because Ian was in s, right? > 4) Anthony's new proposal would schedule the two most senior folks to > expire at end of 2015, right? So you'd have up to 5 experienced folks > through most of 2015. As the person who suggested 2-S, I think that Anthony's proposal has the same practical effect after the upcoming year, and preferred Anthony's wording. So I think of them as being essentially the same, and I wouldn't want both on the ballot. Of course for the purposes of your comparison, they are different, but we can treat them the same if we pretend that Anthony's proposal has a transitional measure clause that said that the two most senior members of the TC as of 2014-01-01 had their memberships set to expire on 2014-12-31. (I don't have an opinion on whether we should have such a transitional measure clause.) There's also the 2-R' proposal, and for the record, I would prefer not to have both 2-R' and 2-S on the ballot, because I consider them similar enough that I think that having an extra option on the ballot would do more harm than good. On the other hand, I would not oppose having both on the ballot. It's just that if someone formally proposes 2-R' for voting on, I personally would not propose 2-S. -- 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/87y4r4myuh@desiato.home.uhoreg.ca
Re: [DRAFT] Maximum term for tech ctte members
On Fri, Nov 21, 2014 at 12:41:28PM +, Sam Hartman wrote: > Hmm, are you saying that I should dislike option 4 too because if we > had three resignations in the middle of next year we could get into > the same situation unless some of the resignations were from the > senior members? I actually do find that reason compelling as an > argument of 2-r over 2-s. All I wanted to do is to bring your attention the fact that a pending change to 2 would make it behave exactly like 2-S (for the purpose of your mail at least), because you seemed to have not taken that into account. Nothing more, nothing less :) -- 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
> "Stefano" == Stefano Zacchiroli writes: [quoting out of order] >> I also believe that we should not treat the current situation as >> exceptional. This will not be the last time we have a tough >> issue before us that takes up a lot of emotional energy. It is >> strongly in the interest of TC members and the project for us to >> encourage people to find something that makes them happy when the >> TC no longer does. So, I recommend evaluating these mechanisms >> against future similar situations as an important evaluation >> criteria. Stefano> Agreed. Stefano> On Fri, Nov 21, 2014 at 12:12:13PM +, Sam Hartman wrote: >> For myself I do not like the effects of option 1. [only 3 people on the TC] Stefano> Note that it has been proposed to amend option (1) to Stefano> remove the transitional measure. I have yet to see Stefano> objections to that proposal. Stefano> With that change applied, and limited to the effects you Stefano> discussed in your mail, proposal (1) will behave exactly Stefano> like (4). That's exactly the sort of thinking I was hoping to avoid when I said we need to avoid treating the current situation as exceptional. I dislike any option that would produce bad results if applied in the middle of the current situation. Why? I think the current situation could happen again at any time. Hmm, are you saying that I should dislike option 4 too because if we had three resignations in the middle of next year we could get into the same situation unless some of the resignations were from the senior members? I actually do find that reason compelling as an argument of 2-r over 2-s. --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/0149d25f1970-237fa94e-71b8-4195-98bc-8f99b68f88a6-000...@email.amazonses.com
Re: [DRAFT] Maximum term for tech ctte members
On Fri, Nov 21, 2014 at 12:12:13PM +, Sam Hartman wrote: > 1) 2 would expire two people at Jan 1, 2015, meaning the TC had only 3 > experienced folks on it. [...] > 4) Anthony's new proposal would schedule the two most senior folks to > expire at end of 2015, right? So you'd have up to 5 experienced folks > through most of 2015. > > For myself I do not like the effects of option 1. Note that it has been proposed to amend option (1) to remove the transitional measure. I have yet to see objections to that proposal. With that change applied, and limited to the effects you discussed in your mail, proposal (1) will behave exactly like (4). > I also believe that we should not treat the current situation as > exceptional. This will not be the last time we have a tough issue > before us that takes up a lot of emotional energy. It is strongly in > the interest of TC members and the project for us to encourage people > to find something that makes them happy when the TC no longer does. > So, I recommend evaluating these mechanisms against future similar > situations as an important evaluation criteria. Agreed. 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
So, let's assume we'd adopted this proposal back in July or so. And then things happened as they did, and we got the same three resignations we did. Perhaps we wouldn't have gotten those same three resignations. I actually argue that it is a feature to encourage the people who resigned to do so. All wanted to be gone; you don't want to encourage people to hang on past the time they are ready to go. It's basically always better to get on with the transition reasonably rapidly rather than hanging on another year or so. So, let's assume we did have the same three resignations. How would each of the proposals handle this? 1) 2 would expire two people at Jan 1, 2015, meaning the TC had only 3 experienced folks on it. 2) 2-r would expire no one new because we'd already had enough expirations. 3) 2-s I think would expire 1 person, because Ian was in s, right? 4) Anthony's new proposal would schedule the two most senior folks to expire at end of 2015, right? So you'd have up to 5 experienced folks through most of 2015. For myself I do not like the effects of option 1. I also believe that we should not treat the current situation as exceptional. This will not be the last time we have a tough issue before us that takes up a lot of emotional energy. It is strongly in the interest of TC members and the project for us to encourage people to find something that makes them happy when the TC no longer does. So, I recommend evaluating these mechanisms against future similar situations as an important evaluation criteria. -- 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/0149d2445389-b0e7cfb5-a020-4c0a-a5cc-ee4db3083cf9-000...@email.amazonses.com
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: [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: [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: [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: [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
Re: [DRAFT] Maximum term for tech ctte members
Hi, Anthony Towns: > Technical Committee members are encouraged to serve for a term of > between three and six years. > What, you seriously want to not increase the amount of Legalese in our policy? The shame. :-P > and six years as an upper bound since it gives a bit > more flexibility than five years > Me like. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: [DRAFT] Maximum term for tech ctte members
On Wed, Nov 19, 2014 at 10:09:24PM +0100, Lucas Nussbaum wrote: > I think that the "2-R" behaviour is more desirable, as it avoids 2 years > without replacements in 2017 and 2018. Note that this isn't about the > "2-R" rule as we could have the same behaviour by keeping the "2" rule > and simply dropping the transitional measure (and passing the GR after > 2015-01-01, or having a transitional measure that annihilates the > expiring on 2015-01-01) I think if the "2-R" behaviour is more desirable now, it's worthwhile being a general rule so if we end up in the same situation in future, it's still there. I'm still fairly indifferent between the two options though (I think a committee of just Andi, Don and Keith would actually be fine), personally; so my preference/vote would probably be "[2] == [2-R] > [2 but not until next year]", I guess. 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. What about avoiding all the ifs and buts and math and just giving committee members a goal, and trusting them to figure out how to best to adhere to it (and how to balance it against other goals like retaining institutional memory or whatever)? Technical Committee members are encouraged to serve for a term of between three and six years. If a committee member tried lurking about forever, that would still provide a "we don't hate you, but it's time" justification for the ctte to vote to remove a member, or the project as a whole to do so, which is currently lacking. I've picked three years as a lower bound, since that's how long both Colin and I lasted, and six years as an upper bound since it gives a bit more flexibility than five years and matches about how long Russ lasted. 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/20141119220621.ga31...@master.debian.org
Re: [DRAFT] Maximum term for tech ctte members
On 19/11/14 at 19:21 +, Anthony Towns wrote: > On Wed, Nov 19, 2014 at 11:55:28AM +0100, Stefano Zacchiroli wrote: > > That said, I now am convinced that "2" (without "salvaging" by expiries > > of non-senior members) is a better model than "2-R". I've pondered your > > arguments below, but I don't find them convincing. Specifically, > > Note that with Ian, Russ and Colin's resignation announcements we have a > test case of the difference between these two options: If I got this right... > "2": Russ, Ian resign, either (Bdale, Steve expire; Colin resigns) or > (Colin resigns; Bdale, Steve expire) leaving just Andi, Don and > Keith on the committee, with five spots to fill come January, > and Andi and Don due to expire Jan 1st 2016. 2016-01-01: Andi and Don expire, 2 replacements 2017-01-01: Keith is the oldest member with 3.09y, nobody expires 2018-01-01: Keith is the oldest member with 4.09y, nobody expires 2019-01-01: Keith membership expires, none of the other does 2020-01-01: we have 5 members over the 4.5y limit, two expire 2021-01-01: we have 3+2=5 members over the 4.5y limit, two expire > "2-R": Russ, Ian, Colin resign; nobody expires; Bdale, Steve, Andi, Don, > Keith remain on the committee, with three spots to fill come > January, and Bdale and Steve due to expire Jan 1st 2016. 2016-01-01: Bdale and Steve expire, 2 replacements 2017-01-01: Andi and Don expire, 2 replacements 2018-01-01: Keith is the oldest member with 4.09y, nobody expires 2019-01-01: Keith membership expires, none of the other does 2020-01-01: we have 3 members over the 4.5y limit, two expire 2021-01-01: we have 1+2=3 members over the 4.5y limit, two expire I think that the "2-R" behaviour is more desirable, as it avoids 2 years without replacements in 2017 and 2018. Note that this isn't about the "2-R" rule as we could have the same behaviour by keeping the "2" rule and simply dropping the transitional measure (and passing the GR after 2015-01-01, or having a transitional measure that annihilates the expiring on 2015-01-01) 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/20141119210924.ga28...@xanadu.blop.info
Re: [DRAFT] Maximum term for tech ctte members
On Wed, Nov 19, 2014 at 11:55:28AM +0100, Stefano Zacchiroli wrote: > That said, I now am convinced that "2" (without "salvaging" by expiries > of non-senior members) is a better model than "2-R". I've pondered your > arguments below, but I don't find them convincing. Specifically, Note that with Ian, Russ and Colin's resignation announcements we have a test case of the difference between these two options: "2": Russ, Ian resign, either (Bdale, Steve expire; Colin resigns) or (Colin resigns; Bdale, Steve expire) leaving just Andi, Don and Keith on the committee, with five spots to fill come January, and Andi and Don due to expire Jan 1st 2016. or "2-R": Russ, Ian, Colin resign; nobody expires; Bdale, Steve, Andi, Don, Keith remain on the committee, with three spots to fill come January, and Bdale and Steve due to expire Jan 1st 2016. 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/20141119192115.gb30...@master.debian.org
Re: [DRAFT] Maximum term for tech ctte members
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. 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. 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 pgpZZ4VfOnu2O.pgp Description: PGP signature
Re: [DRAFT] Maximum term for tech ctte members
On Wed, Nov 19, 2014 at 01:20:46PM +0100, Lucas Nussbaum wrote: > This is true only if you use the number of members as the measure for > the "strength" of the TC. But if instead, you consider the sum of the > experience of all members, more turnover due to resignations at a given > point will have a greater impact. I guess we have different notions of "experience" in mind here. It seems to me that the one you are using is "how long you have been serving on the CTTE", right? If it is so, and given that you consider re-appointments unlikely, I understand that from your POV the overall experience of the CTTE will suffer if this proposal were to pass. (As mentioned in a separate mail, I don't think it is that unlikely for CTTE members to be re-appointed after "vacation", so my perception of loss is lower, but I'll ignore that for now.) I think that the experience we should looking for in CTTE members should be pre-existing, in project areas like dealing with pesky technical issues (possibly at the intersection of many inter-connected packages), and in being able to manage standardization-like processes from discussion to synthesis. I expect this experience to be formed mostly outside the CTTE, in large packaging teams and/or working as interface between packaging teams and/or in the policy team. The only other kind of interesting additional experience that is CTTE specific is conflict arbitration. It is certainly very important for the job, but I don't think it is enough, alone, to justify longer terms. (You probably disagree :-)) Also, it is something that IMHO members would have to learn elsewhere anyhow (due to their personal life experiences, previous jobs, professional training, etc). > long as they are able to do their job with the level of quality required > by the role. So, yes, I think that the replacement of inactive, > demotivated or no longer suited members is much more important than to > the replacement of the more senior members. [...] > Note that I agree that turn-over is good. > > I also generally agree that remaining in charge too long is bad. However: > - I think that what is "too long" might depend on individual factors > - I don't think that 4 years is a reasonable value for "too long". We can certainly discuss on your second point, and possibly have different values for N on the ballot. That's easy. But your first point is essentially delegating to case-by-case decisions what to do, which is by definition not something you can obtain with a strict rule. I.e., it seems to me that your first point calls in to question whether we should have a strict rule in the first place. 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 19/11/14 at 11:55 +0100, Stefano Zacchiroli wrote: > On Wed, Nov 19, 2014 at 10:13:45AM +0100, Lucas Nussbaum wrote: > > Now, let's assume that I'm a member of the TC, not among the two most > > senior members, and that I feel a bit exhausted about that, not really > > motivated, and not really up to the task anymore. Ideally, I should be > > encouraged to resign. > > With the 'strictly 2' schema, I have an additional incentive NOT to > > resign: if I resign, I cause 3 renewals instead of 2, which might weaken > > the TC a bit too much. > > This is true only insofar a temporary reduction in CTTE membership > actually weakens the CTTE. I don't think that's the case. Formally, the > Constitution suggests ranges in which the CTTE is somehow considered to > be properly functional; outside those ranges, there is no quality > judgement associate to CTTE size. More generally in management terms, > larger boards are not necessarily "better" than smaller ones (in fact, > in the specific case of efficiency, size is usually considered to be > _negatively_ correlated with it, due to the communication overhead). > > But more importantly, we are talking here about *temporary* reductions > in CTTE size, with a time window that might be as small as 0. The CTTE > and the DPL will know in advance that expiries are upcoming, and can > plan new appointments accordingly, potentially doing appointments as > early as January 2nd. If it is known that someone will step in (no > matter whether you know who that person will be or not), then the > negative incentive you mention disappears. This is true only if you use the number of members as the measure for the "strength" of the TC. But if instead, you consider the sum of the experience of all members, more turnover due to resignations at a given point will have a greater impact. Of course, the TC will likely be mostly resilient to that. But if we can avoid that, I think we should. > > With the '2-R' schema, I have an additional incentive to resign: if I > > resign, I 'save' someone else more senior than me from getting expired. > > (And given I'm not so active anymore, instead of weakening the TC further, > > my resignation might even reinforce the TC). > > It seems to me that you've an underlying assumption here that > resignation of inactive members are more important than resignation of > senior members. For me they are exactly on the same level, so I don't > see why one should be technically favored over the other. Oh yes, sure. I don't care very much about the seniority of members, as long as they are able to do their job with the level of quality required by the role. So, yes, I think that the replacement of inactive, demotivated or no longer suited members is much more important than to the replacement of the more senior members. > (It is worth noting here that I'm thinking about this master in fully > abstract terms, I do not have any specific present, past, or future > members of the CTTE in mind. Same here. > Nor I know offhand the current seniority ranking.) Well, I can't say that, given I did the research to do the stats in <20141119103725.gb9...@xanadu.blop.info> > > 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. Note that I agree that turn-over is good. I also generally agree that remaining in charge too long is bad. However: - I think that what is "too long" might depend on individual factors - I don't think that 4 years is a reasonable value for "too long". Lucas signature.asc Description: Digital signature
Re: [DRAFT] Maximum term for tech ctte members
On Wed, Nov 19, 2014 at 10:13:45AM +0100, Lucas Nussbaum wrote: > (Elaborating on the context a bit given the discussion spread over some > time -- two options have been proposed: > - expire the 2 most senior members > - expire the 2-R most senior members, with R the number of resignations > over the last 12 months) ACK. For reference this was discussed mostly in [1,2], unfortunately with not too many people participating. My draft is based on the apparent potential consensus (between me and AJ, as the main participants in the discussion). It is indeed an important point, so thanks for re-raising it. [1]: https://lists.debian.org/debian-vote/2014/11/msg00041.html [2]: https://lists.debian.org/debian-vote/2014/11/msg00098.html That said, I now am convinced that "2" (without "salvaging" by expiries of non-senior members) is a better model than "2-R". I've pondered your arguments below, but I don't find them convincing. Specifically, > What we want to encourage is, I think, a sane and healthy turnover in > the TC. Ideally, this would happen automatically: members would just > resign when they feel that bringing fresh manpower is profitable to > the TC overall. However, there's a number of social reasons why this > doesn't work so well. Agreed. > Now, let's assume that I'm a member of the TC, not among the two most > senior members, and that I feel a bit exhausted about that, not really > motivated, and not really up to the task anymore. Ideally, I should be > encouraged to resign. > With the 'strictly 2' schema, I have an additional incentive NOT to > resign: if I resign, I cause 3 renewals instead of 2, which might weaken > the TC a bit too much. This is true only insofar a temporary reduction in CTTE membership actually weakens the CTTE. I don't think that's the case. Formally, the Constitution suggests ranges in which the CTTE is somehow considered to be properly functional; outside those ranges, there is no quality judgement associate to CTTE size. More generally in management terms, larger boards are not necessarily "better" than smaller ones (in fact, in the specific case of efficiency, size is usually considered to be _negatively_ correlated with it, due to the communication overhead). But more importantly, we are talking here about *temporary* reductions in CTTE size, with a time window that might be as small as 0. The CTTE and the DPL will know in advance that expiries are upcoming, and can plan new appointments accordingly, potentially doing appointments as early as January 2nd. If it is known that someone will step in (no matter whether you know who that person will be or not), then the negative incentive you mention disappears. > With the '2-R' schema, I have an additional incentive to resign: if I > resign, I 'save' someone else more senior than me from getting expired. > (And given I'm not so active anymore, instead of weakening the TC further, > my resignation might even reinforce the TC). It seems to me that you've an underlying assumption here that resignation of inactive members are more important than resignation of senior members. For me they are exactly on the same level, so I don't see why one should be technically favored over the other. Also if there are no incentives against resigning (which I maintain as per my answer to your other argument) I do expect inactive members to resign no matter whether they are senior or not. And if they do not want to, then it is much better to have a strict term limit rule, rather than one allowing for exceptions. (It is worth noting here that I'm thinking about this master in fully abstract terms, I do not have any specific present, past, or future members of the CTTE in mind. Nor I know offhand the current seniority ranking.) > 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. 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 19/11/14 at 10:13 +0100, Lucas Nussbaum wrote: > > - The main change wrt the original text by Anthony is that the provision > > of not expiring senior members if less-senior ones have resigned is > > gone. In its stead, there is a provision that inhibits expiries from > > reducing the CTTE size below 4 members. As a result, the math part > > with N and R is gone, IMHO simplifying the text. > > Hi, > > I thought about that change, and I am unsure that this is a good thing. To clarify: by 'that change', I mean the switch from '2-R most senior members' to '2 most senior members'. The quoted paragraph is mostly about something else, but I failed to find another place where that change was discussed. Lucas signature.asc Description: Digital signature
Re: [DRAFT] Maximum term for tech ctte members
Le mercredi, 19 novembre 2014, 10.13:45 Lucas Nussbaum a écrit : > 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 quite like the idea. I was also thinking of something along the lines of "automatic resignation unless self-extended", similar to what we have (although mildly working) for DMs. This would be equivalent to saying that the TC terms are of one year, renewed manually by "stating so", up to 5 times. This would allow automatic expiry of members becoming inactive for some reason, without implying a TC+DPL decision (§6.2.5). This would also put the "should I continue be part of the TC for a new one-year term" question explicitly and annually on the table. OdyX signature.asc Description: This is a digitally signed message part.
Re: [DRAFT] Maximum term for tech ctte members
On 18/11/14 at 11:33 +0100, Stefano Zacchiroli wrote: > Here is a draft GR text which builds on Anthony's work and implements > some of the aspects discussed in this thread. See below for > comments/rationales and the attachment for a wdiff. > > == > The Constitution is amended as follows: > > --- > --- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100 > +++ constitution.txt.new 2014-11-18 11:12:13.665659796 +0100 > @@ -299,8 +299,28 @@ > 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 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 the 2 most senior members automatically expire > +provided they were appointed at least 54 months ago. > + 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. > + 3. At each review round expiries are processed sequentially, most > +senior member first. > + 4. No expiry can reduce the size of the Technical Committee to > +3 members or fewer. (It might thus happen that up to 4 members of > +the Technical Committee remain in charge with more than 54 months > +of seniority on January 1st. In that case, up to 2 of them will > +expire at the next review round, provided that the committee has > +been further staffed.) > >6.3. Procedure > > --- > > As a transitional measure, if this GR proposal is passed after 2015-01-01, > then the first automatic review of membership of the Technical Committee > happens immediately. > == > > - The main change wrt the original text by Anthony is that the provision > of not expiring senior members if less-senior ones have resigned is > gone. In its stead, there is a provision that inhibits expiries from > reducing the CTTE size below 4 members. As a result, the math part > with N and R is gone, IMHO simplifying the text. Hi, I thought about that change, and I am unsure that this is a good thing. (Elaborating on the context a bit given the discussion spread over some time -- two options have been proposed: - expire the 2 most senior members - expire the 2-R most senior members, with R the number of resignations over the last 12 months) What we want to encourage is, I think, a sane and healthy turnover in the TC. Ideally, this would happen automatically: members would just resign when they feel that bringing fresh manpower is profitable to the TC overall. However, there's a number of social reasons why this doesn't work so well. So what we are proposing here is to force the renewal of some members. Now, let's assume that I'm a member of the TC, not among the two most senior members, and that I feel a bit exhausted about that, not really motivated, and not really up to the task anymore. Ideally, I should be encouraged to resign. With the 'strictly 2' schema, I have an additional incentive NOT to resign: if I resign, I cause 3 renewals instead of 2, which might weaken the TC a bit too much. With the '2-R' schema, I have an additional incentive to resign: if I resign, I 'save' someone else more senior than me from getting expired. (And given I'm not so active anymore, instead of weakening the TC further, my resignation might even reinforce the TC). 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. What do you think? Lucas signature.asc Description: Digital signature
Re: [DRAFT] Maximum term for tech ctte members
On Tue, Nov 18, 2014 at 09:44:43PM +0100, Didier 'OdyX' Raboud wrote: > > This is still pending, and noted in BUGS. I agree this is as a > > potential problem, at least if you look at it from a paranoid angle. > > I find your suggested wording not immediate, though, and I wonder if > > a/ someone else has better suggestion, and b/ whether this is worth > > fixing. > > What about something along the lines of "At this time, the terms of > members who have been members for more than 54 months automatically > expire." ? I've proposed a solution to this shortly before your message. Can you look at it and follow-up if you're not happy with it and have an alternative proposal? > Another point though: > > 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. > > Provided that the expiration happens on January first, does this imply > that if A was expired on 01.01.2015, she becomes eligible again on > 01.01.2016? As I read the two new clauses, given someone the project > really wants on the TC, she can stay 5 years, break for a year and be > re-appointed, right? That is correct, yes. > All-in-all, I feel the change goes in the right direction, but I also > feel it only goes halfway through (probably the half we can collectively > agree on though). The two issues I'd like to see fixed on a longer term > are "quite long mandates" (although the fix helps here) I guess it does, yes. Of course it depends on your notion of "quite long", but ~5 years matches my intuitive notion of "long but not too long" terms in board-like settings. > and "imperfect representativity of the diversity of the project caused > by self- appointment", which I'd like to get fixed through some sort > of election through the project. Sorry, I digressed; let's keep that > for a later discussion. TBH I'm not sure how one could fix that with a hard rule either way, but if you've specific proposals I'm all ears :) But please let's avoid making perfect the enemy of the good (...nd once again I'm done with my daily dose of lame proverbs). 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
Hi, On Dienstag, 18. November 2014, Don Armstrong wrote: > The real reason to use an odd number is to avoid having to use the > casting vote in the CTTE. Considering that we've used the casting vote > exactly once in the entire history of Debian, I'm not sure that > including this is worth the effort if even one person disagrees. according to https://www.debian.org/devel/tech-ctte the very first tech-ctte decission was decided by Ian through casting vote... Thinking aloud: maybe this casting vote is a bad idea, and if the even number of tech-ctte members cannot agree we must have... a GR? discussions til we light up some fire until we have white smoke? cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: [DRAFT] Maximum term for tech ctte members
On Tue, 18 Nov 2014, Holger Levsen wrote: > (FWIW, I _think_ I prefer an even number here... and despite labeling > this a "game changer" I'm not sure I care that much about this > change... arg and this might sound like it could be misunderstood > again...) The real reason to use an odd number is to avoid having to use the casting vote in the CTTE. Considering that we've used the casting vote exactly once in the entire history of Debian, I'm not sure that including this is worth the effort if even one person disagrees. -- Don Armstrong http://www.donarmstrong.com You could say she lived on the edge... Well, maybe not exactly on the edge, just close enough to watch other people fall off. -- hugh macleod http://www.gapingvoid.com/Moveable_Type/archives/000309.html -- 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/20141118205723.gc4...@rzlab.ucr.edu
Re: [DRAFT] Maximum term for tech ctte members
Hi zack@, Thanks for pushing this subject forward, it's a constitutional change I would likely second. Le mardi, 18 novembre 2014, 14.15:25 Stefano Zacchiroli a écrit : > > "provided /they/ were appointed" reads to me like it might mean that > > if only one of them was appointed that long ago, maybe neither of > > them expire. I'm not sure I can think of anything better; maybe > > something like "At this time, the terms of members who were > > appointed at least 54 months ago automatically expire. Expiry > > occurs in order of seniority, and is limited to at most the two > > most senior members." would be better? But I'm not sure this is > > worth fixing. > > This is still pending, and noted in BUGS. I agree this is as a > potential problem, at least if you look at it from a paranoid angle. > I find your suggested wording not immediate, though, and I wonder if > a/ someone else has better suggestion, and b/ whether this is worth > fixing. What about something along the lines of "At this time, the terms of members who have been members for more than 54 months automatically expire." ? Another point though: > 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. Provided that the expiration happens on January first, does this imply that if A was expired on 01.01.2015, she becomes eligible again on 01.01.2016? As I read the two new clauses, given someone the project really wants on the TC, she can stay 5 years, break for a year and be re-appointed, right? All-in-all, I feel the change goes in the right direction, but I also feel it only goes halfway through (probably the half we can collectively agree on though). The two issues I'd like to see fixed on a longer term are "quite long mandates" (although the fix helps here) and "imperfect representativity of the diversity of the project caused by self- appointment", which I'd like to get fixed through some sort of election through the project. Sorry, I digressed; let's keep that for a later discussion. Cheers, OdyX -- 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/2993924.FIlfxOZmI7@gyllingar
Re: [DRAFT] Maximum term for tech ctte members
Hi Don, On Dienstag, 18. November 2014, Don Armstrong wrote: > This patch is simple, but: > -1. The Technical Committee consists of up to 8 Developers, and should > +1. The Technical Committee consists of up to 9 Developers, and should [...] > But if this is at all controversial, then we can put this forward later. It's a game changer, IMHO, so I guess it will be somewhat controversial for sure and should be presented as (an) explicit option(s) on ballots... (FWIW, I _think_ I prefer an even number here... and despite labeling this a "game changer" I'm not sure I care that much about this change... arg and this might sound like it could be misunderstood again...) ;tldr;: clear ballots, "no editorial changes" please. Holger signature.asc Description: This is a digitally signed message part.
Re: [DRAFT] Maximum term for tech ctte members
On Tue, 18 Nov 2014, Stefano Zacchiroli wrote: > On Tue, Nov 18, 2014 at 10:41:13PM +1000, Anthony Towns wrote: > > "provided /they/ were appointed" > > This is still pending, and noted in BUGS. I agree this is as a potential > problem, at least if you look at it from a paranoid angle. I find your > suggested wording not immediate, though, and I wonder if a/ someone else > has better suggestion, and b/ whether this is worth fixing. Maybe this: diff --git a/constitution.txt.new b/constitution.txt.new index 96245cf..fb5ac4a 100644 --- a/constitution.txt.new +++ b/constitution.txt.new @@ -305,10 +305,10 @@ 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 the 2 most senior members automatically expire -provided they were appointed at least four and a half years -(54 months) ago. +reviewed on the 1st of January of each year. At this time, +the terms of the 2 most senior members who were most +recently appointed at least 54 months ago automatically +expire. 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 -- 2.1.1 Also, one of the things that would also be nice to fix is to make the max number of CTTE members 9 instead of 8, to avoid the casting vote problem when the CTTE is full. I don't believe that we should force the CTTE to have an odd number, because that is complicated, and may not be worth the effort, either. This patch is simple, but: diff --git a/constitution.txt.new b/constitution.txt.new index 96245cf..85f0043 100644 --- a/constitution.txt.new +++ b/constitution.txt.new @@ -288,9 +288,9 @@ 6.2. Composition -1. The Technical Committee consists of up to 8 Developers, and should +1. The Technical Committee consists of up to 9 Developers, and should usually have at least 4 members. -2. When there are fewer than 8 members the Technical Committee may +2. When there are fewer than 9 members the Technical Committee may recommend new member(s) to the Project Leader, who may choose (individually) to appoint them or not. 3. When there are 5 members or fewer the Technical Committee may -- 2.1.1 But if this is at all controversial, then we can put this forward later. -- Don Armstrong http://www.donarmstrong.com LEADERSHIP -- A form of self-preservation exhibited by people with autodestructive imaginations in order to ensure that when it comes to the crunch it'll be someone else's bones which go crack and not their own. -- The HipCrime Vocab by Chad C. Mulligan (John Brunner _Stand On Zanzibar_ p256-7) -- 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/20141118202142.gz4...@rzlab.ucr.edu
Re: [DRAFT] Maximum term for tech ctte members
On Tue, 18 Nov 2014 14:15:25 +0100, Stefano Zacchiroli said: >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 the 2 most senior members automatically expire >provided they were appointed at least four and a half years >(54 months) ago. One possible reading of that is that both members must have been appointed at least 54 months ago in order for either of them to be expired, which is probably not what was meant. I'm not entirely sure what a better wording would be. Maybe adding an extra sentence saying: "If only one member was appointed at least four and a half years (54 months) ago, that member's term expires." But I'm not too happy with they way that flows, and maybe someone can come up with something better. -- 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/871tp0mteu@desiato.home.uhoreg.ca
Re: Re: [DRAFT] Maximum term for tech ctte members
Hi, > 6.2. Composition > > 1. The Technical Committee consists of up to 8 Developers, and should >usually have at least 4 members. > 2. When there are fewer than 8 members the Technical Committee may >recommend new member(s) to the Project Leader, who may choose >(individually) to appoint them or not. > 3. When there are 5 members or fewer the Technical Committee may >appoint new member(s) until the number of members reaches 6. > 4. When there have been 5 members or fewer for at least one week the >Project Leader may appoint new member(s) until the number of >members reaches 6, at intervals of at least one week per >appointment. Why not avoid the casting vote problem by stipulating that the number of members should always be an odd number. In case it is a problem of keeping this number always odd, at least when voting is required, the number of voters should be odd (either by excluding or including one voter). (Yes, I know about the Condorcet Voting System with Schwartz Sequential Dropping.) Sincerely -- 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/1416318282.11764.95.ca...@g3620.my.own.domain
Re: [DRAFT] Maximum term for tech ctte members
On Tue, Nov 18, 2014 at 10:41:13PM +1000, Anthony Towns wrote:
> Looks good to me.
Thanks for your feedback. New draft attached implementing (almost all)
the changes you suggested. The GR text is now also available at
http://git.upsilon.cc/?p=text/gr-ctte-term-limit.git;a=summary
which also contains BUGS{_archive,} files listing fixed and pending
issues.
> > + 3. At each review round expiries are processed sequentially, most
> > +senior member first.
> > + 4. No expiry can reduce the size of the Technical Committee to
> > +3 members or fewer. (It might thus happen that up to 4
[...]
> I guess I'd still be inclined to drop both of those; I don't see much
> difference between (letting the membership drop to 5 or 4 at which point
> DPL can increase it without the ctte's cooperation) and (letting the
> membership drop to 5, 4, 3, 2, 1 or 0 at which point the DPL can increase
> it without the ctte's cooperation), and making it another two paragraphs
> simpler would be a win.
>
> Wording simplifications and fixes for my en_IT idiosyncrasies are
I'm convinced by your arguments. After all, the committee can become
understaffed for reasons other than expiries, and the Constitution
already has a mechanism for dealing with that: more liberal ctte
appointment by the DPL alone. (And Occam's razor rocks anyhow.)
Fixed in the new draft attached.
I note that this might be seen as flying a little bit in the face of
continuity---which we have discussed before in this thread. But that
theoretical problem is balanced by the fact that we limit expiries to 2
per year. That should be enough to induce a fairly regular turn-over.
> "not eligible to be (re)appointed" perhaps?
Fixed.
(For those who care about uniformity: yes the "(re)appointed" syntax was
already used elsewhere in the Constitution.)
> "provided /they/ were appointed" reads to me like it might mean that if
> only one of them was appointed that long ago, maybe neither of them expire.
> I'm not sure I can think of anything better; maybe something like "At this
> time, the terms of members who were appointed at least 54 months ago
> automatically expire. Expiry occurs in order of seniority, and is limited
> to at most the two most senior members." would be better? But I'm not sure
> this is worth fixing.
This is still pending, and noted in BUGS. I agree this is as a potential
problem, at least if you look at it from a paranoid angle. I find your
suggested wording not immediate, though, and I wonder if a/ someone else
has better suggestion, and b/ whether this is worth fixing.
> Maybe "(It might thus happen that at the start of January 1st the
> Technical Committee is composed of just 4 members, all of whom were
> appointed more than 54 months ago. If so, no one's term will expire.
> However if additional members are appointed in the next year, then the 2
> most senior members' terms will expire at the next review round.)" would be
> better? I'm not sure if this needs explaining though?
This has become moot, as the underlying text is gone.
> I wonder if "four and a half years (54 months)" would be better.
Fixed.
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 »
Constitution for the Debian Project (v1.4)
Version 1.4 ratified on October 7th, 2007. Supersedes Version 1.3
ratified on September 24th, 2006, Version 1.2 ratified on October 29th,
2003 and Version 1.1 ratified on June 21st, 2003, which itself
supersedes Version 1.0 ratified on December 2nd, 1998.
1. Introduction
The Debian Project is an association of individuals who have made
common cause to create a free operating system.
This document describes the organisational structure for formal
decision-making in the Project. It does not describe the goals of the
Project or how it achieves them, or contain any policies except those
directly related to the decision-making process.
2. Decision-making bodies and individuals
Each decision in the Project is made by one or more of the following:
1. The Developers, by way of General Resolution or an election;
2. The Project Leader;
3. The Technical Committee and/or its Chairman;
4. The individual Developer working on a particular task;
5. Delegates appointed by the Project Leader for specific tasks;
6. The Project Secretary.
Most of the remainder of this document will outline the powers of these
bodies, their composition and appointment, and the procedure for their
decision-making. The powers of a person or body may be subject to
review and/or limitation by others; in this case the reviewing body or
person's entry will state this. In the list above, a person or bod
Re: [DRAFT] Maximum term for tech ctte members
On 18 November 2014 20:33, Stefano Zacchiroli wrote: > Here is a draft GR text which builds on Anthony's work and implements > some of the aspects discussed in this thread. See below for > comments/rationales and the attachment for a wdiff. > Looks good to me. > + 3. At each review round expiries are processed sequentially, most > +senior member first. > + 4. No expiry can reduce the size of the Technical Committee to > +3 members or fewer. (It might thus happen that up to 4 > members of > +the Technical Committee remain in charge with more than 54 > months > +of seniority on January 1st. In that case, up to 2 of them > will > +expire at the next review round, provided that the committee > has > +been further staffed.) > I guess I'd still be inclined to drop both of those; I don't see much difference between (letting the membership drop to 5 or 4 at which point DPL can increase it without the ctte's cooperation) and (letting the membership drop to 5, 4, 3, 2, 1 or 0 at which point the DPL can increase it without the ctte's cooperation), and making it another two paragraphs simpler would be a win. Wording simplifications and fixes for my en_IT idiosyncrasies are > particularly welcome. > Hmm. Wording seemed fine to me. Suggestions anyway: "not eligible to be (re)appointed" perhaps? "provided /they/ were appointed" reads to me like it might mean that if only one of them was appointed that long ago, maybe neither of them expire. I'm not sure I can think of anything better; maybe something like "At this time, the terms of members who were appointed at least 54 months ago automatically expire. Expiry occurs in order of seniority, and is limited to at most the two most senior members." would be better? But I'm not sure this is worth fixing. Maybe "(It might thus happen that at the start of January 1st the Technical Committee is composed of just 4 members, all of whom were appointed more than 54 months ago. If so, no one's term will expire. However if additional members are appointed in the next year, then the 2 most senior members' terms will expire at the next review round.)" would be better? I'm not sure if this needs explaining though? I wonder if "four and a half years (54 months)" would be better. Cheers, aj -- Anthony Towns
[DRAFT] Maximum term for tech ctte members
Here is a draft GR text which builds on Anthony's work and implements some of the aspects discussed in this thread. See below for comments/rationales and the attachment for a wdiff. == The Constitution is amended as follows: --- --- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100 +++ constitution.txt.new2014-11-18 11:12:13.665659796 +0100 @@ -299,8 +299,28 @@ 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 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 the 2 most senior members automatically expire +provided they were appointed at least 54 months ago. + 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. + 3. At each review round expiries are processed sequentially, most +senior member first. + 4. No expiry can reduce the size of the Technical Committee to +3 members or fewer. (It might thus happen that up to 4 members of +the Technical Committee remain in charge with more than 54 months +of seniority on January 1st. In that case, up to 2 of them will +expire at the next review round, provided that the committee has +been further staffed.) 6.3. Procedure --- As a transitional measure, if this GR proposal is passed after 2015-01-01, then the first automatic review of membership of the Technical Committee happens immediately. == - The main change wrt the original text by Anthony is that the provision of not expiring senior members if less-senior ones have resigned is gone. In its stead, there is a provision that inhibits expiries from reducing the CTTE size below 4 members. As a result, the math part with N and R is gone, IMHO simplifying the text. My understanding of [1] is that we might find consensus (at least among the people who have shown interest in drafting this proposal) on the above text. Please correct me if I'm wrong. [1]: https://lists.debian.org/debian-vote/2014/11/msg00098.html Specifically, I do agree with the potentially weird incentives that reaching the threshold of 4 members will induce. But I also agree with the fact that DPL's power to restaff the ctte until it reaches 6 members (basically by him/herself) is enough to make the problem moot. - I've added point (3) about the order in which expiries are processed to disambiguate the case in which the ctte is composed by 5 members with 2 senior ones. In that case we want one expiry to be acted upon but not the other (I think). - I've integrated Lucas suggestion about the transitional measure in case we get this approved after January 1st. I welcome comments, reviews, etc. Wording simplifications and fixes for my en_IT idiosyncrasies are particularly welcome. 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 » Constitution for the Debian Project (v1.4) Version 1.4 ratified on October 7th, 2007. Supersedes Version 1.3 ratified on September 24th, 2006, Version 1.2 ratified on October 29th, 2003 and Version 1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 ratified on December 2nd, 1998. 1. Introduction The Debian Project is an association of individuals who have made common cause to create a free operating system. This document describes the organisational structure for formal decision-making in the Project. It does not describe the goals of the Project or how it achieves them, or contain any policies except those directly related to the decision-making proc
