subject:"Maximum term for tech ctte members"

On Sun, Nov 23, 2014 at 12:08:26PM +0100, Lucas Nussbaum wrote:
 Our voting system is designed to handle this case just fine, and the
 only drawback is that it makes the voting slightly more complex
 because project members have to compare two options, and not just
 approve/disapprove one -- but I think that voters can handle this
 additional complexity just fine.

Note that I never said voters cannot handle the complexity. I wanted to
avoid it in the first place, if possible, because it has a cost. From
your mail I conclude that avoiding it is not possible (assuming all
proposed options will receive enough seconds, that is).

 I think that you should propose the option you consider best; I will
 propose 2-R, because I still have a strong preference for that option
 compared to 2-S, 2-R' or 2.

Fair enough.

How about the transitional measure? I think it would be nice to have
uniformity on those. Would you agree to drop the transitional measures,
with the rationale that the CTTE has already have quite a bit of churn?

I now think the above would be appropriate for both 2 and 2-R. To obtain
an equivalent result with 2-S I think the transitional measure should
retroactively trigger a review on January 1st, 2015; which will in turn
cause expiries only on December 31st, 2015.

 However, as I am not sure if it's just me, or if there's wider support
 for 2-R, I will ask the secretary to not automatically accept the
 amendment (as an amendment from the DPL), but instead require it to
 reach the usual number of sponsors.

I can't find the reference right now, but IIRC we've discussed this
during the init system coupling GR and I don't think it's possible: you
are DPL, if you introduce an amendment, it's automatically accepted. I
don't remember if the Secretary acknowledged that interpretation, but
reading of §4.2.1 doesn't seem to leave much room for interpretation.
So you could either ask someone else to propose the amendment, or gather
seconds informally yourself and only propose the amendment when you've
received K of them.

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: [SUMMARY] Maximum term for tech ctte members

2014-11-23 Thread Lucas Nussbaum

On 23/11/14 at 12:32 +0100, Stefano Zacchiroli wrote:
 On Sun, Nov 23, 2014 at 12:08:26PM +0100, Lucas Nussbaum wrote:
  I think that you should propose the option you consider best; I will
  propose 2-R, because I still have a strong preference for that option
  compared to 2-S, 2-R' or 2.
 
 Fair enough.
 
 How about the transitional measure? I think it would be nice to have
 uniformity on those. Would you agree to drop the transitional measures,
 with the rationale that the CTTE has already have quite a bit of churn?
 
 I now think the above would be appropriate for both 2 and 2-R. To obtain
 an equivalent result with 2-S I think the transitional measure should
 retroactively trigger a review on January 1st, 2015; which will in turn
 cause expiries only on December 31st, 2015.

A transitional measure does not have any effect on 2-R anyway, due to
the recent resignations.

For 2, I agree that it would be better not to have expiries before
2016-01-01.  Note that to achieve that without a transitional measure,
the GR must pass on 2015-01-02 at the earliest; which means that the
vote must not start before 2014-12-19, and that the discussion period
must not start before 2014-12-05. It might not be worth waiting until
then, so you might want to add a transitional measure such as:

  As a transitional measure, the first automatic review of membership
  of the Technical Committee will happen on 2016-01-01.

  However, as I am not sure if it's just me, or if there's wider support
  for 2-R, I will ask the secretary to not automatically accept the
  amendment (as an amendment from the DPL), but instead require it to
  reach the usual number of sponsors.
 
 I can't find the reference right now, but IIRC we've discussed this
 during the init system coupling GR and I don't think it's possible: you
 are DPL, if you introduce an amendment, it's automatically accepted. I
 don't remember if the Secretary acknowledged that interpretation, but
 reading of §4.2.1 doesn't seem to leave much room for interpretation.
 So you could either ask someone else to propose the amendment, or gather
 seconds informally yourself and only propose the amendment when you've
 received K of them.

According to 20141017174252.gb10...@roeckx.be, I think it's possible.
But maybe the Secretary can clarify.

Lucas


signature.asc
Description: Digital signature

Re: [DRAFT] Maximum term for tech ctte members

2014-11-23 Thread Wouter Verhelst

On Sat, Nov 22, 2014 at 03:46:49PM +, Philip Hands wrote:
 Philip Hands p...@hands.com writes:
 
  Wouter Verhelst wou...@debian.org 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

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: [SUMMARY] Maximum term for tech ctte members

2014-11-23 Thread Sam Hartman

 Stefano == Stefano Zacchiroli z...@debian.org writes:


Stefano - 2-S seems to be some sort of middle ground among the
Stefano first choices in the hypothetical votes you proposed above
Stefano (and in fact it was proposed by AJ precisely as a mediation
Stefano among them)

Stefano - 2-S seems to have received only positive reactions on
Stefano this list

I think 2 and 2-s suffer from the same problem.  Namely, in situations
like the current one, they produce more churn than I like.
So far I'd probably only second 2-r and not 2 or 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/0149dd7296b1-28ab5477-58e3-44d9-b885-00c2061ed950-000...@email.amazonses.com

Re: [SUMMARY] Maximum term for tech ctte members

TL;DR: the latest complete drafts of proposals 2, 2-R, and 2-S are
available at:

  https://people.debian.org/~zack/gr-ctte-term-limit/

please have a look if you care about any of them.

On Sun, Nov 23, 2014 at 12:57:32PM +0100, Lucas Nussbaum wrote:
 A transitional measure does not have any effect on 2-R anyway, due to
 the recent resignations.

Correct. But the latest draft of 2-R still contained a (redundant, given
the current churn) transitional measure. Given your mail, I've now
removed it, please let me know if you've further changes [1].

