Discussion:
GR proposal, Call for Seconds - term limit for the tech-ctte
(too old to reply)
Stefano Zacchiroli
2014-12-01 11:20:25 UTC
Permalink
[ Cross post -vote, -project ; M-F-T: to -vote.

For more background information on the development of this proposal,
see https://lists.debian.org/debian-vote/2014/11/msg00274.html ]

I'm hereby formally submitting the GR proposal included below between
dashed double lines, and calling for seconds. With respect to past
discussions on the -vote mailing list, this is the proposal code-named
"2-S"; see [1,2] for (the last known versions of) alternative proposals.

[1]: https://people.debian.org/~zack/gr-ctte-term-limit/
[2]: http://git.upsilon.cc/?p=text/gr-ctte-term-limit.git;a=tree

===========================================================================
The Constitution is amended as follows:

---------------------------------------------------------------------------
--- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
+++ constitution.2-S.txt 2014-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, if this GR is passed after January 1st, 2015,
then the provision of section §6.2.7.1 is taken to have occurred on January
1st, 2015.
===========================================================================

I'd like to thank Anthony Towns for introducing the term limit idea
several months ago [3] and for his help in polishing it through several
rounds of feedback on the -vote mailing list.

[3]: https://lists.debian.org/debian-project/2014/05/threads.html#00054

Cheers.
--
Stefano Zacchiroli . . . . . . . ***@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 »
Jakub Wilk
2014-12-01 12:10:34 UTC
Permalink
Post by Stefano Zacchiroli
===========================================================================
---------------------------------------------------------------------------
--- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
+++ constitution.2-S.txt 2014-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.
+ 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, if this GR is passed after January 1st, 2015,
then the provision of section §6.2.7.1 is taken to have occurred on January
1st, 2015.
===========================================================================
Seconded.
--
Jakub Wilk
Aníbal Monsalve Salazar
2014-12-01 12:20:45 UTC
Permalink
Post by Stefano Zacchiroli
===========================================================================
---------------------------------------------------------------------------
--- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
+++ constitution.2-S.txt 2014-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.
+ 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, if this GR is passed after January 1st, 2015,
then the provision of section §6.2.7.1 is taken to have occurred on January
1st, 2015.
===========================================================================
Seconded!
Ricardo Mones
2014-12-01 12:15:40 UTC
Permalink
Post by Stefano Zacchiroli
[ Cross post -vote, -project ; M-F-T: to -vote.
For more background information on the development of this proposal,
see https://lists.debian.org/debian-vote/2014/11/msg00274.html ]
I'm hereby formally submitting the GR proposal included below between
dashed double lines, and calling for seconds. With respect to past
discussions on the -vote mailing list, this is the proposal code-named
"2-S"; see [1,2] for (the last known versions of) alternative proposals.
[1]: https://people.debian.org/~zack/gr-ctte-term-limit/
[2]: http://git.upsilon.cc/?p=text/gr-ctte-term-limit.git;a=tree
===========================================================================
---------------------------------------------------------------------------
--- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
+++ constitution.2-S.txt 2014-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.
+ 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, if this GR is passed after January 1st, 2015,
then the provision of section §6.2.7.1 is taken to have occurred on January
1st, 2015.
===========================================================================
I'd like to thank Anthony Towns for introducing the term limit idea
several months ago [3] and for his help in polishing it through several
rounds of feedback on the -vote mailing list.
[3]: https://lists.debian.org/debian-project/2014/05/threads.html#00054
Seconded.
--
Ricardo Mones
~
Never send a human to do a machine's job. Agent Smith
Didier 'OdyX' Raboud
2014-12-01 12:40:14 UTC
Permalink
Post by Stefano Zacchiroli
I'm hereby formally submitting the GR proposal included below between
dashed double lines, and calling for seconds. With respect to past
discussions on the -vote mailing list, this is the proposal code-named
"2-S"; see [1,2] for (the last known versions of) alternative proposals.
[1]: https://people.debian.org/~zack/gr-ctte-term-limit/
[2]: http://git.upsilon.cc/?p=text/gr-ctte-term-limit.git;a=tree
===========================================================================
---------------------------------------------------------------------------
--- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
+++ constitution.2-S.txt 2014-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.
+ 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, if this GR is passed after January 1st, 2015,
then the provision of section §6.2.7.1 is taken to have occurred on January
1st, 2015.
===========================================================================
Seconded.

OdyX
Cyril Brulebois
2014-12-01 12:45:07 UTC
Permalink
Post by Stefano Zacchiroli
===========================================================================
---------------------------------------------------------------------------
--- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
+++ constitution.2-S.txt 2014-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.
+ 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, if this GR is passed after January 1st, 2015,
then the provision of section §6.2.7.1 is taken to have occurred on January
1st, 2015.
===========================================================================
Seconded.

Mraw,
KiBi.
--
To UNSUBSCRIBE, email to debian-vote-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@mraw.org
Cyril Brulebois
2014-12-01 12:46:22 UTC
Permalink
Post by Stefano Zacchiroli
===========================================================================
---------------------------------------------------------------------------
--- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
+++ constitution.2-S.txt 2014-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.
+ 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, if this GR is passed after January 1st, 2015,
then the provision of section §6.2.7.1 is taken to have occurred on January
1st, 2015.
===========================================================================
Seconded. (Signed this time, sorry for the noise.)

Mraw,
KiBi.
Colin Tuckley
2014-12-01 12:49:42 UTC
Permalink
Post by Stefano Zacchiroli
===========================================================================
---------------------------------------------------------------------------
--- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
+++ constitution.2-S.txt 2014-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.
+ 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, if this GR is passed after January 1st, 2015,
then the provision of section §6.2.7.1 is taken to have occurred on January
1st, 2015.
===========================================================================
Seconded!
--
Colin Tuckley | +44(0)1223 830814 | PGP/GnuPG Key Id
Debian Developer | +44(0)7799 143369 | 0x38C9D903

Famous last words - Icarus: Aaaahhhhhhhhh.
Sebastian Ramacher
2014-12-01 12:48:27 UTC
Permalink
Post by Stefano Zacchiroli
===========================================================================
---------------------------------------------------------------------------
--- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
+++ constitution.2-S.txt 2014-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.
+ 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, if this GR is passed after January 1st, 2015,
then the provision of section §6.2.7.1 is taken to have occurred on January
1st, 2015.
===========================================================================
Seconded.
--
Sebastian Ramacher
Lucas Nussbaum
2014-12-01 13:37:30 UTC
Permalink
[ Cross post -vote, -project ; M-F-T: to -vote ]

Hi,

I am hereby formally submitting an alternative proposal, between
double-dashed lines below (formally it's an "amendment", but I don't
expect Stefano to accept it, as we discussed it before). I am also
calling for seconds (see below).

===========================================================================
The Constitution is amended as follows:

---------------------------------------------------------------------------
--- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
+++ constitution.2-R.txt 2014-11-24 10:24:42.109426386 +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. On January 1st of each year the term of any Committee member
+ who has served more than 54 months (4.5 years) and who is one
+ of the N most senior members automatically expires. 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

---------------------------------------------------------------------------
===========================================================================

Rationale
---------
First, I think that there is wide agreement that a more regular
turn-over among TC members would be a good thing. And both Stefano's
and this proposal aim at addressing this, by ensuring that at least 2
members of the TC are replaced every year.

However, too much turn-over, with more than 2 replacements at one point
of time, might have negative effects too. The TC might be temporarily
weakened by having more young members; replacing more than two members
at one point will cause less replacements later; it increases the
difficulty of finding new members.

The recent situation, with three TC members resigning, should not be
treated as exceptional in the context of this resolution. If it were to
happen again, I don't think that we should add one or two automatic
expirations to the three resignations.

This proposal differs from the original proposal by counting all
resignations and removals as part of the desirable "2 per year"
replacement rate, so that the total number of replacements does not
exceed two if only one or two younger members decide to resign.

This version of the proposal could even result in an internal TC
discussion: "OK, the Project wants two members to be replaced. Are there
members that feel like resigning now? Or should we just fallback to the
default of expiring the two most senior members?". I think that such a
discussion would be a healthy way for each TC member to evaluate its
status. The orignal proposal could have the detrimental effect of
pushing inactive/demotivated members to stay on the TC until their
expiration, to avoid causing additional churn.

Note that there are a few examples to compare the behaviour of the 2-S
and 2-R proposals in <***@xanadu.blop.info>.

Calling for seconds
-------------------
The DPL can propose general resolutions or GR amendments without seeking
seconds. I initially wanted to waive that right, to only have this
option on the ballot if there's sufficient interest from others, but the
Secretary declined (in <***@roeckx.be>). I am
therefore seeking seconds, and will withdraw this alternative proposal
if it does not reach the required number of seconds by December 10th.

Thanks
------
I would like to thank Stefano for organizing the discussion around this
GR, and preparing the various versions of the resolution and amendments.

Lucas
Sam Hartman
2014-12-01 15:39:37 UTC
Permalink
===========================================================================
The Constitution is amended as follows:

---------------------------------------------------------------------------
--- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
+++ constitution.2-R.txt 2014-11-24 10:24:42.109426386 +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. On January 1st of each year the term of any Committee member
+ who has served more than 54 months (4.5 years) and who is one
+ of the N most senior members automatically expires. 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

---------------------------------------------------------------------------
===========================================================================

Seconded.
Didier 'OdyX' Raboud
2014-12-01 17:24:18 UTC
Permalink
Post by Lucas Nussbaum
I am hereby formally submitting an alternative proposal, between
double-dashed lines below (formally it's an "amendment", but I don't
expect Stefano to accept it, as we discussed it before). I am also
calling for seconds (see below).
===========================================================================
---------------------------------------------------------------------------
--- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
+++ constitution.2-R.txt 2014-11-24 10:24:42.109426386 +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.
+ 1. On January 1st of each year the term of any Committee member
+ who has served more than 54 months (4.5 years) and who is one
+ of the N most senior members automatically expires. 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
---------------------------------------------------------------------------
===========================================================================
Seconded.

OdyX
Anthony Towns
2014-12-02 03:53:48 UTC
Permalink
The TC might be temporarily weakened by having more young members;
While this is conceivable, I don't think it's even remotely likely in
practice -- there is a huge pool of brilliant people in Debian to draw
from, and the work undertaken by the tech ctte is not so different from
everything else in Debian that ctte newbies will be starting from scratch.

Likewise, past members of the ctte can still stick their noses in
(wanted or not), and the ctte can always informally invite people to
help out either for the sake of the help itself, or as a way of helping
people get experience in the role -- much like the DPL, the secretary,
ftpmaster, release team and DSA already have helpers and assistants [0].

I'm all for planning against all contingencies, I just think it's
important to recognise that, for Debian, worries about appointing novices
to the technical ctte are at the far end of hypothetical. Even if only
to remind the next batch of recruits that they're expected to be hitting
the same [1] standards of good judgement and whatnot as current and past
ctte members from day one of joining.

Cheers,
aj

[0] Multiple teams in Debian have "assistant" positions, and none of
them are called "minions"? Really? No "leader's lackeys", "DSA goon
squad", or "ftpmaster flunkies"? Total missed opportunity.

[1] (or better)
--
To UNSUBSCRIBE, email to debian-vote-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@master.debian.org
Bernd Zeimetz
2014-12-02 19:50:31 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Post by Lucas Nussbaum
[ Cross post -vote, -project ; M-F-T: to -vote ]
Hi,
I am hereby formally submitting an alternative proposal, between
double-dashed lines below (formally it's an "amendment", but I don't expect
Stefano to accept it, as we discussed it before). I am also calling for
seconds (see below).
===========================================================================
---------------------------------------------------------------------------
- --- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
Post by Lucas Nussbaum
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
+ 1. On January 1st of each year the term of any Committee member +
who has served more than 54 months (4.5 years) and who is one +
of the N most senior members automatically expires. 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
---------------------------------------------------------------------------
===========================================================================
Post by Lucas Nussbaum
Rationale --------- First, I think that there is wide agreement that a more
regular turn-over among TC members would be a good thing. And both
Stefano's and this proposal aim at addressing this, by ensuring that at
least 2 members of the TC are replaced every year.
However, too much turn-over, with more than 2 replacements at one point of
time, might have negative effects too. The TC might be temporarily weakened
by having more young members; replacing more than two members at one point
will cause less replacements later; it increases the difficulty of finding
new members.
The recent situation, with three TC members resigning, should not be
treated as exceptional in the context of this resolution. If it were to
happen again, I don't think that we should add one or two automatic
expirations to the three resignations.
This proposal differs from the original proposal by counting all
resignations and removals as part of the desirable "2 per year" replacement
rate, so that the total number of replacements does not exceed two if only
one or two younger members decide to resign.
This version of the proposal could even result in an internal TC
discussion: "OK, the Project wants two members to be replaced. Are there
members that feel like resigning now? Or should we just fallback to the
default of expiring the two most senior members?". I think that such a
discussion would be a healthy way for each TC member to evaluate its
status. The orignal proposal could have the detrimental effect of pushing
inactive/demotivated members to stay on the TC until their expiration, to
avoid causing additional churn.
Note that there are a few examples to compare the behaviour of the 2-S and
Calling for seconds ------------------- The DPL can propose general
resolutions or GR amendments without seeking seconds. I initially wanted to
waive that right, to only have this option on the ballot if there's
sufficient interest from others, but the Secretary declined (in
will withdraw this alternative proposal if it does not reach the required
number of seconds by December 10th.
Thanks ------ I would like to thank Stefano for organizing the discussion
around this GR, and preparing the various versions of the resolution and
amendments.
Lucas
seconded

- --
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJUfhgHAAoJEOs2Fxpv+UNfdoIP/i0CLWgPvVVCGF7VNTjlNQJi
+GAau08SMP81GjE4gkj7ZHVhxpNDfFwj88j1rE3X7VEPqqQjAdj2U3Ugcs5wB3Kp
pr71queoEaBe0jaloONc48K2B/yey8tyt/OSW+A3ljLYjRY0KtvcZiIiNBNfDGF+
HDY2pstn38lkncsMHvInSh8RFbGwD0hmweAqxyEmXZ/1TnkchAKYe4n4AW3d7rJj
RUcXv8MxoLjrDyxYwjKE11s3yZNcN4rlYCo+6T1RiRNuM68NzcrscVRbI5HS17la
5uuyI0RKyFyrPxUhuiE3yGeNJVulKrNzI3+eGcnYPJ5tT9M+ySC1Wl9ap/JVmy9t
LqS95l8LKNYFIv68M0PG/9a5YZw5gOEFojMA3u5Fih1blYyU3MEt6txnSTdxOh76
vZrngVxcKW7R2EzgYmuwJpmc+JcIql7pKmak2PA/Ne4XilyaqReMvgtHWvocjFjx
uZfnic51rNirI214R9oGrp+y1yvYekJiYLcA4xh8doabi1RuaQe4IKmHX6kfxsnu
dsxZyRx6yZpZXl1tu5DOYFHigrScv2QYESYNiYE6AyQUqY3JZ1nRccPRHIlSFe1/
susyNU5dx0PhLtQUt2K5Hl2ylw7WagIC02R7HasFImkhO/eLeqV/x0he6tQBMeNZ
6vnty6XCbzyCpKgxBwBh
=yJNE
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-vote-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@bzed.de
Colin Tuckley
2014-12-02 20:05:45 UTC
Permalink
Post by Stefano Zacchiroli
===========================================================================
---------------------------------------------------------------------------
--- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
+++ constitution.2-R.txt 2014-11-24 10:24:42.109426386 +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.
+ 1. On January 1st of each year the term of any Committee member
+ who has served more than 54 months (4.5 years) and who is one
+ of the N most senior members automatically expires. 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
---------------------------------------------------------------------------
===========================================================================
Seconded
--
Colin Tuckley | +44(0)1223 830814 | PGP/GnuPG Key Id
Debian Developer | +44(0)7799 143369 | 0x38C9D903

A day without radiation is a day without sunshine.
Matthew Vernon
2014-12-05 08:38:18 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Post by Stefano Zacchiroli
===========================================================================
---------------------------------------------------------------------------
--- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
+++ constitution.2-R.txt 2014-11-24 10:24:42.109426386 +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.
+ 1. On January 1st of each year the term of any Committee member
+ who has served more than 54 months (4.5 years) and who is one
+ of the N most senior members automatically expires. 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
---------------------------------------------------------------------------
===========================================================================
Seconded.

Regards,

Matthew
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.9 <http://mailcrypt.sourceforge.net/>

iQIcBAEBCgAGBQJUgW70AAoJEBL00hyPamPIW3MP/2GAmlklhQvMN7EMwjh3e597
WhpfKgK4IrxyhpNMiX7hU1k8nAswTc7AGGtdKB+gEfwrK+jGTpPVCml8tHtNANmE
kbj1BY3ETXUeJjQoE4Zn+z7kr8tpGG/d1szb9Pun144ULc1gg3ZvZ714k0MxX0AH
9VWCWkxZpuVFt6TKnlv+gLvQU6nfs1r9HjfLr7i8prIjgdxNnEjABcLl6ZCfJUSv
qx5JYXTjgEvxKnrbTHGstkEgiP4Lm+qD6N1xxn9bveSmXtVoMF8z54JpBzlSfuEV
cSaW2K8dR5BbcTHR1ee5J5IETYVRrEIVbdlktJoPAPDsXL9ODDxTO+agKxGDerGn
K1JGV3ZBbqWqfPDZPHMZvYVGR0HAbUTKTT8ml0ITaVqlE3mBJCYNlIbfZBoDaa36
Qfd1/tZjVMziPuLTkQL6NSXRalCJvKfHPDFY2u+lhtgCZDCB+Ip7onGRDvnKRxtn
V5TOByBYEPQe/TM1H/OMINaMSrddWd7NXteWE7GttHHQZjRlNGQWTyMOAWIqA8Fi
H+JdiDyfM6knibliQ6B33cMm0jyLOKRNQEtoId+Gtt8LfkA3NJhvonBEk59xN8gM
SlFU4KKuDt09Kxx4LgQpEELUl8BEzNSmdxPh4XTd6jwzWG4GZO8kckdBh86JqniI
mvKEgibxK2t5PU9cc8J2
=beob
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-vote-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@aragorn.weathertop.principate.org.uk
Steve Langasek
2014-12-06 21:26:58 UTC
Permalink
Post by Lucas Nussbaum
Rationale
---------
First, I think that there is wide agreement that a more regular
turn-over among TC members would be a good thing. And both Stefano's
and this proposal aim at addressing this, by ensuring that at least 2
members of the TC are replaced every year.
However, too much turn-over, with more than 2 replacements at one point
of time, might have negative effects too. The TC might be temporarily
weakened by having more young members; replacing more than two members
at one point will cause less replacements later; it increases the
difficulty of finding new members.
The recent situation, with three TC members resigning, should not be
treated as exceptional in the context of this resolution. If it were to
happen again, I don't think that we should add one or two automatic
expirations to the three resignations.
This proposal differs from the original proposal by counting all
resignations and removals as part of the desirable "2 per year"
replacement rate, so that the total number of replacements does not
exceed two if only one or two younger members decide to resign.
This version of the proposal could even result in an internal TC
discussion: "OK, the Project wants two members to be replaced. Are there
members that feel like resigning now? Or should we just fallback to the
default of expiring the two most senior members?". I think that such a
discussion would be a healthy way for each TC member to evaluate its
status. The orignal proposal could have the detrimental effect of
pushing inactive/demotivated members to stay on the TC until their
expiration, to avoid causing additional churn.
The pathological corner case here appears to be that the longest-serving
member of the TC could evade the term limit indefinitely. A scenario that
assumes good faith on the part of all TC members is:

- The longest-serving member of the TC spends a minimum amount of time
engaging with TC issues. They vote on all resolutions, but don't spend
much time cross-examining the petitioners, nor do they participate in
resolution drafting. From their perspective, they are doing their duty
on the TC, but other members of the TC have a faster response time to
issues and therefore wind up doing the bulk of the work.
- The other members of the TC all are very passionate about their work on
the committee. (They've all been serving less than 3 years, so they have
a lot of passion for it.) They engage with every issue, spend several
hours each week on trying to make the TC serve the needs of the project
as best they know how. And once or twice each year, there is a big issue
that lands on the TC's desk, with social and technical issues intertwined
and that require a lot of energy to pick apart. Once a year, one of
these issues further devolves into a public flamewar where the ethics of
the TC members themselves are called into question. And as a result, two
members of the TC per year resign.
- With the minimum turnover requirement met, the longest-serving member
continues to serve as long as they are comfortable doing so.

Did you consider this corner case in your analysis? If you think this
corner case is less important than the risk of high turnover in the TC,
could you elaborate why you think this?

Thanks,
--
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 Developer http://www.debian.org/
***@ubuntu.com ***@debian.org
Lucas Nussbaum
2014-12-07 13:55:23 UTC
Permalink
Post by Steve Langasek
Post by Lucas Nussbaum
Rationale
---------
First, I think that there is wide agreement that a more regular
turn-over among TC members would be a good thing. And both Stefano's
and this proposal aim at addressing this, by ensuring that at least 2
members of the TC are replaced every year.
However, too much turn-over, with more than 2 replacements at one point
of time, might have negative effects too. The TC might be temporarily
weakened by having more young members; replacing more than two members
at one point will cause less replacements later; it increases the
difficulty of finding new members.
The recent situation, with three TC members resigning, should not be
treated as exceptional in the context of this resolution. If it were to
happen again, I don't think that we should add one or two automatic
expirations to the three resignations.
This proposal differs from the original proposal by counting all
resignations and removals as part of the desirable "2 per year"
replacement rate, so that the total number of replacements does not
exceed two if only one or two younger members decide to resign.
This version of the proposal could even result in an internal TC
discussion: "OK, the Project wants two members to be replaced. Are there
members that feel like resigning now? Or should we just fallback to the
default of expiring the two most senior members?". I think that such a
discussion would be a healthy way for each TC member to evaluate its
status. The orignal proposal could have the detrimental effect of
pushing inactive/demotivated members to stay on the TC until their
expiration, to avoid causing additional churn.
The pathological corner case here appears to be that the longest-serving
member of the TC could evade the term limit indefinitely. A scenario that
- The longest-serving member of the TC spends a minimum amount of time
engaging with TC issues. They vote on all resolutions, but don't spend
much time cross-examining the petitioners, nor do they participate in
resolution drafting. From their perspective, they are doing their duty
on the TC, but other members of the TC have a faster response time to
issues and therefore wind up doing the bulk of the work.
- The other members of the TC all are very passionate about their work on
the committee. (They've all been serving less than 3 years, so they have
a lot of passion for it.) They engage with every issue, spend several
hours each week on trying to make the TC serve the needs of the project
as best they know how. And once or twice each year, there is a big issue
that lands on the TC's desk, with social and technical issues intertwined
and that require a lot of energy to pick apart. Once a year, one of
these issues further devolves into a public flamewar where the ethics of
the TC members themselves are called into question. And as a result, two
members of the TC per year resign.
- With the minimum turnover requirement met, the longest-serving member
continues to serve as long as they are comfortable doing so.
Did you consider this corner case in your analysis? If you think this
corner case is less important than the risk of high turnover in the TC,
could you elaborate why you think this?
Your scenario describes a case where a member of the TC fullfills their
voting duties, but does not otherwise really participate in TC work.
This can happen, but I don't really see a correlation between this
happening, and the seniority of that specific TC member.

One could imagine a scenario where a recently-appointed TC member goes
semi-MIA very early, and still stay on the TC for 4 years. After all, in
Debian teams, people go MIA for various reasons, and this is not
correlated with their seniority in those particular teams.

I think that the root goal of this GR is to force more turn-over in the
TC, which is a very desirable thing. Doing that by removing the most
senior members every year is a reasonable default choice.

However, the goal of this GR is NOT to provide a mechanism to
automatically 'expire' poorly-performing TC members. I am not sure that
this is necessary: we already have a mechanism to remove members of the TC
(§6.2.5), which has already been used in situations where members of
the TC had become inactive. I doubt that we need more than that.

Also, if the version of the GR I proposed gets chosen, I hope
that the fact that resignations or removals can 'save' other members
from expiration will result in yearly discussions where the status and
activity level of each member gets reviewed, which could actually help
address the general problem of semi-MIA TC members.

Lucas
Steve McIntyre
2014-12-01 13:38:02 UTC
Permalink
Post by Stefano Zacchiroli
===========================================================================
---------------------------------------------------------------------------
--- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
+++ constitution.2-S.txt 2014-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.
+ 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, if this GR is passed after January 1st, 2015,
then the provision of section §6.2.7.1 is taken to have occurred on January
1st, 2015.
===========================================================================
Seconded.
--
Steve McIntyre, Cambridge, UK. ***@einval.com
Welcome my son, welcome to the machine.
Martin Zobel-Helas
2014-12-01 14:16:51 UTC
Permalink
Hi,
Post by Stefano Zacchiroli
[ Cross post -vote, -project ; M-F-T: to -vote.
For more background information on the development of this proposal,
see https://lists.debian.org/debian-vote/2014/11/msg00274.html ]
I'm hereby formally submitting the GR proposal included below between
dashed double lines, and calling for seconds. With respect to past
discussions on the -vote mailing list, this is the proposal code-named
"2-S"; see [1,2] for (the last known versions of) alternative proposals.
[1]: https://people.debian.org/~zack/gr-ctte-term-limit/
[2]: http://git.upsilon.cc/?p=text/gr-ctte-term-limit.git;a=tree
===========================================================================
---------------------------------------------------------------------------
--- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
+++ constitution.2-S.txt 2014-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.
+ 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
---------------------------------------------------------------------------
Seconded.
--
Martin Zobel-Helas <***@debian.org> Debian 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
Steve Langasek
2014-12-01 16:20:50 UTC
Permalink
Post by Stefano Zacchiroli
[ Cross post -vote, -project ; M-F-T: to -vote.
For more background information on the development of this proposal,
see https://lists.debian.org/debian-vote/2014/11/msg00274.html ]
I'm hereby formally submitting the GR proposal included below between
dashed double lines, and calling for seconds. With respect to past
discussions on the -vote mailing list, this is the proposal code-named
"2-S"; see [1,2] for (the last known versions of) alternative proposals.
[1]: https://people.debian.org/~zack/gr-ctte-term-limit/
[2]: http://git.upsilon.cc/?p=text/gr-ctte-term-limit.git;a=tree
===========================================================================
---------------------------------------------------------------------------
--- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
+++ constitution.2-S.txt 2014-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.
+ 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, if this GR is passed after January 1st, 2015,
then the provision of section §6.2.7.1 is taken to have occurred on January
1st, 2015.
===========================================================================
I'd like to thank Anthony Towns for introducing the term limit idea
several months ago [3] and for his help in polishing it through several
rounds of feedback on the -vote mailing list.
[3]: https://lists.debian.org/debian-project/2014/05/threads.html#00054
Seconded.

Thanks,
--
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 Developer http://www.debian.org/
***@ubuntu.com ***@debian.org
Scott Kitterman
2014-12-01 16:50:27 UTC
Permalink
Post by Stefano Zacchiroli
[ Cross post -vote, -project ; M-F-T: to -vote.
For more background information on the development of this proposal,
see https://lists.debian.org/debian-vote/2014/11/msg00274.html ]
I'm hereby formally submitting the GR proposal included below between
dashed double lines, and calling for seconds. With respect to past
discussions on the -vote mailing list, this is the proposal code-named
"2-S"; see [1,2] for (the last known versions of) alternative proposals.
[1]: https://people.debian.org/~zack/gr-ctte-term-limit/
[2]: http://git.upsilon.cc/?p=text/gr-ctte-term-limit.git;a=tree
===========================================================================
---------------------------------------------------------------------------
--- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
+++ constitution.2-S.txt 2014-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.
+ 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, if this GR is passed after January 1st, 2015,
then the provision of section §6.2.7.1 is taken to have occurred on January
1st, 2015.
===========================================================================
I'd like to thank Anthony Towns for introducing the term limit idea
several months ago [3] and for his help in polishing it through several
rounds of feedback on the -vote mailing list.
[3]: https://lists.debian.org/debian-project/2014/05/threads.html#00054
Cheers.
We discussed, and I thought there was consensus around, the idea that due to
the recent ctte churn, the transitional measure was no longer needed.

As an amendment, I propose the transitional measure be removed.

Scott K
Colin Tuckley
2014-12-01 16:59:53 UTC
Permalink
Post by Scott Kitterman
As an amendment, I propose the transitional measure be removed.
Why not support the amendment from Lucas instead which has more or less
the same effect?

Colin
--
Colin Tuckley | +44(0)1223 830814 | PGP/GnuPG Key Id
Debian Developer | +44(0)7799 143369 | 0x38C9D903

Even worse than raining cats and dogs is hailing taxi's.
Scott Kitterman
2014-12-01 17:06:40 UTC
Permalink
Post by Colin Tuckley
Post by Scott Kitterman
As an amendment, I propose the transitional measure be removed.
Why not support the amendment from Lucas instead which has more or less
the same effect?
It has the ~same effect right now, but behaves differently in the future. When
we vote, I think it would be a better choice if the transitional language
weren't there. I'd like to see all the options be as good as possible before
the vote.

Scott K
Philip Hands
2014-12-01 18:44:22 UTC
Permalink
Post by Scott Kitterman
Post by Colin Tuckley
Post by Scott Kitterman
As an amendment, I propose the transitional measure be removed.
Why not support the amendment from Lucas instead which has more or less
the same effect?
It has the ~same effect right now, but behaves differently in the future. When
we vote, I think it would be a better choice if the transitional language
weren't there. I'd like to see all the options be as good as possible before
the vote.
In the spirit of making things as good as possible before the vote, I'll
mention an idea that was kicked around earlier, and seemed to meet with
a fair amount of approval, just to see if people at large prefer it:

We could simply remove the sub-clauses about tie-breaking in 2.

There's no need for the situation ever to arise as long as we establish
a custom (which need not be defined in the constitution) that the DPL
always makes it clear that appointments to the TC happen in series.

Then there would never be any simultaneous appointments, so we'd never
need a tie-breaker. Even if a DPL forgets that, there will be an
official announcement, and we could just decide (or the DPL could later
declare) that the order the names appeared in the announcement was the
order of appointment. It's not as though it's vitally important, and if
people like the "age in the project" tie-breaker the DPL just needs to
appoint people in that order and that gives us the same effect.

We could perhaps replace part 2 of the proposals with something like:

2. Seniority in this context is a measure of how long a member has
served in their current term on the committee: whoever was appointed
first is considered to be the more senior.

I'm not proposing this as an amendment yet, but if it meets with general
approval, I will, and it it seems to upset anyone I'll just drop it.
I'd personally prefer the simplicity, but I'm unwilling to make a fuss
about it.

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
Lucas Nussbaum
2014-12-02 11:34:16 UTC
Permalink
Hi,
Post by Philip Hands
Post by Scott Kitterman
Post by Colin Tuckley
Post by Scott Kitterman
As an amendment, I propose the transitional measure be removed.
Why not support the amendment from Lucas instead which has more or less
the same effect?
It has the ~same effect right now, but behaves differently in the future. When
we vote, I think it would be a better choice if the transitional language
weren't there. I'd like to see all the options be as good as possible before
the vote.
In the spirit of making things as good as possible before the vote, I'll
mention an idea that was kicked around earlier, and seemed to meet with
We could simply remove the sub-clauses about tie-breaking in 2.
There's no need for the situation ever to arise as long as we establish
a custom (which need not be defined in the constitution) that the DPL
always makes it clear that appointments to the TC happen in series.
Then there would never be any simultaneous appointments, so we'd never
need a tie-breaker. Even if a DPL forgets that, there will be an
official announcement, and we could just decide (or the DPL could later
declare) that the order the names appeared in the announcement was the
order of appointment. It's not as though it's vitally important, and if
people like the "age in the project" tie-breaker the DPL just needs to
appoint people in that order and that gives us the same effect.
2. Seniority in this context is a measure of how long a member has
served in their current term on the committee: whoever was appointed
first is considered to be the more senior.
I'm not proposing this as an amendment yet, but if it meets with general
approval, I will, and it it seems to upset anyone I'll just drop it.
I'd personally prefer the simplicity, but I'm unwilling to make a fuss
about it.
Hi,

Of course, it would be fine for future appointments. But we have one
small problem with the current members:
Steve Langasek and Andreas Barth were appointed on the same date.
The TC recommended their addition in
https://lists.debian.org/debian-ctte/2005/12/msg00042.html
and the DPL confirmed their appointment in
https://lists.debian.org/debian-project/2006/01/msg00013.html

However:
- Steve would be more senior if we used the 'age in the project' rule
(DD since 2001-01-14, vs 2004-01-16 for Andreas)
- Steve was listed first in both the recommendation and the appointment
emails (contrary to the alphabetical order), so one could argue that
he was appointed first.

Lucas
Stefano Zacchiroli
2014-12-02 11:52:32 UTC
Permalink
Post by Lucas Nussbaum
Post by Philip Hands
In the spirit of making things as good as possible before the vote, I'll
mention an idea that was kicked around earlier, and seemed to meet with
We could simply remove the sub-clauses about tie-breaking in 2.
Of course, it would be fine for future appointments. But we have one
FWIW, I'm fine either way.

I did discuss the possibility of dropping the tie-breaking helper about
seniority in Debian with Phil. I'm fine with the principle and like the
resulting increase in simplicity. But I also discussed that possibility
with Lucas and he did prefer having some help from the Constitution to
avoid that we recur too often to the DPL tie breaking (as will happen in
the near future, apparently). Based on those discussions, I decided not
to remove the tie-breaking clause. But I don't particularly care either
way.

If there is consensus that simplicity is preferable and Lucas won't mind
dealing with the upcoming ties (in a way that is constitutionally
sound), I'll be happy to formally accept an amendment to that end.

Cheers.
--
Stefano Zacchiroli . . . . . . . ***@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 »
Lucas Nussbaum
2014-12-02 12:11:19 UTC
Permalink
Post by Stefano Zacchiroli
If there is consensus that simplicity is preferable and Lucas won't mind
dealing with the upcoming ties (in a way that is constitutionally
sound), I'll be happy to formally accept an amendment to that end.
I would find it a bit strange to deal with the vorlon/aba tie, but would
of course accept to do it if the resulting general resolution put that
responsibility in the DPL's hands.

How would you implement that? By expliciting making the DPL the
tie-breaking entity in that case, or by implicitely falling back to
5.1.4 "Make any decision for whom noone else has responsibility."?

If you make it explicit, it would be better to clarify if the DPL who
makes the decision is the DPL on January 1st, or on the following
December 31st. Which might result on more verbosity that the current
version, heh :-)

Lucas
Stefano Zacchiroli
2014-12-02 13:32:53 UTC
Permalink
Post by Lucas Nussbaum
How would you implement that? By expliciting making the DPL the
tie-breaking entity in that case, or by implicitely falling back to
5.1.4 "Make any decision for whom noone else has responsibility."?
I had in mind to explicitly state that the DPL will break ties. But I
neither have a text ready that implements that, nor I have seen
proposals by others that do that.

I didn't think of §5.1.4, but I agree that that would be a nice way out
of over-specification. It'd be wise to run that idea through the current
secretary before counting on it, though.
Post by Lucas Nussbaum
If you make it explicit, it would be better to clarify if the DPL who
makes the decision is the DPL on January 1st, or on the following
December 31st. Which might result on more verbosity that the current
version, heh :-)
Good point.

Cheers.
--
Stefano Zacchiroli . . . . . . . ***@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 »
Philip Hands
2014-12-02 13:43:39 UTC
Permalink
Post by Lucas Nussbaum
Post by Stefano Zacchiroli
If there is consensus that simplicity is preferable and Lucas won't mind
dealing with the upcoming ties (in a way that is constitutionally
sound), I'll be happy to formally accept an amendment to that end.
I would find it a bit strange to deal with the vorlon/aba tie, but would
of course accept to do it if the resulting general resolution put that
responsibility in the DPL's hands.
Didn't you just do it already ;-)
Post by Lucas Nussbaum
How would you implement that? By expliciting making the DPL the
tie-breaking entity in that case, or by implicitely falling back to
5.1.4 "Make any decision for whom noone else has responsibility."?
If you make it explicit, it would be better to clarify if the DPL who
makes the decision is the DPL on January 1st, or on the following
December 31st. Which might result on more verbosity that the current
version, heh :-)
Since it will only ever be relevant for the vorlon/aba tie, it seems
superfluous to put anything into the constitution.

If you insist on something explicit, I'd suggest:

3. Appointments are not simultaneous.

That way, if they might appear to be simultaneous, as in the aba/vorlon
case, it's up to someone (i.e. the DPL) to decide which one was done
first. I'd suggest that that isn't really needed, but seems harmless.

Conveniently, as you point out, the announcement order for vorlon/aba
coincides with the way the tie-breaker would have acted anyway, so we
can just say that vorlon was appointed moments before aba and all is
well, and the problem never needs to arise again, so no complicated
clauses required.

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
Hubert Chathi
2014-12-01 17:28:58 UTC
Permalink
Post by Scott Kitterman
Post by Stefano Zacchiroli
---------------------------------------------------------------------------
As a transitional measure, if this GR is passed after January 1st,
2015, then the provision of section §6.2.7.1 is taken to have
occurred on January 1st, 2015.
===========================================================================
I'd like to thank Anthony Towns for introducing the term limit idea
several months ago [3] and for his help in polishing it through
several rounds of feedback on the -vote mailing list.
https://lists.debian.org/debian-project/2014/05/threads.html#00054
Cheers.
We discussed, and I thought there was consensus around, the idea that
due to the recent ctte churn, the transitional measure was no longer
needed.
Due to that way things are worded, the transitional measure for this
proposal would cause TC memberships to start expiring December 31,
*2015* (i.e. next year), because the review period at the beginning of
the year causes expiries to happen at the end of that year, as opposed
to happening immediately.
--
Hubert Chathi <***@debian.org> -- Jabber: ***@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-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@desiato.home.uhoreg.ca
Scott Kitterman
2014-12-01 17:36:23 UTC
Permalink
Post by Hubert Chathi
Post by Scott Kitterman
Post by Stefano Zacchiroli
-------------------------------------------------------------------------
--
As a transitional measure, if this GR is passed after January 1st,
2015, then the provision of section §6.2.7.1 is taken to have
occurred on January 1st, 2015.
=========================================================================
==
I'd like to thank Anthony Towns for introducing the term limit idea
several months ago [3] and for his help in polishing it through
several rounds of feedback on the -vote mailing list.
https://lists.debian.org/debian-project/2014/05/threads.html#00054
Cheers.
We discussed, and I thought there was consensus around, the idea that
due to the recent ctte churn, the transitional measure was no longer
needed.
Due to that way things are worded, the transitional measure for this
proposal would cause TC memberships to start expiring December 31,
*2015* (i.e. next year), because the review period at the beginning of
the year causes expiries to happen at the end of that year, as opposed
to happening immediately.
I'm OK with that (i.e. not surprised). I think we've had enough turnover for
awhile without enforcing more. The point of term limits is to get new blood
onto the ctte. We'll have plenty of that shortly.

Scott K
Stefano Zacchiroli
2014-12-01 20:12:47 UTC
Permalink
Post by Scott Kitterman
We discussed, and I thought there was consensus around, the idea that
due to the recent ctte churn, the transitional measure was no longer
needed.
You recall correctly, but a simple removal of the transitional measure
would have very different effects on the various proposals. So what I
did instead is to try to uniform the *effects* of the various proposals,
so that the removal (or not) of transitional measures would result in
the same net result --- as much as permitted by the intrinsic
differences in the proposals, that is.

I've done that between draft #2 and draft #3 (as usual, based on my own
perception of consensus) and discussed the rationale behind my choices
when announcing the last draft [1]. It would have been useful to hear
about this back then.

[1]: https://lists.debian.org/debian-vote/2014/11/msg00274.html

But right now, I'm not sure to understand what your main concern is, and
I'd appreciate if you could elaborate a bit more. With the current
transitional measure, the proposal 2-S will de facto do nothing for a
full year. The first expiries will kick in only on January 1st, 2016.
That is the same that you would obtain with, say, proposal without any
transitional measure.

If you propose an amendment for 2-S ("my" proposal, the one that seems
to have received enough seconds now) to remove the transitional measure,
that will mean that the first expiries will happen on January 1st, 2017.
That's 2 years before seeing any effect whatsoever for the GR. Yes,
we've had some churn in the tech-ctte as of lately, but IMHO not that
much to justify such a delay.

Is that the goal you actually want to achieve?

Cheers.
--
Stefano Zacchiroli . . . . . . . ***@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 »
Stefano Zacchiroli
2014-12-01 20:24:12 UTC
Permalink
Post by Stefano Zacchiroli
But right now, I'm not sure to understand what your main concern is, and
I'd appreciate if you could elaborate a bit more. With the current
transitional measure, the proposal 2-S will de facto do nothing for a
full year. The first expiries will kick in only on January 1st, 2016.
That is the same that you would obtain with, say, proposal without any
^
Post by Stefano Zacchiroli
transitional measure. |
|
"2"

Sorry,
--
Stefano Zacchiroli . . . . . . . ***@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 »
Scott Kitterman
2014-12-01 20:43:44 UTC
Permalink
Post by Stefano Zacchiroli
Post by Scott Kitterman
We discussed, and I thought there was consensus around, the idea that
due to the recent ctte churn, the transitional measure was no longer
needed.
You recall correctly, but a simple removal of the transitional measure
would have very different effects on the various proposals. So what I
did instead is to try to uniform the *effects* of the various proposals,
so that the removal (or not) of transitional measures would result in
the same net result --- as much as permitted by the intrinsic
differences in the proposals, that is.
I've done that between draft #2 and draft #3 (as usual, based on my own
perception of consensus) and discussed the rationale behind my choices
when announcing the last draft [1]. It would have been useful to hear
about this back then.
[1]: https://lists.debian.org/debian-vote/2014/11/msg00274.html
But right now, I'm not sure to understand what your main concern is, and
I'd appreciate if you could elaborate a bit more. With the current
transitional measure, the proposal 2-S will de facto do nothing for a
full year. The first expiries will kick in only on January 1st, 2016.
That is the same that you would obtain with, say, proposal without any
transitional measure.
If you propose an amendment for 2-S ("my" proposal, the one that seems
to have received enough seconds now) to remove the transitional measure,
that will mean that the first expiries will happen on January 1st, 2017.
That's 2 years before seeing any effect whatsoever for the GR. Yes,
we've had some churn in the tech-ctte as of lately, but IMHO not that
much to justify such a delay.
Is that the goal you actually want to achieve?
Cheers.
Yes. The goal of the proposals is to turn over approximately two per year and
we've just lost three, so I think that's reasonable. It also puts an forced
retirements well past the recent turmoil and the Jessie release.

When making something as fundamental as constitutional change, I think it's
good to have it only affect things far enough in the future that people's
emotions about today are less likely to be wrapped up in it.

After quite some period of minimal turnover, we're already ahead of the game.

Scott K
Lucas Nussbaum
2014-12-02 07:38:47 UTC
Permalink
Post by Scott Kitterman
Yes. The goal of the proposals is to turn over approximately two per year and
we've just lost three, so I think that's reasonable.
Proposal 1 (Stefano's) puts a lot of emphasis on the removal of the two
most senior members. Imagine for a second that we had passed that
resolution at some point in 2013:
- on 2014-01-01, Ian and Bdale are set for expiry on 2014-12-31
- in 2014-11, Ian resigns, as well as Colin and Russ
- on 2014-12-31, Bdale's membership still expires

Is that the behaviour we want for the future? Maybe. But it results in
*at least two replacements per year* (more than two if there are
resignations or removals of members that are not among the two most
senior).

Lucas
Lucas Nussbaum
2014-12-01 20:27:40 UTC
Permalink
Post by Stefano Zacchiroli
But right now, I'm not sure to understand what your main concern is, and
I'd appreciate if you could elaborate a bit more. With the current
transitional measure, the proposal 2-S will de facto do nothing for a
full year. The first expiries will kick in only on January 1st, 2016.
^^^^^^^^^^^^^^^^^
December 31st, 2015, actually.

L.
Anthony Towns
2014-12-02 03:05:11 UTC
Permalink
Post by Scott Kitterman
Post by Stefano Zacchiroli
+ 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.
As a transitional measure, if this GR is passed after January 1st, 2015,
then the provision of section ?6.2.7.1 is taken to have occurred on January
1st, 2015.
We discussed, and I thought there was consensus around, the idea that due to
the recent ctte churn, the transitional measure was no longer needed.
The transitional measure here just makes the GR have the same effect
whether passed in late December or early January.

Timelines would be:

a) Stefano's proposal w/ transitional measure

Dec/Jan - GR passed
Jan 1st - Bdale and Steve's terms set to expire
...
Dec 31st - Bdale and Steve no longer members of the ctte

b) Stefano's roposal w/o transitional measure