[1]: https://people.debian.org/~zack/gr-ctte-term-limit/gr.2-R.txt

 For 2, I agree that it would be better not to have expiries before
 2016-01-01.  Note that to achieve that without a transitional measure,
 the GR must pass on 2015-01-02 at the earliest; which means that the
 vote must not start before 2014-12-19, and that the discussion period
 must not start before 2014-12-05. It might not be worth waiting until
 then, so you might want to add a transitional measure such as:
 
   As a transitional measure, the first automatic review of membership
   of the Technical Committee will happen on 2016-01-01.

That looked like a good idea to me, so I've implemented it [2].

[2]: https://people.debian.org/~zack/gr-ctte-term-limit/gr.2.txt


For 2-S, I've done my best to adapt its transitional measure to have
roughly the same effect of other proposals. And I've tried to formulate
it in a way that is independent of whether the GR is passed before or
after December 31st. What I came up with is [3]:

  As a transitional measure, if this GR is passed after December 31st,
  2014, the term of any Committee member who, as of January 1st, 2015,
  had served more than 42 months (3.5 years) and who was one of the two
  most senior members is set to expire on December 31st, 2015.

[3]: https://people.debian.org/~zack/gr-ctte-term-limit/gr.2-S.txt

  I can't find the reference right now, but IIRC we've discussed this
  during the init system coupling GR and I don't think it's possible: you
  are DPL, if you introduce an amendment, it's automatically accepted. I
  don't remember if the Secretary acknowledged that interpretation, but
  reading of §4.2.1 doesn't seem to leave much room for interpretation.
  So you could either ask someone else to propose the amendment, or gather
  seconds informally yourself and only propose the amendment when you've
  received K of them.
 
 According to 20141017174252.gb10...@roeckx.be, I think it's possible.
 But maybe the Secretary can clarify.

Ah yes, that was the thread I had in mind, thanks. I found follow-ups to
that message [4,5] to be fairly convincing, but we clearly need an
answer from the Secretary.

[4]: https://lists.debian.org/debian-vote/2014/10/msg00172.html
[5]: https://lists.debian.org/debian-vote/2014/10/msg00194.html

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

2014-11-23 Thread Philip Hands

Stefano Zacchiroli z...@debian.org 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 Sun, Nov 23, 2014 at 09:00:11PM +, Philip Hands wrote:
 Stefano Zacchiroli z...@debian.org 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

2014-11-22 Thread Wouter Verhelst

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: Re: [DRAFT] Maximum term for tech ctte members

2014-11-22 Thread Wouter Verhelst

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

2014-11-22 Thread Stefano Zacchiroli

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: [SUMMARY] Maximum term for tech ctte members

2014-11-22 Thread Stefano Zacchiroli

On Fri, Nov 21, 2014 at 11:29:40AM +0100, Lucas Nussbaum wrote:
 Considering only 2*, if we were to vote today, my vote would probably be:
 2-R  2-R'  2-S  2  FD
 I'm assuming your vote would be:
 2  2-S  2-R'  2-R  FD
 This is hard to reconcile.
[...]
 But I don't think that a ballot with several options is necessarily
 very bad, as our voting system handles those cases just fine.
 
 What we should focus on is ensuring that it remains easy for everybody
 to understand and rank the various options.

Yes, that is the issue. What you propose (summaries with pro/cons) is of
course a solution, but it requires quite a bit of work. And even if we
do that work, the decision about how to vote would be more complex for
DDs in comparison with a more straightforward yes/no ballot. And all
this is, IMO, for relatively little gain, as we are essentially
bikeshedding on minutiae at this point.

Given that:

- 2-S seems to be some sort of middle ground among the first choices in
  the hypothetical votes you proposed above (and in fact it was proposed
  by AJ precisely as a mediation among them)

- 2-S seems to have received only positive reactions on this list

would you refrain from proposing 2-R as an amendment if 2-S were to be
the initial GR proposal? If so, I'd be happy to do the same for 2, and
we can have a simple yes/no ballot.

I.e., can we agree on 2-S as a mediation and simplify voting for
everyone?

For reference, I'm attaching the current version of the 2-S GR text.
I'm still waiting to see if people object to that idea, but the only
remaining change I'd like to apply to that proposal is to remove the
transitional measure, on the basis of the fact that we've already had
quite a bit of churn in the CTTE due to recent events.

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-S.txt2014-11-21 16:56:47.328071287 +0100
@@ -299,8 +299,20 @@
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. On January 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 December
+31st of that 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
 
---

As a transitional measure, 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 as of
January 1st, 2014 is set to expire one month after this GR is passed.


signature.asc
Description: Digital signature

Re: [DRAFT] Maximum term for tech ctte members

2014-11-22 Thread Wouter Verhelst

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: [SUMMARY] Maximum term for tech ctte members

2014-11-22 Thread Hubert Chathi

On Sat, 22 Nov 2014 12:35:28 +0100, Stefano Zacchiroli z...@debian.org said:

[...]

 For reference, I'm attaching the current version of the 2-S GR text.
 I'm still waiting to see if people object to that idea, but the only
 remaining change I'd like to apply to that proposal is to remove the
 transitional measure, on the basis of the fact that we've already had
 quite a bit of churn in the CTTE due to recent events.

For the record, I added the transitional measure for easier comparison
with the other methods, but other than that, due to the amount churn
that we've already had, I have no opinion as to whether it should be
there or not, as I mentioned in another email.

-- 
Hubert Chathi uho...@debian.org -- 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/87h9xrmkhc@desiato.home.uhoreg.ca

Re: [DRAFT] Maximum term for tech ctte members

2014-11-22 Thread Philip Hands

Wouter Verhelst wou...@debian.org 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

2014-11-22 Thread Philip Hands

Philip Hands p...@hands.com writes:

 Wouter Verhelst wou...@debian.org 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: [SUMMARY] Maximum term for tech ctte members

2014-11-22 Thread Jakub Wilk


* Stefano Zacchiroli z...@debian.org, 2014-11-22, 12:35:
As a transitional measure, 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 as of January 1st, 2014 is set to expire one month after 
this GR is passed.


s/who has/who had/,
s/who is/who was/?

--
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/20141122154717.ga4...@jwilk.net

[SUMMARY] Maximum term for tech ctte members

2014-11-21 Thread Lucas Nussbaum

Hi,

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

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

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

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

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

Here is a tentative list of the various proposals:

soft: 20141119220621.ga31...@master.debian.org
  Technical Committee members are encouraged to serve for a term of
  between three and six years.

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

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


There are three different variants that consider resignations/removals:

2-R: 20141119091345.ga9...@xanadu.blop.info, formalized in
   20141120204606.ga30...@upsilon.cc
  expire the 2-R most senior members, with R the number of resignations/removals
  over the last 12 months)

2-R': 20141119220621.ga31...@master.debian.org
  R' is the number of resignations of people who have been on the TC for more
  than 4.5 years

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


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

(I hope I didn't miss too much)

Lucas


signature.asc
Description: Digital signature

Re: [SUMMARY] Maximum term for tech ctte members

2014-11-21 Thread Stefano Zacchiroli

On Fri, Nov 21, 2014 at 10:45:18AM +0100, Lucas Nussbaum wrote:
 I'm trying to summarize the thread here, so that others have an easy
 way in.

Thanks.

 soft: 20141119220621.ga31...@master.debian.org
 max: 20141120192253.GA6120@jtriplet-mobl1
 2: 20141120204606.ga30...@upsilon.cc
 2-R: 20141119091345.ga9...@xanadu.blop.info, formalized in
 2-R': 20141119220621.ga31...@master.debian.org
 2-S: 874mttkatj@desiato.home.uhoreg.ca

FWIW, I'm trying to collect at

  http://git.upsilon.cc/?p=text/gr-ctte-term-limit.git;a=tree

one fully fleshed out proposal for each (reasonable) proposal on the
table. At present, I've 2, 2-R, and max (which is in the fact the
name for it that I've proposed to Josh, who has kindly submitted a patch
for it).  I don't have yet soft, 2-S, and 2-R' (it would be nice
to have a better title for the latter one).

Patches welcome to fill the above gaps. What to do should be trivial
after reading README. make will do for you the Constitution diffing
and GR text preparation.


That said, I do believe we are almost in the realm of bikeshed/minutiae
here, and I would see as a problem having a ballot with the above 6
options + FD.  So I do hope we can converge/compromise, at least among
option proposers, on a single option.

If we cannot, I'm personally going to call for second on *one* myself
(the one that I consider most convincing), after giving this list (and
-ctte) at least 1 week of advance notice. Others can propose and/or
second amendments, taking on their share of responsibility for having a
larger ballot.


Lucas: can I conclude from your summary that you do *not* have a 7th
alternative proposal in the working (which is what I was assuming thus
far)?


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: [SUMMARY] Maximum term for tech ctte members

2014-11-21 Thread Lucas Nussbaum

On 21/11/14 at 10:59 +0100, Stefano Zacchiroli wrote:
 That said, I do believe we are almost in the realm of bikeshed/minutiae
 here, and I would see as a problem having a ballot with the above 6
 options + FD.  So I do hope we can converge/compromise, at least among
 option proposers, on a single option.
 
 If we cannot, I'm personally going to call for second on *one* myself
 (the one that I consider most convincing), after giving this list (and
 -ctte) at least 1 week of advance notice. Others can propose and/or
 second amendments, taking on their share of responsibility for having a
 larger ballot.

Considering only 2*, if we were to vote today, my vote would probably be:
2-R  2-R'  2-S  2  FD
I'm assuming your vote would be:
2  2-S  2-R'  2-R  FD
This is hard to reconcile. But I don't think that a ballot with several
options is necessarily very bad, as our voting system handles those
cases just fine.

What we should focus on is ensuring that it remains easy for everybody
to understand and rank the various options. I think that we are in
agreement with the various pros and cons of the various options: maybe
options proposers could write together a short document explaining how
the various options compare, and that document could be on the vote
page? Also, it would make sense to order options on the ballot using the
amount of churn they would produce as a metric, so that the above two
votes would be 12345 and 43215, rather than 34215 :)

 Lucas: can I conclude from your summary that you do *not* have a 7th
 alternative proposal in the working (which is what I was assuming thus
 far)?

At this point I don't plan to propose anything else.

Lucas


signature.asc
Description: Digital signature

Re: [DRAFT] Maximum term for tech ctte members

2014-11-21 Thread Sam Hartman

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

2014-11-21 Thread Stefano Zacchiroli

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

2014-11-21 Thread Sam Hartman

Stefano == Stefano Zacchiroli z...@debian.org 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

2014-11-21 Thread Stefano Zacchiroli

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

2014-11-21 Thread Hubert Chathi

On Fri, 21 Nov 2014 12:12:13 +, Sam Hartman hartm...@debian.org 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 uho...@debian.org -- 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 #2] Maximum term for tech ctte members

2014-11-20 Thread Anthony Towns

On Thu, Nov 20, 2014 at 08:01:54AM +0100, Lucas Nussbaum wrote:
   I don't think that the TC is a stress-full role. Obviously the recent past
   proved how the role can be incredibly stressful at times. But there has
   also been long periods without much activity, [...]

FWIW, I agree with Steve here. The nature of the tech ctte is that it
only does things when there's some sort of significant enough problem
that can't be dealt with by other means, and that's pretty much always
going to be stressful. If the problem's not significant, no one cares
enough to take it to the ctte; if it's easy, it just gets dealt with. If
it's hard and important, dealing with it will be stressful...