Dec - GR passed
Jan 1st - Bdale and Steve's terms set to expire
...
Dec 31st - Bdale and Steve no longer members of the ctte

/or/

Jan - GR passed
[no expiries]
Jan 1st 2016 - Bdale and Steve's terms set to expire
...
Dec 31st 2016 - Bdale and Steve no longer members of the ctte

c) Lucas's proposal (assuming no additional resignations)

Dec - Colin resigns
Jan 1st - no expiries (there's been 3 resignations)
...
Jan 1st 2016 - Bdale and Steve's terms expire

/or/

Jan 1st - no expiries (there's been 2 resignations)
Jan - Colin resigns
...
Jan 1st 2016 - Bdale's term expires

(it doesn't make a difference whether Lucas's proposal passes before
or after New Year)

Summarising the possible outcomes in date order:

2015-12-31 Bdale, Steve term expiry (a, b.1)
2016-01-01 Bdale term expiry (c.1, c.2)
2016-01-01 Steve term expiry (c.1)

2016-12-31 Bdale, Steve term expiry (b.2)
2017-01-01 Steve term expiry (c.2)
Post by Scott Kitterman
As an amendment, I propose the transitional measure be removed.
ie, in summary, the effect this would have is that Bdale's and Steve's
terms would not expire until two years (and 30 days) from now, rather
than expiring at the end of next year; if and only if the GR doesn't
pass before the end of this month.

I think having the same effect independent of the GR passing in late
Dec or early Jan is a good thing, so if that's really the outcome that's
desired, replacing the transition statement with something like:

As a transitional measure, the implementation of section 6.2.7.1
will not begin until January 1st 2016.

would be better than removing it.

If it's just unclear, maybe adding "with the first expiry not occurring
until Dec 31st 2015" to the transition statement would help?

Cheers,
aj
--
To UNSUBSCRIBE, email to debian-vote-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@master.debian.org
Stefano Zacchiroli
2014-12-02 07:54:26 UTC
Permalink
Post by Anthony Towns
If it's just unclear, maybe adding "with the first expiry not
occurring until Dec 31st 2015" to the transition statement would help?
If there is a strong desire to clarify the language further, I wouldn't
mind formally accepting the above as an amendment.

Cheers.
--
Stefano Zacchiroli . . . . . . . ***@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 »
Lisandro Damián Nicanor Pérez Meyer
2014-12-01 22:30:25 UTC
Permalink
On Monday 01 December 2014 12:20:25 Stefano Zacchiroli wrote:
[snip]
Post by Stefano Zacchiroli
+ 6. If the Technical Committee and the Project Leader agree they may
remove or replace an existing member of the Technical Committee.
In the special case that a member is replaced, the new member "resets" it's
status or does him inherits the status of the one being replaced?

Yes, maybe I'm too picky here, but who knows...
--
9: Que es el "Explorador" de Windows
* El tipo que le roba las ideas a MacOs
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Tollef Fog Heen
2014-12-02 08:29:36 UTC
Permalink
]] Stefano Zacchiroli
Post by Stefano Zacchiroli
I'm hereby formally submitting the GR proposal included below between
dashed double lines, and calling for seconds. With respect to past
discussions on the -vote mailing list, this is the proposal code-named
"2-S"; see [1,2] for (the last known versions of) alternative proposals.
I like the term limit concept. I'm wondering if we should have a wider
proposal in which we just make the CTTE an elected body. I'm not sure
it's a good idea, but I'm also not sure if it's been discussed at all
(only having followed some of the -vote discussions around this from the
web archives).
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To UNSUBSCRIBE, email to debian-vote-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@aexonyam.err.no
Philip Hands
2014-12-02 09:46:01 UTC
Permalink
Post by Tollef Fog Heen
]] Stefano Zacchiroli
Post by Stefano Zacchiroli
I'm hereby formally submitting the GR proposal included below between
dashed double lines, and calling for seconds. With respect to past
discussions on the -vote mailing list, this is the proposal code-named
"2-S"; see [1,2] for (the last known versions of) alternative proposals.
I like the term limit concept. I'm wondering if we should have a wider
proposal in which we just make the CTTE an elected body. I'm not sure
it's a good idea, but I'm also not sure if it's been discussed at all
(only having followed some of the -vote discussions around this from the
web archives).
Wouldn't it have been great if the various factions around the systemd
issue had got the idea early on to try to stuff the committee with their
respective friends before the decision.