That said, the breaks without activity make it easier, certainly --
I can't imagine someone lasting as DPL or release manager for 16 or 13
or 9 years, for instance.

Cheers,
aj


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141120082146.ga21...@master.debian.org

Re: [DRAFT #2] Maximum term for tech ctte members

2014-11-20 Thread Lucas Nussbaum

On 20/11/14 at 08:21 +, Anthony Towns wrote:
 On Thu, Nov 20, 2014 at 08:01:54AM +0100, Lucas Nussbaum wrote:
I don't think that the TC is a stress-full role. Obviously the recent 
past
proved how the role can be incredibly stressful at times. But there has
also been long periods without much activity, [...]
 
 FWIW, I agree with Steve here. The nature of the tech ctte is that it
 only does things when there's some sort of significant enough problem
 that can't be dealt with by other means, and that's pretty much always
 going to be stressful. If the problem's not significant, no one cares
 enough to take it to the ctte; if it's easy, it just gets dealt with. If
 it's hard and important, dealing with it will be stressful...
 
 That said, the breaks without activity make it easier, certainly --
 I can't imagine someone lasting as DPL or release manager for 16 or 13
 or 9 years, for instance.

I think that this is a (quite useless) discussion about the exact
meaning of 'stress-full'. To be clear, I fully agree that the stress
level of TC members has probably been super-high for the last 3 years or
so. But I hope that this is just an anomaly, and that at some point it
will return to being super-high only from time to time (when there are
decisions to make), so that on average it isn't such a stress-full role.

Lucas


signature.asc
Description: Digital signature

Re: [DRAFT #2] Maximum term for tech ctte members

2014-11-20 Thread Sam Hartman

Watching other volunteer organizations, I've found that having turnover
somewhere between 3-5 years tends to work fairly well.

I've seen this in student organizations where the turnover tends to be
somewhat encouraged by graduation although in the cases I'm thinking of
that did not force the issue.
By 3 years someone is very good at what they do. However, they start to
burn out and start to not notice or take advantage of good ideas.
The burn out is becoming a significant issue by 5 years.

I've seen the same thing in the IETF. There, two years is really just
enough to learn some of the leadership roles and to get into the stride
of things. Those roles are fairly intense. Four years tends to work
quite well, but by 6 years (two year terms), people really do tend to be
burned out. Even the best people are showing significant signs of being
jaded and abrupt. They don't pursue things with the dedication they
used to, they don't dedicate as much time to working with folks to
understand all sides, consensus decisions seem to be more forced.

Keep in mind that TC members can seek wizdom and institutional memory
from outside the TC. There's nothing stopping a TC member next year
from writing to Russ, Ian, collin, or even older TC members to get
advice.

The point should be to have people with good technical judgment and
current willingness to come up with solutions that make the project
stronger. That doesn't require a huge memory of being on the TC.

--Sam

--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/0149ccdf9746-1d35b433-b0a5-4589-9623-6de0a0a06bac-000...@email.amazonses.com

Re: [DRAFT] Maximum term for tech ctte members

2014-11-20 Thread Sam Hartman

Lucas == Lucas Nussbaum lu...@debian.org 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

2014-11-20 Thread Scott Kitterman

On Thursday, November 20, 2014 12:33:28 PM Sam Hartman wrote:
  Lucas == Lucas Nussbaum lu...@debian.org 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

2014-11-20 Thread Stefano Zacchiroli

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

2014-11-20 Thread Stefano Zacchiroli

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

2014-11-20 Thread Hubert Chathi

On Thu, 20 Nov 2014 17:59:31 +0100, Stefano Zacchiroli z...@debian.org 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 uho...@debian.org -- 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

2014-11-20 Thread Lucas Nussbaum

Hi Phil,

On 19/11/14 at 16:44 +, Philip Hands wrote:
 Stefano Zacchiroli z...@debian.org 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

2014-11-20 Thread Lucas Nussbaum

On 20/11/14 at 13:04 -0500, Hubert Chathi wrote:
 On Thu, 20 Nov 2014 17:59:31 +0100, Stefano Zacchiroli z...@debian.org 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

2014-11-20 Thread Philip Hands

Lucas Nussbaum lu...@debian.org writes:

 On 20/11/14 at 13:04 -0500, Hubert Chathi wrote:
 On Thu, 20 Nov 2014 17:59:31 +0100, Stefano Zacchiroli z...@debian.org 
 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

2014-11-20 Thread Sam Hartman

 Stefano == Stefano Zacchiroli z...@debian.org 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 - 2-R model

2014-11-20 Thread Stefano Zacchiroli

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 - 2-R model

2014-11-20 Thread Hubert Chathi

On Thu, 20 Nov 2014 21:46:06 +0100, Stefano Zacchiroli z...@debian.org 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 uho...@debian.org -- 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

2014-11-20 Thread Anthony Towns

On Thu, Nov 20, 2014 at 07:51:16PM +, Philip Hands wrote:
 Lucas Nussbaum lu...@debian.org 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

2014-11-20 Thread Hubert Chathi

On Thu, 20 Nov 2014 21:17:11 +, Anthony Towns a...@erisian.com.au said:

 On Thu, Nov 20, 2014 at 07:51:16PM +, Philip Hands wrote:
 Lucas Nussbaum lu...@debian.org 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 uho...@debian.org -- 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

2014-11-20 Thread Jakub Wilk


* Anthony Towns a...@erisian.com.au, 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

2014-11-20 Thread Philip Hands

Anthony Towns a...@erisian.com.au writes:

 On Thu, Nov 20, 2014 at 07:51:16PM +, Philip Hands wrote:
 Lucas Nussbaum lu...@debian.org 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

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

2014-11-19 Thread Didier 'OdyX' Raboud

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 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 #2] Maximum term for tech ctte members

Hi,

First, some data. The 'age' of each member of the TC (not excluding Russ and
Colin) is:
aba 2005-12-27 8764pbxd9k@glaurung.internal.golden-gryphon.com, 8.9y
bdale 2001-04-17 20010417195420.i5...@visi.net, ~13.6y
cjwatson 2011-08-24 20110824160257.ga30...@upsilon.cc, 3.2y
don 2009-01-11 87zlhx3c2s@rover.gag.com, 5.8y
iwj at some point in 1999; ~15.3y
rra 2009-01-11 87zlhx3c2s@rover.gag.com, 5.8y
vorlon 2005-12-27 8764pbxd9k@glaurung.internal.golden-gryphon.com, 8.9y
keithp  2013-11-29 20131129161152.ga9...@xanadu.blop.info, 0.9y

So the average time spent in the TC is 7.8 years. (8.9 years without
Russ and Colin)

On 18/11/14 at 21:49 +0100, Stefano Zacchiroli wrote:
 +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.

Even if the possibility is open, I doubt that many expired TC members
will actually re-apply the year after their expiration. The message sent
by the project is quite clear: they should probably do something else.

So this proposal is likely to significantly reduce the average 'age' of
TC members, to ~2 or 3 years.

I totally see the point in preventing the ossification of the TC.
Clearly, it is a good thing if many TC members are involved in
day-to-day Debian activities outside of the TC, and even preferably in
day-to-day *core* Debian activities (core team membership, maintenance
of important packages, etc). It's useful to feel what it's like to
maintain packages etc, to fully understand the impact of their
decisions. I don't think that we want a TC that is an advisory board,
where, for all members, being in the TC is the only thing they do in
Debian.

On the other hand, the TC is the kind of committee where it's useful to
have members with quite a lot of memory about past decisions (and
possibly, mistakes). There's not so much activity (well, in general), so
experience builds up slowly. Also, even if there's a correlation in
general between age and ossification, we could have older members that
manage to stay young, active, and generally useful to the TC.

I fear that, by reducing the average 'age' from 7.8 years to ~2 years,
we are going too far. I would like to make it easier, for some members,
to stay members of the TC for longer than 4 years. OTOH, I don't want
this decision to be taken lightly.

I'm not sure of how to achieve that. We could just drop the mandatory
vacation clause, and have expired TC members go through the same process
as prospective new members (nomination, etc.). The TC and the DPL would
then have to consider whether it's better to re-appoint an old member,
or to replace him/her with a new one. But maybe that's not enough to
ensure the suitable rate of change...

What do you think?

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 #2] Maximum term for tech ctte members

On Wed, Nov 19, 2014 at 11:37:25AM +0100, Lucas Nussbaum wrote:
 On 18/11/14 at 21:49 +0100, Stefano Zacchiroli wrote:
  +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.
 
 Even if the possibility is open, I doubt that many expired TC members
 will actually re-apply the year after their expiration. The message sent
 by the project is quite clear: they should probably do something else.

I disagree that that would be the message that the project send to CTTE
members when they hit the term limit. There is nothing *personal* in a
term limit, it's a common sense rule to ensure turn-over. Nothing more,
nothing less.

I do understand that *current* CTTE members might, in theory, take this
GR the wrong way and think that it is a GR against them personally.
(This is in fact why I do plan, as mentioned before, to explicitly
invite CTTE members to get involved in this discussion once the
landscape of proposals on the table has clarified.) If that were to
happen, you're probably correct on the fact that those members will
probably not apply again. My only answer here is that we should do our
best to convey to them the rationale behind this change in the
abstract. (Which is also why I try hard not to look at, or think of, the
seniority ranking among current CTTE members.)

But once the rule is agreed upon, I do not see why anyone should take
reaching the term limit badly.

It seems to me that the year off is a win-win scenario for all involved
actors. The senior member get a chance of reassessing whether they want
to keep on working with CTTE stuff without the social awkwardness of
having to explain why they step down. If they come back, the rest of the
CTTE and the DPL get a chance to reassess whether the reapplying member
would still be a good fit for the CTTE and the Project. If they do not
come back, then probably they should have stepped down more or less at
the same time anyhow and, once again, we have spared them some social
awkwardness.

 On the other hand, the TC is the kind of committee where it's useful
 to have members with quite a lot of memory about past decisions (and
 possibly, mistakes). There's not so much activity (well, in general),
 so experience builds up slowly. Also, even if there's a correlation in
 general between age and ossification, we could have older members that
 manage to stay young, active, and generally useful to the TC.

Fine. We will then just offer them 1 year of vacation from CTTE duties
every now and then, I believe many people in other Debian core teams
dream of that :-)

 I fear that, by reducing the average 'age' from 7.8 years to ~2 years,
 we are going too far. I would like to make it easier, for some members,
 to stay members of the TC for longer than 4 years. OTOH, I don't want
 this decision to be taken lightly.

Again, this is true only under the assumption that former members won't
come back.

But even with that assumption, it seems you're arguing for the fact that
a term limit of 4.5 years (and therefore an average of about half of
that, modulo the transition period) is too short. It's hard to judge
that in the abstract, but my gut feeling is that it is in fact quite
long. Volunteers, especially when active in stress-full roles, do need
shorter cycles.

 I'm not sure of how to achieve that. We could just drop the mandatory
 vacation clause, and have expired TC members go through the same
 process as prospective new members (nomination, etc.). The TC and the
 DPL would then have to consider whether it's better to re-appoint an
 old member, or to replace him/her with a new one. But maybe that's not
 enough to ensure the suitable rate of change...
 
 What do you think?

I see where you are going, but all in all it seems to me you have in
mind a different model from what has been now distilled in the current
draft. Which is of course absolutely fine. I'd love to see a more
complete sketch of your model (e.g., as a draft GR) to better compare
and contrast. Maybe the best way forward here is to come up with
alternative models and have all of them in a GR.

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 #2] Maximum term for tech ctte members

On 19/11/14 at 12:25 +0100, Stefano Zacchiroli wrote:
 On Wed, Nov 19, 2014 at 11:37:25AM +0100, Lucas Nussbaum wrote:
  I fear that, by reducing the average 'age' from 7.8 years to ~2 years,
  we are going too far. I would like to make it easier, for some members,
  to stay members of the TC for longer than 4 years. OTOH, I don't want
  this decision to be taken lightly.
 
 Again, this is true only under the assumption that former members won't
 come back.
 
 But even with that assumption, it seems you're arguing for the fact that
 a term limit of 4.5 years (and therefore an average of about half of
 that, modulo the transition period) is too short. It's hard to judge
 that in the abstract, but my gut feeling is that it is in fact quite
 long. Volunteers, especially when active in stress-full roles, do need
 shorter cycles.

I don't think that the TC is a stress-full role. Obviously the recent past
proved how the role can be incredibly stressful at times. But there has
also been long periods without much activity, as shown on
https://www.debian.org/devel/tech-ctte or
https://lists.debian.org/stats/debian-ctte.png

  I'm not sure of how to achieve that. We could just drop the mandatory
  vacation clause, and have expired TC members go through the same
  process as prospective new members (nomination, etc.). The TC and the
  DPL would then have to consider whether it's better to re-appoint an
  old member, or to replace him/her with a new one. But maybe that's not
  enough to ensure the suitable rate of change...
  
  What do you think?
 
 I see where you are going, but all in all it seems to me you have in
 mind a different model from what has been now distilled in the current
 draft. Which is of course absolutely fine. I'd love to see a more
 complete sketch of your model (e.g., as a draft GR) to better compare
 and contrast. Maybe the best way forward here is to come up with
 alternative models and have all of them in a GR.

Maybe. I'll wait for a few more days for additional feedback.
Also, I'm not entirely satisfied with my proposal to just drop the
mandatory vacation clause, and have expired TC members go through the
same process as other candidates if they want another term.
 
Lucas


signature.asc
Description: Digital 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

2014-11-19 Thread Philip Hands

Stefano Zacchiroli z...@debian.org 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 #2] Maximum term for tech ctte members

2014-11-19 Thread Jakub Wilk


* Stefano Zacchiroli z...@debian.org, 2014-11-18, 21:49:

-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.


Not sure why you had to renumber existing stuff;
but other than that, looks good to me!

--
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/20141119173131.ga5...@jwilk.net

Re: [DRAFT #2] Maximum term for tech ctte members

On Wed, Nov 19, 2014 at 06:31:31PM +0100, Jakub Wilk wrote:
 * Stefano Zacchiroli z...@debian.org, 2014-11-18, 21:49:
 -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.
 
 Not sure why you had to renumber existing stuff;

So, that is because (a) logically the point about the vacation period
seems more related to appointment rather than removal from the CTTE, and
therefore (b) to preserve the relative order of list items about
appointment vs list items about removal.

But if renumbering one point of the Constitution is annoying (Cc:-ing
secretary) we can certainly switch 5 with 6 and avoid it.

FWIW I did check, and I didn't find any reference /in the Constitution/
to §6.2.5 that would become dangling due to this renumbering.

 but other than that, looks good to me!

Thanks for your feedback!

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 #2] Maximum term for tech ctte members

2014-11-19 Thread Anthony Towns

On Wed, Nov 19, 2014 at 11:37:25AM +0100, Lucas Nussbaum wrote:
 First, some data. The 'age' of each member of the TC (not excluding Russ and
 Colin) is:
 aba 2005-12-27 8764pbxd9k@glaurung.internal.golden-gryphon.com, 8.9y
 bdale 2001-04-17 20010417195420.i5...@visi.net, ~13.6y
 cjwatson 2011-08-24 20110824160257.ga30...@upsilon.cc, 3.2y
 don 2009-01-11 87zlhx3c2s@rover.gag.com, 5.8y
 iwj at some point in 1999; ~15.3y
 rra 2009-01-11 87zlhx3c2s@rover.gag.com, 5.8y
 vorlon 2005-12-27 8764pbxd9k@glaurung.internal.golden-gryphon.com, 8.9y
 keithp  2013-11-29 20131129161152.ga9...@xanadu.blop.info, 0.9y

I already did the refs for these in May:

https://lists.debian.org/debian-project/2014/05/msg00054.html

Ian was a founding member of the ctte in 1998, not '99; so with his
resignation today combined with the constitution passing on 23 Nov 1998,
he served three days short of 16 years by my count.

 So the average time spent in the TC is 7.8 years. (8.9 years without
 Russ and Colin)

That's only true of the current members, I went through the past members in

https://lists.debian.org/debian-project/2014/05/msg00077.html

Basically about 5 or 6 years average when you include them.

 On 18/11/14 at 21:49 +0100, Stefano Zacchiroli wrote:
  +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.
 Even if the possibility is open, I doubt that many expired TC members
 will actually re-apply the year after their expiration. The message sent
 by the project is quite clear: they should probably do something else.

I think that depends on how many good candidates the project can find
for tech ctte members. If there's just, say, 10 people, I can easily
imagine people re-volunteering a year after to keep the ctte filled. If
there's 20 or more (which I expect is the case), I'd expect you're right,
and that, having been on the ctte for 5 years, people would take the
opportunity for a longer break than 12 months.

None of that's a value judgement though, and at least I, personally, don't
think/intend that the proposed change should be interpreted that way.

 So this proposal is likely to significantly reduce the average 'age' of
 TC members, to ~2 or 3 years.

In one sense, that's trivially true: if the max age is 5.5 years
(appointment on Jul 2nd, hitting 4.49 years on Jan 1st, then expiring
at 5.49 years next Jan 1st), no one resigns ever, and you somehow get
an even distribution of member ages, that would look something like:

  8 months x 2
 25 months x 2
 41 months x 2
 58 months x 2

which averages to about 33 months (2 years 9 months) average age. That's
despite an average length of service of between 4.5 and 5.5 years since
by assumption, no one ever resigns. I think the length of service is more
important than the average age, personally.

 On the other hand, the TC is the kind of committee where it's useful to
 have members with quite a lot of memory about past decisions (and
 possibly, mistakes). 

First, even if that's true, you don't have to have been on the ctte to
have seen its decisions or mistakes -- it's constitutionally required
to operate in the open, so *anyone* (DD or not) can follow its decision
making processes, either in real time, or by looking through the archives.
Further, past-committee members can always be sought out for advice
and more insight into previous decisions if that's needed/desired --
they don't have to retain seats on the ctte for their memories to be
used in decisions.

Second, I'm not sure that is true -- assuming a mistake was made in
the past, whoever made it is is more likely to defend it, repeat it,
or simiply not want to admit it, than someone who wasn't involved and
can view the issue more objectively.

 I fear that, by reducing the average 'age' from 7.8 years to ~2 years,

I think you'd be better off focussing on max(age) than average here
-- even if the only way of getting info on past decisions was to have
someone who was there on the committee, you only need one person, not
half of them to have been around that long.

A max age of 2 years would be pretty unsustainable IMO, but I don't think
it's terribly realistic either (and could be worked around by ex-members
getting reappointed after 12 months off anyway).

 I'm not sure of how to achieve that. We could just drop the mandatory
 vacation clause, and have expired TC members go through the same process
 as prospective new members (nomination, etc.). The TC and the DPL would
 then have to consider whether it's better to re-appoint an old member,
 or to replace him/her with a new one. But maybe that's not enough to
 ensure the suitable rate of change...

Russ's reaction to this was that it would be very hard not to
automatically reappoint a current member:

  The social pressures here don't work very well.  In general, any
  approach that has the existing committee decide whether to retain
  a member who's

Re: Re: [DRAFT #2] Maximum term for tech ctte members

2014-11-19 Thread Bdale Garbee

An easy way to resolve the question about the mandatory vacation
period would be to just have both variants available when this goes to
GR?  In other words, let the project decide whether that seems prudent.

For the record, as the now-longest-serving member of the TC, I'll be the
first person to go if any term limit measure is put in place, and I'm
not emotional about either the overall idea of term limits, or about
this sub-question. 

Bdale


signature.asc
Description: PGP signature

Re: [DRAFT] Maximum term for tech ctte members

2014-11-19 Thread Anthony Towns

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

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 #2] Maximum term for tech ctte members

On 19/11/14 at 19:13 +, Anthony Towns wrote:
 Russ's reaction to this was that it would be very hard not to
 automatically reappoint a current member:
 
   The social pressures here don't work very well.  In general, any
   approach that has the existing committee decide whether to retain
   a member who's already on the committee has the potential for hard
   feelings, creating future difficulties working together, and so forth.
   This is why I favor some system that requires a pause; that way, no
   one is put in the position of having to refuse to reappoint someone
   that they've worked with for the last eight years.
 
-- https://lists.debian.org/debian-project/2014/05/msg00081.html
 
 I found that pretty persuasive personally.

OK, point taken.
So either we find a way to re-appoint a current member that avoids that
social pressure (but that would likely require changing the appointment
procedure entirely), or we drop the idea of not having a mandatory
vacation between two appointments. (which sounds more likely)
 
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/20141119211836.gb28...@xanadu.blop.info

Re: [DRAFT] Maximum term for tech ctte members

2014-11-19 Thread Anthony Towns

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 #2] Maximum term for tech ctte members

2014-11-19 Thread David Weinehall

On Wed, Nov 19, 2014 at 10:18:36PM +0100, Lucas Nussbaum wrote:
 On 19/11/14 at 19:13 +, Anthony Towns wrote:
  Russ's reaction to this was that it would be very hard not to
  automatically reappoint a current member:
  
The social pressures here don't work very well.  In general, any
approach that has the existing committee decide whether to retain
a member who's already on the committee has the potential for hard
feelings, creating future difficulties working together, and so forth.
This is why I favor some system that requires a pause; that way, no
one is put in the position of having to refuse to reappoint someone
that they've worked with for the last eight years.
  
 -- https://lists.debian.org/debian-project/2014/05/msg00081.html
  
  I found that pretty persuasive personally.
 
 OK, point taken.
 So either we find a way to re-appoint a current member that avoids that
 social pressure (but that would likely require changing the appointment
 procedure entirely), or we drop the idea of not having a mandatory
 vacation between two appointments. (which sounds more likely)

How about only accepting reappointment during the cooloff period if

a.) the committee is short more than one person
*AND*
b.) the nomination comes from the DPL?