Personally I think there's more than enough voting going on as it is,
and adding reasons to have more regular votes will just promote the idea
(that is already rather hard to dissuade people of) that all one needs to
do is vote for a thing, and somehow it will magically do itself.

It does not strike me as obvious that popularity correlates to
competence. Also, it would not be helpful if members of the committee
were tempted to take the popular side of an argument, against their
better judgement, because they were coming to the end of their term, and
they would like to be reelected.

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
Stefano Zacchiroli
2014-12-02 09:59:01 UTC
Permalink
Post by Philip Hands
It does not strike me as obvious that popularity correlates to
competence. Also, it would not be helpful if members of the committee
were tempted to take the popular side of an argument, against their
better judgement, because they were coming to the end of their term,
and they would like to be reelected.
+1

All the usual arguments against elected "judges" in democracies apply
here, and I'm personally very much against the election of arbitration
bodies in general. If anything, the highly technical nature of a project
like Debian reinforces those arguments.

More importantly, it doesn't seem to me we're near having a concrete GR
proposal for electing ctte members. So IMO it would be best to
disentangle this discussion from the term limit GR proposal.

Cheers.
--
Stefano Zacchiroli . . . . . . . ***@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 »
Tollef Fog Heen
2014-12-02 21:29:41 UTC
Permalink
]] Philip Hands
Post by Philip Hands
Post by Tollef Fog Heen
]] Stefano Zacchiroli
Post by Stefano Zacchiroli
I'm hereby formally submitting the GR proposal included below between
dashed double lines, and calling for seconds. With respect to past
discussions on the -vote mailing list, this is the proposal code-named
"2-S"; see [1,2] for (the last known versions of) alternative proposals.
I like the term limit concept. I'm wondering if we should have a wider
proposal in which we just make the CTTE an elected body. I'm not sure
it's a good idea, but I'm also not sure if it's been discussed at all
(only having followed some of the -vote discussions around this from the
web archives).
Wouldn't it have been great if the various factions around the systemd
issue had got the idea early on to try to stuff the committee with their
respective friends before the decision.
If we assume four-year terms, that'd have been, at max, two members out
of the eight.
Post by Philip Hands
Personally I think there's more than enough voting going on as it is,
and adding reasons to have more regular votes will just promote the idea
(that is already rather hard to dissuade people of) that all one needs to
do is vote for a thing, and somehow it will magically do itself.
I'm not seeing people having that idea.
Post by Philip Hands
It does not strike me as obvious that popularity correlates to
competence. Also, it would not be helpful if members of the committee
were tempted to take the popular side of an argument, against their
better judgement, because they were coming to the end of their term, and
they would like to be reelected.
If that's the only reason, make it so people can sit for a maximum of
one term before being off the committee for a full term and that effect
more or less vanishes.

I'm not saying «We should absolutely have an elected TC», I'm saying
that I think it's something that's worth discussing.

As for Zack's point about this process being underway already: yes,
that's the point. If we want to change things about the TC, let's put
out a comprehensive proposal instead of changing one thing now and
another thing in six or twelve months.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To UNSUBSCRIBE, email to debian-vote-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@xoog.err.no
Bernd Zeimetz
2014-12-02 19:49:43 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Post by Stefano Zacchiroli
[ Cross post -vote, -project ; M-F-T: to -vote.
For more background information on the development of this proposal, see
https://lists.debian.org/debian-vote/2014/11/msg00274.html ]
I'm hereby formally submitting the GR proposal included below between
dashed double lines, and calling for seconds. With respect to past
discussions on the -vote mailing list, this is the proposal code-named
"2-S"; see [1,2] for (the last known versions of) alternative proposals.
http://git.upsilon.cc/?p=text/gr-ctte-term-limit.git;a=tree
===========================================================================
---------------------------------------------------------------------------
- --- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
Post by Stefano Zacchiroli
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
+ 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, if this GR is passed after January 1st, 2015,
then the provision of section §6.2.7.1 is taken to have occurred on
January 1st, 2015.
===========================================================================
I'd like to thank Anthony Towns for introducing the term limit idea
several months ago [3] and for his help in polishing it through several
rounds of feedback on the -vote mailing list.
[3]: https://lists.debian.org/debian-project/2014/05/threads.html#00054
Cheers.
seconded

- --
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJUfhfSAAoJEOs2Fxpv+UNfQjMQAJ8rNLdQeSP7WC6SslUQfCUA
mh6JlbQmdO8O0q9xpEKwqq7gkKqSWM6r09Dvh0VMHkEYEuo4qeG1C7nL7WyOVKew
k/XWM/kZnqOHStxZFgNnOJHzLhQBdnAVd1hnjFF5l/XYgLbOO0t/pyBaDKaFasDq
d7QgkAFs47GWGGBTSiXN+6Ny3c3k+C0kj4hbOqSy/Nw2+xDm7bmn3r+zz93iOK6u
86GLBWeQeIjuFRWh/0cUUswTUxT8wzdx52/QFboFd9D2qX4MTVcgwVM2Fx+5Ps2n
UBOT5Y63Lc8zf8o44obBFwPyfu/ANFAIpOhLzxlIMxyAdbr+i0zo3/GpuBqvhZcZ
tjzQIyQ572WY3MkCbXtvzxKNP8fJRSgEfQE+jJ09GuAvbE6gH1g7S9pmynTxMpy8
Cks1miHO0exZbB737fk7YflPFWeGaHsJ7fl8I9XeP0sen5YR8Vi1sO0l9hSSb/rU
s7Yx5I3vlhpHQ0HI05kZnSCQHgIr8wtJO3IimINTJ+pfIjpHLAxdBPEGRvor9GnL
CDq4+nfSfxcMP1nigfOs7+O9Z4rnpnYKsSDnDs7XCAUrUREqoeTJ8M+xqc5+3Md4
9RlPx19zkWMgPYcmmg/MiFKtegi4LvRGY0UjagN31lK4CQr24F3+Rs3bdxSpGPNb
mh5FB5LgBYPqVJKMyZmB
=aqWM
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-vote-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@bzed.de
Stefano Zacchiroli
2014-12-15 19:53:11 UTC
Permalink
Post by Stefano Zacchiroli
I'm hereby formally submitting the GR proposal included below between
dashed double lines, and calling for seconds.
AFAICT the discussion period has now elapsed, so I'm formally calling
for vote on the resolution and amendment texts quoted below.

As per discussions during the last general resolution: it would be nice
if the Secretary could send a draft ballot to -vote for comments, before
it is final.

Cheers.
Post by Stefano Zacchiroli
===========================================================================
---------------------------------------------------------------------------
--- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
+++ constitution.2-S.txt 2014-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.
+ 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, if this GR is passed after January 1st, 2015,
then the provision of section §6.2.7.1 is taken to have occurred on January
1st, 2015.
===========================================================================
===========================================================================
---------------------------------------------------------------------------
--- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
+++ constitution.2-R.txt 2014-11-24 10:24:42.109426386 +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.
+ 1. On January 1st of each year the term of any Committee member
+ who has served more than 54 months (4.5 years) and who is one
+ of the N most senior members automatically expires. 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
---------------------------------------------------------------------------
===========================================================================
--
Stefano Zacchiroli . . . . . . . ***@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 »
Kurt Roeckx
2014-12-16 09:41:50 UTC
Permalink
Post by Stefano Zacchiroli
Post by Stefano Zacchiroli
I'm hereby formally submitting the GR proposal included below between
dashed double lines, and calling for seconds.
AFAICT the discussion period has now elapsed, so I'm formally calling
for vote on the resolution and amendment texts quoted below.
As per discussions during the last general resolution: it would be nice
if the Secretary could send a draft ballot to -vote for comments, before
it is final.
It would also be nice that already suggested what the wording of
the options should be.


Kurt
--
To UNSUBSCRIBE, email to debian-vote-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@roeckx.be
Kurt Roeckx
2014-12-16 15:51:25 UTC
Permalink
Post by Kurt Roeckx
It would also be nice that already suggested what the wording of
the options should be.
I really can't come up with good wordings on the difference, so
I'm probably going with "option 1" and "option 2".


Kurt
--
To UNSUBSCRIBE, email to debian-vote-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@roeckx.be
Stefano Zacchiroli
2014-12-16 15:55:33 UTC
Permalink
Post by Kurt Roeckx
It would also be nice that already suggested what the wording of
the options should be.
How about:

1) replace the two oldest members every year
2) replace the two oldest members every year, excluding resignations