That way, if the DPL observes that the TC clearly struggles to find a
new member he can nominate a cooloff:ee, but the TC cannot do so
themselves.

PS: To preempt possible objections that this allows for the TC
to gamble the system by claiming that there are no viable candidates:
I fully trust the TC to be above such behaviour *AND* I also fully
trust the DPL to see through such a behaviour if it, against all odds,
would take place.


Kind regards, David
-- 
 /) David Weinehall t...@debian.org /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
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/20141119223245.gg8...@hirohito.acc.umu.se

Re: [DRAFT #2] Maximum term for tech ctte members

2014-11-19 Thread Steve Langasek

On Wed, Nov 19, 2014 at 01:59:33PM +0100, Lucas Nussbaum wrote:
 On 19/11/14 at 12:25 +0100, Stefano Zacchiroli wrote:
  On Wed, Nov 19, 2014 at 11:37:25AM +0100, Lucas Nussbaum wrote:
   I fear that, by reducing the average 'age' from 7.8 years to ~2 years,
   we are going too far. I would like to make it easier, for some members,
   to stay members of the TC for longer than 4 years. OTOH, I don't want
   this decision to be taken lightly.

  Again, this is true only under the assumption that former members won't
  come back.

  But even with that assumption, it seems you're arguing for the fact that
  a term limit of 4.5 years (and therefore an average of about half of
  that, modulo the transition period) is too short. It's hard to judge
  that in the abstract, but my gut feeling is that it is in fact quite
  long. Volunteers, especially when active in stress-full roles, do need
  shorter cycles.

 I don't think that the TC is a stress-full role.

snort

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: [DRAFT] Maximum term for tech ctte members

2014-11-19 Thread Matthias Urlichs

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 #2] Maximum term for tech ctte members

On 19/11/14 at 22:31 -0600, Steve Langasek wrote:
 On Wed, Nov 19, 2014 at 01:59:33PM +0100, Lucas Nussbaum wrote:
  On 19/11/14 at 12:25 +0100, Stefano Zacchiroli wrote:
   On Wed, Nov 19, 2014 at 11:37:25AM +0100, Lucas Nussbaum wrote:
I fear that, by reducing the average 'age' from 7.8 years to ~2 years,
we are going too far. I would like to make it easier, for some members,
to stay members of the TC for longer than 4 years. OTOH, I don't want
this decision to be taken lightly.
 
   Again, this is true only under the assumption that former members won't
   come back.
 
   But even with that assumption, it seems you're arguing for the fact that
   a term limit of 4.5 years (and therefore an average of about half of
   that, modulo the transition period) is too short. It's hard to judge
   that in the abstract, but my gut feeling is that it is in fact quite
   long. Volunteers, especially when active in stress-full roles, do need
   shorter cycles.
 
  I don't think that the TC is a stress-full role.
 
 snort

Steve, I think you know better than to misquote. The full paragraph was:

  I don't think that the TC is a stress-full role. Obviously the recent past
  proved how the role can be incredibly stressful at times. But there has
  also been long periods without much activity, as shown on
  https://www.debian.org/devel/tech-ctte or
  https://lists.debian.org/stats/debian-ctte.png


I think that Debian is currently going through a set of difficult decisions,
and that the activity level (and stress level) of the TC will return to
something more acceptable at some point. If it doesn't, then we have a problem,
because I don't think that it's normal to rely so much on a last resort
committee. It would say something about our inability to make good decisions in
the normal course of actions.

Lucas


signature.asc
Description: Digital signature

[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

Re: [DRAFT] Maximum term for tech ctte members

2014-11-18 Thread Anthony Towns

On 18 November 2014 20:33, Stefano Zacchiroli z...@debian.org 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 a...@erisian.com.au

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 body is
   usually listed before any people or

Re: Re: [DRAFT] Maximum term for tech ctte members

2014-11-18 Thread Svante Signell

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

2014-11-18 Thread Hubert Chathi

On Tue, 18 Nov 2014 14:15:25 +0100, Stefano Zacchiroli z...@debian.org 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 uho...@debian.org -- 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: [DRAFT] Maximum term for tech ctte members

2014-11-18 Thread Don Armstrong

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

2014-11-18 Thread Holger Levsen

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

2014-11-18 Thread Didier 'OdyX' Raboud

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

[DRAFT #2] Maximum term for tech ctte members

On Tue, Nov 18, 2014 at 11:33:10AM +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.

Updated draft below.

Changelog is:

- fixed the potential ambiguous all or nothing interpretation of the
  provided /they/ ... formulation.

  I've received and tried to integrate feedback from various people on
  that point (Anthony Towns, Hubert Chathi, Lars Noschinski). As Don
  Armstrong's fix came in while I was writing this mail, I've discussed
  both solutions with him and we agree the one below is preferable as it
  is more explicit

- updated the transitional measure to be first term review 1 month
  after the GR is passed, unconditionally.

  This is to avoid uncertainty about how long the ctte will have to
  adapt to the upcoming expiries depending on whether the GR is passed
  (if it is, of course) before of after January 1st. In theory the new
  formulation would be problematic if we were to pass the GR near the
  end of November (because it would induce two expiration rounds in a
  very short period), but that's impossible considering a minimum of 1+1
  weeks of discussion+voting periods from now. I've discussed the new
  formulation (who proposed the original transitional measure) and he is
  fine with it.

Cheers.

===
The Constitution is amended as follows:

---
--- constitution.txt.orig   2014-11-17 18:02:53.314945907 +0100
+++ constitution.txt.new2014-11-18 21:17:30.544040579 +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
 
---

As a transitional measure, the first automatic review of membership of the
Technical Committee will happen 1 month after this GR is passed.
===

-- 
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 #2] Maximum term for tech ctte members

2014-11-18 Thread Martin Zobel-Helas

Hi, 

On Tue Nov 18, 2014 at 21:49:52 +0100, Stefano Zacchiroli wrote:
 ===
 The Constitution is amended as follows:
 
 ---
 --- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
 +++ constitution.txt.new  2014-11-18 21:17:30.544040579 +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.

*second*


-- 
 Martin Zobel-Helas zo...@debian.orgDebian System Administrator
 Debian  GNU/Linux Developer   Debian Listmaster
 http://about.me/zobel   Debian Webmaster
 GPG Fingerprint:  6B18 5642 8E41 EC89 3D5D  BDBB 53B1 AC6D B11B 627B 


signature.asc
Description: Digital signature

Re: [DRAFT] Maximum term for tech ctte members

2014-11-18 Thread Don Armstrong

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

2014-11-18 Thread Holger Levsen

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