(Suggested by Lucas to me on IRC.)

Cheers.
--
Stefano Zacchiroli . . . . . . . ***@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 »
Jakub Wilk
2014-12-16 17:07:18 UTC
Permalink
Post by Stefano Zacchiroli
It would also be nice that already suggested what the wording of the
options should be.
1) replace the two oldest members every year
2) replace the two oldest members every year, excluding resignations
To me, it's more confusing that descriptive.
I've reread the proposals, and still can't tell which one is "excluding
resignations".

How about:

1) replace the two oldest members every year (liberal)
2) replace the two oldest members every year (conservative)
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-vote-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@jwilk.net
Sam Hartman
2014-12-16 17:21:27 UTC
Permalink
Post by Kurt Roeckx
It would also be nice that already suggested what the wording of
the options should be.
1) replace the two oldest members every year 2) replace the two
oldest members every year, excluding resignations
Jakub> To me, it's more confusing that descriptive. I've reread the
Jakub> proposals, and still can't tell which one is "excluding
Jakub> resignations".
2-r, but it's interesting that you find it confusing.

Jakub> How about:

Jakub> 1) replace the two oldest members every year (liberal) 2)
Jakub> replace the two oldest members every year (conservative)

I strongly prefer "option 1" and "option 2" to the above.

I preferred Stefano's wording over option 1 and 2, but I don't know how
to account for your confusion.
--
To UNSUBSCRIBE, email to debian-vote-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/0000014a541e6c12-ea9c6f07-2fc2-4b82-9464-c01b5f86a23d-***@email.amazonses.com
Lucas Nussbaum
2014-12-16 17:53:25 UTC
Permalink
Post by Sam Hartman
Post by Kurt Roeckx
It would also be nice that already suggested what the wording of
the options should be.
1) replace the two oldest members every year 2) replace the two
oldest members every year, excluding resignations
Jakub> To me, it's more confusing that descriptive. I've reread the
Jakub> proposals, and still can't tell which one is "excluding
Jakub> resignations".
2-r, but it's interesting that you find it confusing.
Jakub> 1) replace the two oldest members every year (liberal) 2)
Jakub> replace the two oldest members every year (conservative)
I strongly prefer "option 1" and "option 2" to the above.
I preferred Stefano's wording over option 1 and 2, but I don't know how
to account for your confusion.
What about having 'option 1' and 'option 2', and a neutral summary of
both proposals?

I believe that zack and I can just agree on such a summary.

First draft:
Both proposals aim at creating a regular turn-over of Technical
Committee members, by enforcing a term limit of four years.
The proposals differ in the way they address resignations or removals of
other TC members.
'Option 1' chooses to not consider them, which could result in three
(or more) TC members leaving the TC during the same year in such events.
'Option 2' chooses to substract the number of resignations/removals from
the required number of expirations. As a result, it is more likely that
only two members will be automatically expired (unless there are more
than two resignations). But it is also more likely that membership of
some TC members will exceed four years due to the resignations of other
TC members.

Lucas
--
To UNSUBSCRIBE, email to debian-vote-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@xanadu.blop.info
Stefano Zacchiroli
2014-12-16 20:02:51 UTC
Permalink
Looks quite good, but I'm unhappy about minor things.
I propose the following more balanced (IMO) version:

------------------------------------------------------------------------
Both proposals aim at creating a regular turn-over of Technical
Committee members, by enforcing a term limit of about four years. The
proposals differ in the way they react to resignations or removals of TC
members for reasons other than term limit.

- 'Option 1' chooses to leave regular term limits unaffected by
resignation/removals, which could result in more than 2 TC members
leaving the TC during the same year, in such events.

- 'Option 2' chooses to subtract the number of resignations/removals
from the required number of expiries, which could result in some TC
members exceeding the term limit, in such events.
------------------------------------------------------------------------

Cheers.
--
Stefano Zacchiroli . . . . . . . ***@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 »
Lucas Nussbaum
2014-12-16 20:31:11 UTC
Permalink
Post by Stefano Zacchiroli
Looks quite good, but I'm unhappy about minor things.
------------------------------------------------------------------------
Both proposals aim at creating a regular turn-over of Technical
Committee members, by enforcing a term limit of about four years. The
proposals differ in the way they react to resignations or removals of TC
members for reasons other than term limit.
- 'Option 1' chooses to leave regular term limits unaffected by
resignation/removals, which could result in more than 2 TC members
leaving the TC during the same year, in such events.
- 'Option 2' chooses to subtract the number of resignations/removals
from the required number of expiries, which could result in some TC
members exceeding the term limit, in such events.
------------------------------------------------------------------------
Full ACK. Thanks.

Lucas
Kurt Roeckx
2014-12-16 21:56:08 UTC
Permalink
Post by Lucas Nussbaum
Post by Stefano Zacchiroli
Looks quite good, but I'm unhappy about minor things.
------------------------------------------------------------------------
Both proposals aim at creating a regular turn-over of Technical
Committee members, by enforcing a term limit of about four years. The
proposals differ in the way they react to resignations or removals of TC
members for reasons other than term limit.
- 'Option 1' chooses to leave regular term limits unaffected by
resignation/removals, which could result in more than 2 TC members
leaving the TC during the same year, in such events.
- 'Option 2' chooses to subtract the number of resignations/removals
from the required number of expiries, which could result in some TC
members exceeding the term limit, in such events.
------------------------------------------------------------------------
Full ACK. Thanks.
Since it's a little late now, I'll start the vote tommorow evening
with that text. I'll send the complete ballot text some time
earlier.


Kurt
--
To UNSUBSCRIBE, email to debian-vote-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@roeckx.be
David Prévot
2014-12-17 01:35:25 UTC
Permalink
Hi,
Post by Stefano Zacchiroli
- 'Option 2' chooses to subtract the number of resignations/removals
from the required number of expiries, which could result in some TC
members exceeding the term limit, in such events.
Thanks. Do I understand correctly that option 2 could allow (one of) the
most senior members to stay in the technical committee as long as they
manage to push (one or) two of the other members to resignation every year?

Regards

David
Lucas Nussbaum
2014-12-17 04:28:45 UTC
Permalink
Post by David Prévot
Hi,
Post by Stefano Zacchiroli
- 'Option 2' chooses to subtract the number of resignations/removals
from the required number of expiries, which could result in some TC
members exceeding the term limit, in such events.
Thanks. Do I understand correctly that option 2 could allow (one of) the
most senior members to stay in the technical committee as long as they
manage to push (one or) two of the other members to resignation every year?
Yes.

However I think that such behaviour is already addressed by the
Constitution (§6.2.5).

Lucas

Loading...