Maximum term for tech ctte members

[Anthony Towns]

Hey,

Moving from -project. Reference:

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

Like I said, I'd rather provide a second than make a proposal, but at
debconf Stefano [0] said he'd appreciate some sample wording, so
here's what I came up with, based on where I was thinking when the
thread on -project sputtered out.

https://lists.debian.org/debian-project/2014/06/msg00026.html

--- constitution.cur.wml
+++ constitution.wml
@@ -507,11 +507,33 @@
appointment.</p>
</li>

+ <li>
+ <p>A Developer is not eligible to be appointed to the Technical Committee
+ if they have been a member within the previous 12 months.</p>
+ </li>
+
<li>
<p>If the Technical Committee and the Project Leader agree they
may remove or replace an existing member of the Technical
Committee.</p>
</li>
+
+ <li>
+ <p>Membership of the Technical Committee is automatically reviewed
+ on the 1st of January of each year. At this time, any member of the
+ Technical Committee who was most recently appointed 54 or more months
+ prior will ordinarily have their term automatically expire. However,
+ a member's term may be extended until the next review provided
+ there are at least two other members, each of whom who either (a)
+ are a current, longer serving member of Technical Committee, or (b)
+ resigned from the Technical Committee, or were removed or replaced
+ since the previous review.</p>
+
+ <p><cite>When the Committee is fully populated, it is expected this
+ will result in a turnover of 1 or 2 members each year, whether by
+ resignation or term expiry, while allowing senior members to stay
+ on if a junior member resigns.</cite></p>
+ </li>
</ol>

<h3>6.3. Procedure</h3>

Debian's birthday came and went, so Jan 1st seems the next most
obvious flag day. 54 months is 4.5 years; if you get appointed to the
ctte in January after someone else resigns or expires, you term won't
expire until January 4 years and 11 months away, whether the limit is
48 months or 59 months, so using the midpoint means expiries happen in
the range of 4.5-5.5 years which I think works out okay.

The above's as simple as I could make the phrasing. If someone else
can do better, please do :)

I know there's been some talk that maybe this is something the ctte
should just handle themselves; my view is that it's better to have
something that just takes care of it in a "good enough" way without
having to take specific actions (which can be missed or
procrastinated) or having the people involved having to think about it
in detail (whether that means bikeshedding the process or weight it
against "oh, but I have a couple more things I just have to do while
on the ctte").

Cheers,
aj

[0] I'm pretty sure it was Stefano, my memory of that night's possibly
kinda blurry...

[Sam Hartman]

I support this proposal, and if that was intented as a formal proposal
I'd probably second.

I'd also support:

* making this something the TC decides for themselves with your wording
as an initial condition

I do think rotation in bodies like the TC is really good both for the
members' personal development and for the project as a whole.
I have experience with this in a number of volunteer and standards
organizations and I think it works out well to have this sort of
rotation.

--Sam

[Stefano Zacchiroli]

Post by Anthony Towns
https://lists.debian.org/debian-project/2014/05/threads.html#00054
Like I said, I'd rather provide a second than make a proposal, but at
debconf Stefano [0] said he'd appreciate some sample wording, so
here's what I came up with, based on where I was thinking when the
thread on -project sputtered out.
[0] I'm pretty sure it was Stefano, my memory of that night's possibly
kinda blurry...

Yeah, that was me. Thanks a lot for this draft!

In general, it looks good to me and I'd be happy to second something

Post by Anthony Towns
+ <li>
+ <p>Membership of the Technical Committee is automatically reviewed
+ on the 1st of January of each year. At this time, any member of the
+ Technical Committee who was most recently appointed 54 or more months
+ prior will ordinarily have their term automatically expire. However,
+ a member's term may be extended until the next review provided
+ there are at least two other members, each of whom who either (a)
+ are a current, longer serving member of Technical Committee, or (b)
+ resigned from the Technical Committee, or were removed or replaced
+ since the previous review.</p>

FWIW, I found the original wording about this part from

https://lists.debian.org/debian-project/2014/06/msg00026.html

much easier to follow, but it might be a non-native speaker failure on
my part. Still, I hereby AOL your call for simpler phrasing here :)

Post by Anthony Towns
+ <p><cite>When the Committee is fully populated, it is expected this
+ will result in a turnover of 1 or 2 members each year, whether by
+ resignation or term expiry, while allowing senior members to stay
+ on if a junior member resigns.</cite></p>

Does this really belong to the constitutional text? It is good to
document the underlying principle/expectation of this change, but having
it in the GR text (but still not in the constitution itself) would be
good enough IMO.

Post by Anthony Towns
I know there's been some talk that maybe this is something the ctte
should just handle themselves; my view is that it's better to have
something that just takes care of it in a "good enough" way without
having to take specific actions (which can be missed or
procrastinated) or having the people involved having to think about it
in detail (whether that means bikeshedding the process or weight it
against "oh, but I have a couple more things I just have to do while
on the ctte").

Very much agreed. Nonetheless, before formally calling for seconds, it
would be nice to solicit comments from current tech-ctte members on the
latest and greatest draft of the GR text.

Thanks again,
Cheers.

[Don Armstrong]

I think rotation is a good idea. My main minor concern is that it
doesn't allow reappointing members to the CTTE if there are no
nominees whom the DPL and CTTE finds acceptable (or even if there are no
nominees at all).

Not allowing people to be reappointed if there are nominees and they're
just not acceptable may be a design goal, but not allowing reappointment
if there are no nominees does not.

Post by Anthony Towns
+ <li>
+ <p>A Developer is not eligible to be appointed to the Technical Committee
+ if they have been a member within the previous 12 months.</p>
+ </li>
+

[...]

Post by Anthony Towns
+
+ <li>
+ <p>Membership of the Technical Committee is automatically reviewed
+ on the 1st of January of each year. At this time, any member of the
+ Technical Committee who was most recently appointed 54 or more months
+ prior will ordinarily have their term automatically expire. However,
+ a member's term may be extended until the next review provided

Probably should be "will be extended" instead of "may be extended".

Post by Anthony Towns
+ there are at least two other members, each of whom who either (a)
+ are a current, longer serving member of Technical Committee, or (b)
+ resigned from the Technical Committee, or were removed or replaced
+ since the previous review.</p>
+
+ <p><cite>When the Committee is fully populated, it is expected this
+ will result in a turnover of 1 or 2 members each year, whether by
+ resignation or term expiry, while allowing senior members to stay
+ on if a junior member resigns.</cite></p>
+ </li>
</ol>

There was also some discussion of this during the CTTE meeting too:

http://meetbot.debian.net/debian-ctte/2014/debian-ctte.2014-07-31-16.58.log.html

Thanks for drafting this.
--
Don Armstrong http://www.donarmstrong.com

Miracles had become relative common-places since the advent of
entheogens; it now took very unusual circumstances to attract public
attention to sightings of supernatural entities. The latest miracle
had raised the ante on the supernatural: the Virgin Mary had
manifested herself to two children, a dog, and a Public Telepresence
Point.
-- Bruce Sterling, _Holy Fire_ p228

[Anthony Towns]

Post by Don Armstrong
I think rotation is a good idea. My main minor concern is that it
doesn't allow reappointing members to the CTTE if there are no
nominees whom the DPL and CTTE finds acceptable (or even if there are no
nominees at all).

In that event the ctte would have 6 people rather than 8 for 12 months,
at which point the two expirees could be reappointed. (Though another
2 might expire then, keeping it at 6 members)

Post by Don Armstrong
Not allowing people to be reappointed if there are nominees and they're
just not acceptable may be a design goal, but not allowing reappointment
if there are no nominees does not.

I could easily see "acceptability" being defined so that automatic
reappointment is a matter of course ("they're the most experienced
candidates!", "we know them and trust them!"). Avoiding reappointmnet
as a matter of course is a design goal.

For more generous definitions of acceptability ("really smart", "knows
lots about Debian", "willing to work in a team", "can deal well with
disagreements"), I don't think there's a shortage of potential candidates
in Debian, so on that score I don't think it's likely there won't be
sufficient acceptable nominees. YMMV, of course. (And maybe "willing
to put up with the conflict and BS that makes its way to the tech ctte"
would narrow the field more).

Cheers,
aj

[Bdale Garbee]

Post by Anthony Towns

Post by Don Armstrong
I think rotation is a good idea. My main minor concern is that it
doesn't allow reappointing members to the CTTE if there are no
nominees whom the DPL and CTTE finds acceptable (or even if there are no
nominees at all).

In that event the ctte would have 6 people rather than 8 for 12 months,
at which point the two expirees could be reappointed. (Though another
2 might expire then, keeping it at 6 members)

While not fatal, that doesn't seem particularly desirable.

Post by Anthony Towns
I don't think there's a shortage of potential candidates
in Debian, so on that score I don't think it's likely there won't be
sufficient acceptable nominees.

I agree.

Bdale

[Stefano Zacchiroli]

+ At this time, any member of the
+ Technical Committee who was most recently appointed 54 or more months
+ prior will ordinarily have their term automatically expire.

About this, I wonder if the text should specify in which order expiries
are to be processed, e.g., most recently appointed members last.

It seems to me that without a pre-defined ordering you might have
scenarios in which, in the absence of consensus about who should step
down, more members than desired will automatically expire. (Although
that might be by design.)

And yes, this might be seen as procedural paranoia, but the Constitution
is precisely the place where one wants to be paranoid.

Cheers.

[Anthony Towns]

Post by Stefano Zacchiroli
FWIW, I found the original wording about this part from
https://lists.debian.org/debian-project/2014/06/msg00026.html
much easier to follow, but it might be a non-native speaker failure on
my part.

Hmm, aren't a majority of Debian devs non-native English speakers anyway?

I was worried that the "two or more .. members have either X or Y"
phrasing might be ambiguous if there was one member who matched X and
a different member who matched Y.

Post by Stefano Zacchiroli

Post by Anthony Towns
+ <p><cite>When the Committee is fully populated, it is expected this
+ will result in a turnover of 1 or 2 members each year, whether by
+ resignation or term expiry, while allowing senior members to stay
+ on if a junior member resigns.</cite></p>

Does this really belong to the constitutional text?

"Text marked as a citation, such as this, is rationale and does not form
part of the constitution. It may be used only to aid interpretation in
cases of doubt." -- from appendix B in the constitution.

Post by Stefano Zacchiroli
It is good to
document the underlying principle/expectation of this change, but having
it in the GR text (but still not in the constitution itself) would be
good enough IMO.

Given the convoluted wording, I think it makes sense to have a bit of
an explanation in the text itself, and not just in the GR.

Post by Stefano Zacchiroli

Post by Anthony Towns
+ At this time, any member of the
+ Technical Committee who was most recently appointed 54 or more months
+ prior will ordinarily have their term automatically expire.

About this, I wonder if the text should specify in which order expiries
are to be processed, e.g., most recently appointed members last.

Take the current members, Ian, Bdale, Steve, Andi, Russ and Don are all
over five years and are in roughly that order of seniority iirc. On Jan 1st
2015, assuming no resignations, then:

- Andi: 2x current, longer serving members (Bdale and Ian)
- Bdale: 1x current, longer serving member (Ian) --> expired
- Colin: under 4.5 years
- Don: 4x current, longer serving members (Bdale, Ian, Steve, Andi)
- Ian: no longer serving members --> expired
- Russ: same as Don
- Steve: same as Andi

ie, I guess I was thinking that were all considered simultaneously so
ordering wasn't relevant.

There could be a minor cascade effect though I guess. If, say, Colin
resigns, you might get something like:

- 2014-10-23: Colin resigns to found forkubuntu.org
- 2015-01-01: Ian's term expires
- 2016-01-01: Bdale, Steve, Andi's terms expire
- 2017-01-01: Russ and Don's terms expire
- 2018-01-01: no one expires!
- 2019-01-01: Keith's term expires

because while there'd be three people's terms expiring in 2016, both
Andi and Steve would only have Bdale as more senior, since they were
appointed at the same time.

Oh, hey, since there's already math in the constitution, maybe it would
work to say something like:

Membership of the Technical Committee is automatically reviewed on
the 1st of January of each year. At this time, the terms of the N
most senior members automatically expire provided they were appointed
at least 4.5 years ago. 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 twelve
months.

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.

?

It's getting closer to source code than English at that point, but...

(I'm not sure the second paragraph there is actually needed; could
probably just rely on the secretary or the ctte itself to interpret
"seniority" and disambiguate "appointment" sensibly.)

(I believe the above would declare Steve senior to Andi, and Don senior
to Russ)

Cheers,
aj

[Stefano Zacchiroli]

Post by Anthony Towns
"Text marked as a citation, such as this, is rationale and does not form
part of the constitution. It may be used only to aid interpretation in
cases of doubt." -- from appendix B in the constitution.

OK, I didn't remember that (documented) convention. No objection then.

Post by Anthony Towns
Take the current members, Ian, Bdale, Steve, Andi, Russ and Don are all
over five years and are in roughly that order of seniority iirc. On Jan 1st

[...]

Post by Anthony Towns
ie, I guess I was thinking that were all considered simultaneously so
ordering wasn't relevant.

In fact, I don't mind simultaneity, I just wanted to be sure it wasn't
something that had been overlooked. I do observe that simultaneity might
result in more expiries than in scenarios in which you either define a
specific ordering, or members that would have been in the expiration set
voluntarily step down before January 1st.

Post by Anthony Towns
Oh, hey, since there's already math in the constitution, maybe it would
Membership of the Technical Committee is automatically reviewed on
the 1st of January of each year. At this time, the terms of the N
most senior members automatically expire provided they were appointed
at least 4.5 years ago. 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 twelve
months.
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.
?
It's getting closer to source code than English at that point, but...

In fact, I found the above mathematical formulation quite nice, and
clearer than the English wording. But it might be just me. Others?

Post by Anthony Towns
(I'm not sure the second paragraph there is actually needed; could
probably just rely on the secretary or the ctte itself to interpret
"seniority" and disambiguate "appointment" sensibly.)

Better safe than sorry, I'd rather keep it in. Even if it were only to
spare the Project a couple of threads on "hey, but what does it
*actually* mean to be ``more senior''", it would be worth it :-)

Cheers.

[Lucas Nussbaum]

Hi,

Post by Anthony Towns
Membership of the Technical Committee is automatically reviewed on
the 1st of January of each year. At this time, the terms of the N
most senior members automatically expire provided they were appointed
at least 4.5 years ago. 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 twelve
months.

Something just occurred to me.

Given the wide range of questions brought to the TC, it makes sense to
have some diversity in the TC in order to have expertise at hand
covering all the possible questions. Some members might be more familiar
with say, porting issues, packages inter-dependencies issues, low-level
stuff, desktop environments or might have a tendancy to approach
problems with a sysadmin POV, or with a developer POV.

When replacing two members at a time, it might be a bit difficult to
take that desirable balance into consideration. For example, if there are
three candidates A - B - C in the shortlist, and A and B are basically
clones in terms of profile, it would make sense to choose (A OR B) AND
C. If the final decision is made via a vote, it could require to vote on
pairs of candidates.

I don't know if this is a problem that can be ignored (because so far,
we have always found members with a wide range of expertise) or one that
should be addressed somehow. One way to address it would be to serialize
the process by re-evaluating membership every 6 months rather than
annually, and expiring at most one member at a time. This would add
overhead (more frequent renewal processes), but OTOH, once the TC gets
used to the fact that frequent renewals are needed, there are ways to
optimize the process (such as using the previous list of candidates as a
starting point, rather than starting from scratch each time).

Lucas

[Sam Hartman]

Lucas> Hi,

Post by Anthony Towns
Membership of the Technical Committee is automatically reviewed
on the 1st of January of each year. At this time, the terms of
the N most senior members automatically expire provided they were
appointed at least 4.5 years ago. 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 twelve months.

Lucas> Something just occurred to me.

Lucas> Given the wide range of questions brought to the TC, it makes
Lucas> sense to have some diversity in the TC in order to have
Lucas> expertise at hand covering all the possible questions. Some
Lucas> members might be more familiar with say, porting issues,
Lucas> packages inter-dependencies issues, low-level stuff, desktop
Lucas> environments or might have a tendancy to approach problems
Lucas> with a sysadmin POV, or with a developer POV.

Lucas> When replacing two members at a time, it might be a bit
Lucas> difficult to take that desirable balance into
Lucas> consideration. For example, if there are three candidates A -
Lucas> B - C in the shortlist, and A and B are basically clones in
Lucas> terms of profile, it would make sense to choose (A OR B) AND
Lucas> C. If the final decision is made via a vote, it could require
Lucas> to vote on pairs of candidates.

I've been on the IETF nomcom which does have exactly this problem.
They do vote on slates of candidates with ranked ballots similar to
Debian's ballots.
"works fine."

More generally, this procedure does not remove flexibility from how TC
members are appointed.
That process can be serialized say with two quick votes, or with slates,
or however the DPL and TC like.
Depending on the specifics it may be the case that one member is
technically appointed before another, although I'm sure any good rules
lawyer can give you 5-6 ways around that too.
I agree with your problem, but don't believe this proposal needs changes
to give the DPL and TC adequate mechanisms to address it.

[Charles Plessy]

Post by Lucas Nussbaum
When replacing two members at a time, it might be a bit difficult to
take that desirable balance into consideration. For example, if there are
three candidates A - B - C in the shortlist, and A and B are basically
clones in terms of profile, it would make sense to choose (A OR B) AND
C. If the final decision is made via a vote, it could require to vote on
pairs of candidates.

Hi Lucas,

actually, replacing two members at the time would give a good opportunity that
at least one of the members is not a western male that is is fully fluent
English speaker. While there is nothing wrong with that profile by itself, we
are missing something when all the members have this profile.

It is good to value technical excellence, but the work to be done in structures
like the technical comittee needs other skills as well. I think that somebody
who has a good capacity of synthesis, seeking advice, and understanding other
people's points of view would also be very qualified. Said differently, I
think that we give too much importance on who the TC members are, as compared
as what they can do. Let's remember that the TC has a long backlog, so
somebody who can learn and has time to do so will be more efficient than
somebody who knows but has no free time.

Rotating people by pairs would be a good opportunity to make it easier to
introduce diversity in the technical comittee.

(I am not suggesting to change the current proposal to ensure more rotations by
pairs).

Have a nice day,
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

[Svante Signell]

Hello,

Please don't forget to make the number of members in the CTTE an odd
number too, either by adding or removing one member. This was shortly
discussed especially in:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=+636783#180 onwards
and summarized in #210.

Thanks!

[Sam Hartman]

Hi.
This seems to have stalled and I'm disappointed to see that because I
think this is an important issue.

My recommendation is that you propose a resolution based on the comments
you received.


If a resolution isn't proposed within a week or so and there isn't some
nontrivial ongoing discussion at that time, I am likely to propose a
resolution based on your text. Obviously if between now and then
someone makes it clear why we should delay or something like that I'll
listen and consider the input.

My interest in only to make sure this issue is not dropped.

--Sam

[Neil McGovern]

Hi Sam,

Post by Sam Hartman
This seems to have stalled and I'm disappointed to see that because I
think this is an important issue.
My recommendation is that you propose a resolution based on the comments
you received.
nontrivial ongoing discussion at that time, I am likely to propose a
resolution based on your text. Obviously if between now and then
someone makes it clear why we should delay or something like that I'll
listen and consider the input.
My interest in only to make sure this issue is not dropped.

This was discussed at the last tech-ctte irc meeting, and it was agreed
to defer this until the current GR has quietened down. See
http://meetbot.debian.net/debian-ctte/2014/debian-ctte.2014-10-30-17.00.log.html

Neil
--

[Sam Hartman]

Neil> This was discussed at the last tech-ctte irc meeting, and it
Neil> was agreed to defer this until the current GR has quietened
Neil> down. See
Neil> http://meetbot.debian.net/debian-ctte/2014/debian-ctte.2014-10-30-17.00.log.html

Hi.
I'm really kind of frustrated and disappointed reading your message, and
I expect it's just a side effect of some wording choice here.
It sounds like what you're saying is that the TC has decided to defer
the discussions of TC term limits, but not to bring this forward or
explain their reasons on debian-vote.

I don't really think it's appropriate for the TC to decide what a
non-TC member (ajt) does about a discussion on debian-project,
especially when that discussion is *about* the TC.

If the TC as a whole or individual members about the TC have input to
the broader community, I think it's fine for them to share that.

However, I think that to avoid an appearance of a conflict of interest,
they should share that on debian-vote rather than simply having the
discussion die. Also, I'd feel a lot more comfortable if the TC or any
members with opinions made it clear they were giving input to the
project, not actually acting within some area where the TC has decision
making authority.

[Sune Vuorela]

Post by Sam Hartman
I'm really kind of frustrated and disappointed reading your message, and
I expect it's just a side effect of some wording choice here.
It sounds like what you're saying is that the TC has decided to defer
the discussions of TC term limits, but not to bring this forward or
explain their reasons on debian-vote.

I read the logs from the tech-ctte meeting, and my impression was that
- people in tech-ctte thinks that maximum terms are a good idea
- that they should push the thing forward (if no one else does)
- but they should wait with doing it until the current GR is over

I do think it is right to not have too many GR discussions running at
the same time to ensure that the project members have enough mental
bandwidth to figure out what to vote.

/Sune
- who would prefer if a max term wasn't needed by law, but the
tech-ctte members by convention stepped back after some periods of
time by themselves

[Sam Hartman]

Sune> I read the logs from the tech-ctte meeting, and my impression
Sune> was that - people in tech-ctte thinks that maximum terms are a
Sune> good idea - that they should push the thing forward (if no one
Sune> else does) - but they should wait with doing it until the
Sune> current GR is over

nod. My concern is one of process, not any strong disagreement with
opinions expressed.
Neil's message (and note he's also not a TC member) represented things
as a decision having been made in that TC meeting.
A TC meeting is a meeting where only the TC members are speaking.
That's not really the right forum for such a decision to be taken. It's
a fine forum to have a discussion, and it's great if those who
participated in that discussion bring that input to the larger group.

Personally, I agree that having multiple active discussion/second
periods on debian-vote is problematic. For myself, I think midway
through the voting period of the current GR will clear up this list
enough that starting to collect seconds on a new GR seems fine, but I'm
happy to delay beyond that if a significant number of people think
that's valuable.

[Don Armstrong]

Post by Sam Hartman
A TC meeting is a meeting where only the TC members are speaking.
That's not really the right forum for such a decision to be taken.

Just to echo Russ's comments, all that we really discussed was that as
the CTTE, we weren't going to press forward for this to happen while the
other GR was being actively discussed/voted on.

The CTTE has no power to stop anyone (including those on the CTTE) from
proposing, seconding, or discussing this amendment.

Post by Sam Hartman
Personally, I agree that having multiple active discussion/second
periods on debian-vote is problematic.

Right; that's what we seemed to agree on as well.

I think that we can all agree that we'd like a decision on this
amendment significantly before January 1st, which presumably means
having it formally proposed well before December 3rd.
--
Don Armstrong http://www.donarmstrong.com

I really wanted to talk to her.
I just couldn't find an algorithm that fit.
-- Peter Watts _Blindsight_ p294

[Sam Hartman]

Post by Sam Hartman
Personally, I agree that having multiple active discussion/second
periods on debian-vote is problematic.

Don> Right; that's what we seemed to agree on as well.

Don> I think that we can all agree that we'd like a decision on this
Don> amendment significantly before January 1st, which presumably
Don> means having it formally proposed well before December 3rd.

OK. So there is some time pressure.
I personally don't see any problem with that going on while the CFV for
the previous resolution is in place.
So, I think my comment about acting in a week or so seems about right.

I'd find arguments of the form "I personally would find it confusing/bad
to have both going on because ..." more compelling than arguments of
the form "it would generally be confusing/bad." What I'm saying is that
I'd be a lot more sympathetic to delay more than a week or so if people
come forward and say they personally would like to delay more than if
they say that some nebulous we/it would be a good idea to delay more.


--Sam

[Brian Gupta]

Post by Sam Hartman

Post by Sam Hartman
Personally, I agree that having multiple active discussion/second
periods on debian-vote is problematic.

Don> Right; that's what we seemed to agree on as well.
Don> I think that we can all agree that we'd like a decision on this
Don> amendment significantly before January 1st, which presumably
Don> means having it formally proposed well before December 3rd.
OK. So there is some time pressure.
I personally don't see any problem with that going on while the CFV for
the previous resolution is in place.
So, I think my comment about acting in a week or so seems about right.
I'd find arguments of the form "I personally would find it confusing/bad
to have both going on because ..." more compelling than arguments of
the form "it would generally be confusing/bad." What I'm saying is that
I'd be a lot more sympathetic to delay more than a week or so if people
come forward and say they personally would like to delay more than if
they say that some nebulous we/it would be a good idea to delay more.
--Sam

I'll say that I agree with the TC members who have spoken up.. I am a
subscriber to -vote, and am still trying to sort out how I'm going to
vote, but I am just burnt from all the email traffic.

Starting another GR process right now, would almost definitely push me
into that camp of DDs that tends to ignores voting.

IMHO, the lists definitely do need a cool down period, and am grateful
the TC members aren't pushing this right now.

-Brian

[Matthew Vernon]

Post by Brian Gupta

Post by Sam Hartman
I'd find arguments of the form "I personally would find it confusing/bad
to have both going on because ..." more compelling than arguments of
the form "it would generally be confusing/bad." What I'm saying is that
I'd be a lot more sympathetic to delay more than a week or so if people
come forward and say they personally would like to delay more than if
they say that some nebulous we/it would be a good idea to delay more.

I'll say that I agree with the TC members who have spoken up.. I am a
subscriber to -vote, and am still trying to sort out how I'm going to
vote, but I am just burnt from all the email traffic.

Me too. I'm afraid I'm spending too much time and effort tracking the
-vote list at the moment, and I'd like a break!

Regards,

Matthew
--
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org

[Ian Jackson]

Post by Sam Hartman
I'd find arguments of the form "I personally would find it confusing/bad
to have both going on because ..." more compelling than arguments of
the form "it would generally be confusing/bad." What I'm saying is that
I'd be a lot more sympathetic to delay more than a week or so if people
come forward and say they personally would like to delay more than if
they say that some nebulous we/it would be a good idea to delay more.

Firstly, I realise that I have an obvious bias here.

But, speaking entirely personally: I would like to engage properly
with the discussion on the details of the maximum term limit. But I
don't have the energy for that right now. I need to limit the
proportion of my Debian effort that goes into politics, for my own
sanity if for no other reason.

So just to be entirely clear: you are completely entitled to push on
with this now, and I understand why you want to. But you did ask for
my personal opinion, and my preference would be to wait.

Ian.

[Lucas Nussbaum]

Post by Sam Hartman

Post by Sam Hartman
Personally, I agree that having multiple active discussion/second
periods on debian-vote is problematic.

Don> Right; that's what we seemed to agree on as well.
Don> I think that we can all agree that we'd like a decision on this
Don> amendment significantly before January 1st, which presumably
Don> means having it formally proposed well before December 3rd.
OK. So there is some time pressure.

Of course, it would be better if this GR could be passed before January
1st, 2015. However, we could avoid having to rush things by simply
including a paragraph that says something such as:

If this GR proposal is passed after 2015-01-01, then the first
automatic review of membership of the Technical Committee happens
immediately.

With the current wording of a 4.5 years limit, this also doesn't change
anything for the future unless we delay it so much that there's no time
to appoint new members before 2015-07-01.

Lucas

[Neil McGovern]

Post by Sam Hartman
Sune> I read the logs from the tech-ctte meeting, and my impression
Sune> was that - people in tech-ctte thinks that maximum terms are a
Sune> good idea - that they should push the thing forward (if no one
Sune> else does) - but they should wait with doing it until the
Sune> current GR is over
nod. My concern is one of process, not any strong disagreement with
opinions expressed.
Neil's message (and note he's also not a TC member) represented things
as a decision having been made in that TC meeting.

Indeed, apologies, I was spending about 4 hours last night setting up
the current vote. The intention was to try and re-assure that it's not
been forgotton about!

Post by Sam Hartman
Personally, I agree that having multiple active discussion/second
periods on debian-vote is problematic. For myself, I think midway
through the voting period of the current GR will clear up this list
enough that starting to collect seconds on a new GR seems fine, but I'm
happy to delay beyond that if a significant number of people think
that's valuable.

I'd personally prefer it happening after this vote is concluded, but
will endevour to set up a GR if that's what happens.

Neil
--

[Richard Hartmann]

Post by Neil McGovern
I'd personally prefer it happening after this vote is concluded

Strong support. And given Lucas' proposed timed trigger, even more so.


Richard

[Julien Cristau]

Post by Neil McGovern
Hi Sam,

Post by Sam Hartman
This seems to have stalled and I'm disappointed to see that because I
think this is an important issue.
My recommendation is that you propose a resolution based on the comments
you received.
nontrivial ongoing discussion at that time, I am likely to propose a
resolution based on your text. Obviously if between now and then
someone makes it clear why we should delay or something like that I'll
listen and consider the input.
My interest in only to make sure this issue is not dropped.

This was discussed at the last tech-ctte irc meeting, and it was agreed
to defer this until the current GR has quietened down. See
http://meetbot.debian.net/debian-ctte/2014/debian-ctte.2014-10-30-17.00.log.html

I hope the project membership is not bound by tech-ctte irc meetings.

Cheers,
Julien

[Russ Allbery]

Post by Neil McGovern
This was discussed at the last tech-ctte irc meeting, and it was agreed
to defer this until the current GR has quietened down. See
http://meetbot.debian.net/debian-ctte/2014/debian-ctte.2014-10-30-17.00.log.html

I think we were only deferring pushing it forward ourselves. We obviously
have no authority to make that decision for anyone else.

I do think that two GRs running at the same time may be a bit much, and
that the discussion can get lost in the noise, so I'm in favor of waiting
until the current discussion has died down, but that's not some sort of
ruling or something we can request, just a personal preference stated
without my TC hat on.

[Stefano Zacchiroli]

Post by Sam Hartman
This seems to have stalled and I'm disappointed to see that because I
think this is an important issue.

To be frank, I find quite odd to call something in Debian "stalled" on
the basis that it didn't complete in 2 weeks. Especially considering
that:

(a) the issue has been arguably "stalled" for 6 months, revived at
DebConf, and advanced *a lot* precisely over the past few weeks
(thanks to Antony's work); and

(b) there are actionable items that have been discussed in this
thread. Working on them would be much more productive than
threatening to send out a call for seconds if nothing happens in
what I consider to be a very short time frame for Debian discussion
standards

(As an aside, giving some of the clumsiness of the Debian GR
process, I think it's never a good idea to send a GR call for
seconds before sending a complete draft to -vote and let it linger
for at least 1 week without having to accept any modification
whatsoever to the text, not even editorial ones. Been there, done
that. YMMV.)

That said, I'm interested in this GR, but I've had troubles finding time
to push the discussion forward. But I do agree with the apparent
consensus in the "timing" sub-thread: there are no good reasons for
having the term limit GR happen before the ongoing GR is over, and there
are good reasons not to do so.


In the meantime, here is where I think people could help with the
preparation work that needs to be completed before sending out a call
for seconds (if one wants to minimize the risk of fuckups, that is):

- me and Antony discussed various wording possibilities, including at
least two variants: a more mathematical one and one fully in prose.
I've stated my preference among the two, and asked others to comment
on that specific matter. No one did. If you are interested in this
topic, please do.

- I've mentioned before that it would be nice to *explicitly* address
the ctte and ask them what they think about the GR text. Of course it
would be inappropriate to offer the ctte a sort of "veto" power on
this GR, and I'm fully convinced they'd refuse such an offer. But this
GR has the potential of being confrontational and cause tension
between project members and tech-ctte members. I think that risk
should be minimized as much as feasible. A formal "what do you think
of this?" question to the tech-ctte is really the bare minimum that
the proposers of this GR should do.

This item is very actionable: go forward and ask the ctte, summarize
answers received, report back to -project. (Although it has a
dependency on the previous item.)

- I haven't mentioned it yet publicly (still due to ENOTIME), but I
still have mixed feelings about the provision that allows "younger"
ctte members to step down, inhibiting the expiry of "older" members.
I'm not necessarily against that, but I'm struggling to understanding
its rationale.

Antony: can you remind us what the rationale is?
Others: how do you feel about that?

Post by Sam Hartman
My interest in only to make sure this issue is not dropped.

That's great, because I care about it too! But I think that keeping
track of actionable items, reminding the community of them, and acting
on them is a much more effective way of ensuring progress in Debian than
ultimatums.

With many thanks for reviving this thread,
Cheers.

[Richard Hartmann]

Post by Stefano Zacchiroli
- I haven't mentioned it yet publicly (still due to ENOTIME), but I
still have mixed feelings about the provision that allows "younger"
ctte members to step down, inhibiting the expiry of "older" members.
I'm not necessarily against that, but I'm struggling to understanding
its rationale.
Others: how do you feel about that?

As there were not other replies to this: It seems weird and would need
a good rationale; plus some poking at potential corner cases.

Post by Stefano Zacchiroli
Antony: can you remind us what the rationale is?

Yes, please.



Richard

[Stefano Zacchiroli]

Post by Richard Hartmann

Post by Stefano Zacchiroli
still have mixed feelings about the provision that allows "younger"
ctte members to step down, inhibiting the expiry of "older" members.
I'm not necessarily against that, but I'm struggling to understanding
its rationale.
Antony: can you remind us what the rationale is?

Yes, please.

I've briefly discussed this off list with Sam Hartman, who proposed a
sensible rationale (although not necessarily the same Antony had in
mind). The rationale is avoiding suddenly under staffing the ctte too
much, making it non functional.

I understand the concern, but I think it could be addressed better. For
instance, one could say that expiries of "young" members inhibit the
expiry of an "old" member only if the latter expiry would reduce the
size of the ctte below 4 members (which is some sort of minimally viable
threshold for a function ctte, according to Constitution §6.2.1). In all
other situations, "old" member expiries proceed unaffected by how many
other members of the ctte stepped down in the previous year.

I think the above would be a good compromise, although I haven't took
the time to properly formalize it yet (so I might have overlooked nasty
corner cases).

Cheers.

[Bernd Zeimetz]

Post by Stefano Zacchiroli
I think the above would be a good compromise, although I haven't took
the time to properly formalize it yet (so I might have overlooked nasty
corner case
Cheers.

[Anthony Towns]

Post by Stefano Zacchiroli
I've briefly discussed this off list with Sam Hartman, who proposed a
sensible rationale (although not necessarily the same Antony had in
mind). The rationale is avoiding suddenly under staffing the ctte too
much, making it non functional.

Personally, I'm not terribly worried about the size of the ctte; I don't
think having just a couple of active members would be much less effective
than havin eight active members. (Though having only a couple of members
might significantly lower the odds of having any /active/ members)

Post by Stefano Zacchiroli
I understand the concern, but I think it could be addressed better. For
instance, one could say that expiries of "young" members inhibit the
expiry of an "old" member only if the latter expiry would reduce the
size of the ctte below 4 members (which is some sort of minimally viable
threshold for a function ctte, according to Constitution ?6.2.1). In all
other situations, "old" member expiries proceed unaffected by how many
other members of the ctte stepped down in the previous year.

That sounds plausible; I'm not convinced it's a problem worth solving
though. The downside of solving it is that it makes things more
complicated, and potentially introduces annoying loopholes or bad
incentives.

The only bad incentive I see off hand is that if there were only four
members then the oldest members would be discouraged from appointing new
members, because that could force them to expire and otherwise they could
stay on indefinitely. But that's counterbalanced by the clause letting the
DPL appoint two new ctte members without even having to consult the ctte.

But if the DPL's going to exercise that power anyway, why have any
exception at all for resignations? Just have the two oldest members
expire each year, provided they've served at least four years?

*oldest = longest serving

Cheers,
aj

[Anthony Towns]

Post by Stefano Zacchiroli
- I haven't mentioned it yet publicly (still due to ENOTIME), but I
still have mixed feelings about the provision that allows "younger"
ctte members to step down, inhibiting the expiry of "older" members.
I'm not necessarily against that, but I'm struggling to understanding
its rationale.
Antony: can you remind us what the rationale is?
Others: how do you feel about that?

When first posted, there was concern that continuity is a good thing and
having a large proportion of the ctte expire at the same time would be
a bad thing:

- Tollef: https://lists.debian.org/debian-project/2014/05/msg00057.html
- Stefano: https://lists.debian.org/debian-project/2014/05/msg00059.html
- Brian: https://lists.debian.org/debian-project/2014/05/msg00082.html

So based on Russ's comment of:

"The primary goal of this sort of system is to rotate fresh people
through the decision-making body."
- https://lists.debian.org/debian-project/2014/05/msg00055.html

I figured it might work to switch from the goal of "constant max term" to
"constant rate of change over":

"If we want the opportunity to appoint new members regularly, rather
than expire old members per se, we could just say that: "on July 1st,
the two longest serving ctte members' term expires" to end up with
(on average) four year terms... Probably needs some tweaking though
-- maybe it ought only apply if nobody's resigned in the previous 12
months or something.
- https://lists.debian.org/debian-project/2014/05/msg00061.html

They're both reasonable "principles" in my opinion; the only question
between them is how you balance continuity/disruption against rate
of progress. I don't personally have much of a preference either way.

Note that the "worst case" scenario would be something like:

- Keith, Colin, Russ, Don, Steve, Andi all quit from the tech ctte
effective Dec 30th
- Jan 1st rolls around
- Are Bdale and Ian removed?

The "can't rejoin for 12 months" rule would prevent any of them from being
immediately reappointed, and the tech ctte would have to be reconstituted
from all new members by the DPL at that point. Is it better to have some
continuity in the form of Bdale and Ian still being around?

(I don't really have a preference; maybe if they knew Bdale and Ian
would disappear too, that'd be enough to prevent a couple of other
members from quitting in the first place)

Cheers,
aj

[Thijs Kinkhorst]

Post by Stefano Zacchiroli
In the meantime, here is where I think people could help with the
preparation work that needs to be completed before sending out a call
- me and Antony discussed various wording possibilities, including at
least two variants: a more mathematical one and one fully in prose.
I've stated my preference among the two, and asked others to comment
on that specific matter. No one did. If you are interested in this
topic, please do.

For me, I can imagine why people didn't feel the need to reply to that
question. I really don't mind whether it's formulated in a mathematical
style or in English; it's the core substance that counts. Either
formulation is acceptable. Given the lack of replies, it seems that
there's not much strong preference either way with other -vote readers.

Since you seem to have an opinion about it, perhaps you just pick one?

Post by Stefano Zacchiroli
- I've mentioned before that it would be nice to *explicitly* address
the ctte and ask them what they think about the GR text. Of course it
would be inappropriate to offer the ctte a sort of "veto" power on
this GR, and I'm fully convinced they'd refuse such an offer. But this
GR has the potential of being confrontational and cause tension
between project members and tech-ctte members. I think that risk
should be minimized as much as feasible. A formal "what do you think
of this?" question to the tech-ctte is really the bare minimum that
the proposers of this GR should do.
This item is very actionable: go forward and ask the ctte, summarize
answers received, report back to -project. (Although it has a
dependency on the previous item.)

We're certain that committee members are subscribed to debian-vote,
members have participated in this thread, and the committee as a whole is
well aware of this discussion, as evidenced from their last meeting notes.
Therefore there has been (and still is) ample room for their input on the
proposal and we need not worry that they are obvlivious of it going on.
Requiring some extra round of querying and summarising therefore just
seems like a request for busywork.


Cheers,
This

[Lucas Nussbaum]

Post by Stefano Zacchiroli
- me and Antony discussed various wording possibilities, including at
least two variants: a more mathematical one and one fully in prose.
I've stated my preference among the two, and asked others to comment
on that specific matter. No one did. If you are interested in this
topic, please do.

FTR, I have a preference for the mathematical one, as I find it easier to
understand.

Lucas

[Anthony Towns]

Hey Sam,

Post by Sam Hartman
This seems to have stalled and I'm disappointed to see that because I
think this is an important issue.
My recommendation is that you propose a resolution based on the comments
you received.

I haven't been particularly active in Debian over the past few years,
and my feeling is that it's better to leave proposing resolutions
(particularly constitutional changes!) to people who have been. So, as
I've said before, happy to offer a second, but I don't expect to make
an actual proposal.

Cheers,
aj

[Sam Hartman]

Andreas> Hello Anthony Towns!
Andreas> On Tue, Nov 04, 2014 at 03:10:51PM +1000, Anthony Towns wrote:
Andreas> [...]

Post by Anthony Towns
I haven't been particularly active in Debian over the past few
years, and my feeling is that it's better to leave proposing
resolutions (particularly constitutional changes!) to people who
have been. So, as I've said before, happy to offer a second, but
I don't expect to make an actual proposal.

Andreas> The sooner the better IMHO. I find it very weird that
Andreas> tech-ctte members apparently recognize the need but still
Andreas> want to be force-rotated rather then voluntarily doing
Andreas> it. On the other hand, I guess you don't end up in a
Andreas> committee unless you absolutely love procedural formalia
Andreas> and want to see as much as possible of it.

I think with Lucas's proposal to handle the find round of term
expirations immediately if we don't get this approved by January 1,
there's a lot less time pressure.

Also, I think Stefano did a great job of summarizing the things he
thinks needs to be done.

Stefano, I'm happy to sign up to put together a version of the proposal
with the mathematical formulation and a paragraph about January 1 2015
for people to think about.
I may get it out next week, but will definitely do it the week after if
not.
I'd be delighted if after reviewing and discussion you wanted to
formally propose a resolution so I don't have to:-) Seconding and
voting would be lots easier.

[Andreas Henriksson]

Hello Anthony Towns!

On Tue, Nov 04, 2014 at 03:10:51PM +1000, Anthony Towns wrote:
[...]

Post by Anthony Towns
I haven't been particularly active in Debian over the past few years,
and my feeling is that it's better to leave proposing resolutions
(particularly constitutional changes!) to people who have been. So, as
I've said before, happy to offer a second, but I don't expect to make
an actual proposal.

I have been quite active the past few years, and I do think your proposal
is good and needed. I'm not very interested in the procedural formalia
though, so if not for yourself could you please push this forward and
propose it on my behalf?
(You seem to have the procedure nailed down and you also seem to be able
to come up with a more suitable proposal text then I would.)

The sooner the better IMHO. I find it very weird that tech-ctte members
apparently recognize the need but still want to be force-rotated rather
then voluntarily doing it. On the other hand, I guess you don't end
up in a committee unless you absolutely love procedural formalia and
want to see as much as possible of it.

Thanks for working on the initial proposal anyway. Much appreciated!

Regards,
Andreas Henriksson

[Stefano Zacchiroli]

Post by Andreas Henriksson
The sooner the better IMHO. I find it very weird that tech-ctte members
apparently recognize the need but still want to be force-rotated rather
then voluntarily doing it. On the other hand, I guess you don't end
up in a committee unless you absolutely love procedural formalia and
want to see as much as possible of it.

I find this explanation to be absolutely backward. There are good
reasons for *not* wanting a maximum term limit to be just folklore. If
it is something important (and I think it is), then it should really be
carved in the stone of a foundation document. That way you avoid the
risk of people trying to game the system and, more importantly, the
social awkwardness of having to deal with that situation, no matter how
unlikely that is to happen. As I've mentioned before: a Constitution is
precisely the place where one wants to be paranoid.

I wouldn't be surprised to find out that several tech-ctte members think
that such a just rule is so important that it should really be carved in
the Constitution, instead of wanting to have it that way just for the
sake of formalities. Either way, I wouldn't put any motivation in their
mouths without asking first.

Cheers.

[Andreas Henriksson]

Hello Stefano Zacchiroli.

Post by Stefano Zacchiroli

Post by Andreas Henriksson
The sooner the better IMHO. I find it very weird that tech-ctte members
apparently recognize the need but still want to be force-rotated rather
then voluntarily doing it. On the other hand, I guess you don't end
up in a committee unless you absolutely love procedural formalia and
want to see as much as possible of it.

I find this explanation to be absolutely backward. There are good
reasons for *not* wanting a maximum term limit to be just folklore.

Without this made up second part of the sentance, it means nothing to me:

... and if we rotate members now, it will forever remain folklore.

(Which I ofcourse don't think is true.)

Post by Stefano Zacchiroli
If it is something important (and I think it is), then it should really be
carved in the stone of a foundation document. That way you avoid the
risk of people trying to game the system and, more importantly, the
social awkwardness of having to deal with that situation, no matter how
unlikely that is to happen. As I've mentioned before: a Constitution is
precisely the place where one wants to be paranoid.

I don't see any obstacles for improving the constitution at any time.
I also don't see how the constitution not yet being the perfect document
should be allowed to be an obstacle for just doing the right thing.

Post by Stefano Zacchiroli
I wouldn't be surprised to find out that several tech-ctte members think
that such a just rule is so important that it should really be carved in
the Constitution, instead of wanting to have it that way just for the
sake of formalities. Either way, I wouldn't put any motivation in their
mouths without asking first.

This last part is key in summarising how I interpret your reasoning:

- There is a consensus for the basic principle of tech-ctte membership
rotation.
- We (for some value of we) do not trust future members of tech-ctte to
always follow this principle.
- We (FSVO we) do not trust future members of tech-ctte to formalise the
basic principle.
- Therefor we must allow existing tech-ctte members to continue
violating the basic principle so they can enforce it against future
members.

Seems like a whole lot of distrust to me. Would be very refreshening
to see someone take a leap of faith just to prove that we're not
building the entire project based on distrust (and constitutional
documents to deal with that distrust).

As you probably understand, you haven't convinced me yet.... but to
avoid making this yet another unneccesary long discussion we should
probably just agree to disagree here. Neither of this was my primary
motivation for my initial mail. I just wanted to express my support
of Anthony Towns to go ahead with his proposal despite his very
honorable attempts at letting more active contributors propose the
changes we want to see in the project. Just couldn't resist to also
voice my opinion on a related matter, which might have been good
if I managed to resist.

Regards,
Andreas Henriksson

[Stefano Zacchiroli]

Post by Andreas Henriksson

Post by Stefano Zacchiroli
I wouldn't be surprised to find out that several tech-ctte members think
that such a just rule is so important that it should really be carved in
the Constitution, instead of wanting to have it that way just for the
sake of formalities. Either way, I wouldn't put any motivation in their
mouths without asking first.

- There is a consensus for the basic principle of tech-ctte membership
rotation.
- We (for some value of we) do not trust future members of tech-ctte to
always follow this principle.
- We (FSVO we) do not trust future members of tech-ctte to formalise the
basic principle.
- Therefor we must allow existing tech-ctte members to continue
violating the basic principle so they can enforce it against future
members.

I disagree yours is a fair summary of what I wrote. Either way, it is
not a fair summary of what I think. Therefore I don't think your
conclusion on my alleged mistrust on (any number of) tech-ctte members
is warranted.

Post by Andreas Henriksson
As you probably understand, you haven't convinced me yet.... but to
avoid making this yet another unneccesary long discussion we should
probably just agree to disagree here.

Indeed, let's do that :)

Cheers.

[Russ Allbery]

Post by Andreas Henriksson
- There is a consensus for the basic principle of tech-ctte membership
rotation.
- We (for some value of we) do not trust future members of tech-ctte to
always follow this principle.

As a TC member, I would like there to be some structure to the job,
because there's never a good time to step down, there's always something
in progress, etc. If there is a schedule that everyone has agreed to,
then it's reliable and predictable and straightforward.

If we don't end up getting that into the constitution, I will set a
schedule for my own involvement in the TC independently. But I think we
will, institutionally, benefit from having there be a commonly-agreed-on
schedule that we all use, including people who are considering joining.

Post by Andreas Henriksson
- We (FSVO we) do not trust future members of tech-ctte to formalise the
basic principle.

I really don't think it's a matter of trust so much that some things do
work better with a process agreed-on in advance, even when everyone has
the same goals and same desires.

The TC could indeed go off and come up with a process on its own, but why
not involve the project as a whole? Other people have had really good
ideas about what that project would look like.

[Stefano Zacchiroli]

Here is a draft GR text which builds on Anthony's work and implements
some of the aspects discussed in this thread. See below for
comments/rationales and the attachment for a wdiff.

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

---------------------------------------------------------------------------
--- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
+++ constitution.txt.new 2014-11-18 11:12:13.665659796 +0100
@@ -299,8 +299,28 @@
Project Leader may appoint new member(s) until the number of
members reaches 6, at intervals of at least one week per
appointment.
- 5. If the Technical Committee and the Project Leader agree they may
+ 5. A Developer is not eligible to be appointed to the Technical Committee
+ if they have been a member within the previous 12 months.
+ 6. If the Technical Committee and the Project Leader agree they may
remove or replace an existing member of the Technical Committee.
+ 7. Term limit:
+ 1. Membership of the Technical Committee is automatically
+ reviewed on the 1st of January of each year. At this time, the
+ terms of the 2 most senior members automatically expire
+ provided they were appointed at least 54 months ago.
+ 2. A member of the Technical Committee is said to be more senior
+ than another if they were appointed earlier, or were appointed
+ at the same time and have been a member of the Debian Project
+ longer. In the event that a member has been appointed more
+ than once, only the most recent appointment is relevant.
+ 3. At each review round expiries are processed sequentially, most
+ senior member first.
+ 4. No expiry can reduce the size of the Technical Committee to
+ 3 members or fewer. (It might thus happen that up to 4 members of
+ the Technical Committee remain in charge with more than 54 months
+ of seniority on January 1st. In that case, up to 2 of them will
+ expire at the next review round, provided that the committee has
+ been further staffed.)

6.3. Procedure

---------------------------------------------------------------------------

As a transitional measure, if this GR proposal is passed after 2015-01-01,
then the first automatic review of membership of the Technical Committee
happens immediately.
==============================================================================

- The main change wrt the original text by Anthony is that the provision
of not expiring senior members if less-senior ones have resigned is
gone. In its stead, there is a provision that inhibits expiries from
reducing the CTTE size below 4 members. As a result, the math part
with N and R is gone, IMHO simplifying the text.

My understanding of [1] is that we might find consensus (at least
among the people who have shown interest in drafting this proposal) on
the above text. Please correct me if I'm wrong.

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

Specifically, I do agree with the potentially weird incentives that
reaching the threshold of 4 members will induce. But I also agree with
the fact that DPL's power to restaff the ctte until it reaches 6
members (basically by him/herself) is enough to make the problem moot.

- I've added point (3) about the order in which expiries are processed
to disambiguate the case in which the ctte is composed by 5 members
with 2 senior ones. In that case we want one expiry to be acted upon
but not the other (I think).

- I've integrated Lucas suggestion about the transitional measure in
case we get this approved after January 1st.

I welcome comments, reviews, etc.

Wording simplifications and fixes for my en_IT idiosyncrasies are
particularly welcome.

Cheers.

[Anthony Towns]

Post by Stefano Zacchiroli
Here is a draft GR text which builds on Anthony's work and implements
some of the aspects discussed in this thread. See below for
comments/rationales and the attachment for a wdiff.

Looks good to me.​

Post by Stefano Zacchiroli
+ 3. At each review round expiries are processed sequentially, most
+ senior member first.
+ 4. No expiry can reduce the size of the Technical Committee to
+ 3 members or fewer. (It might thus happen that up to 4 members of
+ the Technical Committee remain in charge with more than 54 months
+ of seniority on January 1st. In that case, up to 2 of them will
+ expire at the next review round, provided that the committee has
+ been further staffed.)

I guess ​I'd still be inclined to drop both of those​; I don't see much
difference between (letting the membership drop to 5 or 4 at which point
DPL can increase it without the ctte's cooperation) and (letting the
membership drop to 5, 4, 3, 2, 1 or 0 at which point the DPL can increase
it without the ctte's cooperation), and making it another two paragraphs
simpler would be a win.

Wording simplifications and fixes for my en_IT idiosyncrasies are

Post by Stefano Zacchiroli
particularly welcome.

Hmm. Wording seemed fine to me. Suggestions anyway:

​"not eligible to be (re)appointed" perhaps?

"provided /they/ were appointed" reads to me like it might mean that if
only one of them was appointed that long ago, maybe neither of them expire.
I'm not sure I can think of anything better; maybe something like "At this
time, the terms of members who were appointed at least 54 months ago
automatically expire. Expiry occurs in order of seniority, and is limited
to at most the two most senior members." would be better? But I'm not sure
this is worth fixing.

​Maybe ​"(It might thus happen that at the start of January 1st the
Technical Committee is composed of just 4 members​, all of whom were
appointed more than 54 months ago. If so, no one's term will expire.
However if additional members are appointed in the next year, then the 2
most senior members' terms will expire at the next review round.)" would be
better? I'm not sure if this needs explaining though?

I wonder if "four and a half years (54 months)" would be better.

​Cheers,
aj​

[Stefano Zacchiroli]

Post by Anthony Towns
Looks good to me.​

Thanks for your feedback. New draft attached implementing (almost all)
the changes you suggested. The GR text is now also available at

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

which also contains BUGS{_archive,} files listing fixed and pending
issues.

Post by Anthony Towns

Post by Stefano Zacchiroli
+ 3. At each review round expiries are processed sequentially, most
+ senior member first.
+ 4. No expiry can reduce the size of the Technical Committee to
+ 3 members or fewer. (It might thus happen that up to 4

[...]

Post by Anthony Towns
I guess ​I'd still be inclined to drop both of those​; I don't see much
difference between (letting the membership drop to 5 or 4 at which point
DPL can increase it without the ctte's cooperation) and (letting the
membership drop to 5, 4, 3, 2, 1 or 0 at which point the DPL can increase
it without the ctte's cooperation), and making it another two paragraphs
simpler would be a win.
Wording simplifications and fixes for my en_IT idiosyncrasies are

I'm convinced by your arguments. After all, the committee can become
understaffed for reasons other than expiries, and the Constitution
already has a mechanism for dealing with that: more liberal ctte
appointment by the DPL alone. (And Occam's razor rocks anyhow.)

Fixed in the new draft attached.

I note that this might be seen as flying a little bit in the face of
continuity---which we have discussed before in this thread. But that
theoretical problem is balanced by the fact that we limit expiries to 2
per year. That should be enough to induce a fairly regular turn-over.

Post by Anthony Towns
​"not eligible to be (re)appointed" perhaps?

Fixed.

(For those who care about uniformity: yes the "(re)appointed" syntax was
already used elsewhere in the Constitution.)

Post by Anthony Towns
"provided /they/ were appointed" reads to me like it might mean that if
only one of them was appointed that long ago, maybe neither of them expire.
I'm not sure I can think of anything better; maybe something like "At this
time, the terms of members who were appointed at least 54 months ago
automatically expire. Expiry occurs in order of seniority, and is limited
to at most the two most senior members." would be better? But I'm not sure
this is worth fixing.

This is still pending, and noted in BUGS. I agree this is as a potential
problem, at least if you look at it from a paranoid angle. I find your
suggested wording not immediate, though, and I wonder if a/ someone else
has better suggestion, and b/ whether this is worth fixing.

Post by Anthony Towns
​Maybe ​"(It might thus happen that at the start of January 1st the
Technical Committee is composed of just 4 members​, all of whom were
appointed more than 54 months ago. If so, no one's term will expire.
However if additional members are appointed in the next year, then the 2
most senior members' terms will expire at the next review round.)" would be
better? I'm not sure if this needs explaining though?

This has become moot, as the underlying text is gone.

Post by Anthony Towns
I wonder if "four and a half years (54 months)" would be better.

Fixed.

Cheers.

[Svante Signell]

Hi,

6.2. Composition
1. The Technical Committee consists of up to 8 Developers, and should
usually have at least 4 members.
2. When there are fewer than 8 members the Technical Committee may
recommend new member(s) to the Project Leader, who may choose
(individually) to appoint them or not.
3. When there are 5 members or fewer the Technical Committee may
appoint new member(s) until the number of members reaches 6.
4. When there have been 5 members or fewer for at least one week the
Project Leader may appoint new member(s) until the number of
members reaches 6, at intervals of at least one week per
appointment.

Why not avoid the casting vote problem by stipulating that the number
of members should always be an odd number. In case it is a problem of
keeping this number always odd, at least when voting is required, the
number of voters should be odd (either by excluding or including one
voter). (Yes, I know about the Condorcet Voting System with Schwartz
Sequential Dropping.)

Sincerely

[Hubert Chathi]

Post by Stefano Zacchiroli
1. Membership of the Technical Committee is automatically
reviewed on the 1st of January of each year. At this time, the
terms of the 2 most senior members automatically expire
provided they were appointed at least four and a half years
(54 months) ago.

One possible reading of that is that both members must have been
appointed at least 54 months ago in order for either of them to be
expired, which is probably not what was meant.

I'm not entirely sure what a better wording would be. Maybe adding an
extra sentence saying: "If only one member was appointed at least four
and a half years (54 months) ago, that member's term expires." But I'm
not too happy with they way that flows, and maybe someone can come up
with something better.
--
Hubert Chathi <***@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

[Don Armstrong]

Post by Stefano Zacchiroli

Post by Anthony Towns
"provided /they/ were appointed"

This is still pending, and noted in BUGS. I agree this is as a potential
problem, at least if you look at it from a paranoid angle. I find your
suggested wording not immediate, though, and I wonder if a/ someone else
has better suggestion, and b/ whether this is worth fixing.

Maybe this:

diff --git a/constitution.txt.new b/constitution.txt.new
index 96245cf..fb5ac4a 100644
--- a/constitution.txt.new
+++ b/constitution.txt.new
@@ -305,10 +305,10 @@
remove or replace an existing member of the Technical Committee.
7. Term limit:
1. Membership of the Technical Committee is automatically
- reviewed on the 1st of January of each year. At this time, the
- terms of the 2 most senior members automatically expire
- provided they were appointed at least four and a half years
- (54 months) ago.
+ reviewed on the 1st of January of each year. At this time,
+ the terms of the 2 most senior members who were most
+ recently appointed at least 54 months ago automatically
+ expire.
2. A member of the Technical Committee is said to be more senior
than another if they were appointed earlier, or were appointed
at the same time and have been a member of the Debian Project
--
2.1.1

Also, one of the things that would also be nice to fix is to make the
max number of CTTE members 9 instead of 8, to avoid the casting vote
problem when the CTTE is full.

I don't believe that we should force the CTTE to have an odd number,
because that is complicated, and may not be worth the effort, either.

This patch is simple, but:

diff --git a/constitution.txt.new b/constitution.txt.new
index 96245cf..85f0043 100644
--- a/constitution.txt.new
+++ b/constitution.txt.new
@@ -288,9 +288,9 @@

6.2. Composition

- 1. The Technical Committee consists of up to 8 Developers, and should
+ 1. The Technical Committee consists of up to 9 Developers, and should
usually have at least 4 members.
- 2. When there are fewer than 8 members the Technical Committee may
+ 2. When there are fewer than 9 members the Technical Committee may
recommend new member(s) to the Project Leader, who may choose
(individually) to appoint them or not.
3. When there are 5 members or fewer the Technical Committee may
--
2.1.1

But if this is at all controversial, then we can put this forward later.
--
Don Armstrong http://www.donarmstrong.com

LEADERSHIP -- A form of self-preservation exhibited by people with
autodestructive imaginations in order to ensure that when it comes to
the crunch it'll be someone else's bones which go crack and not their
own.
-- The HipCrime Vocab by Chad C. Mulligan
(John Brunner _Stand On Zanzibar_ p256-7)

[Holger Levsen]

Hi Don,

Post by Don Armstrong
- 1. The Technical Committee consists of up to 8 Developers, and should
+ 1. The Technical Committee consists of up to 9 Developers, and should

[...]

Post by Don Armstrong
But if this is at all controversial, then we can put this forward later.

It's a game changer, IMHO, so I guess it will be somewhat controversial for
sure and should be presented as (an) explicit option(s) on ballots...

(FWIW, I _think_ I prefer an even number here... and despite labeling this a
"game changer" I'm not sure I care that much about this change... arg and this
might sound like it could be misunderstood again...)


;tldr;: clear ballots, "no editorial changes" please.

Holger

[Don Armstrong]

Post by Holger Levsen
(FWIW, I _think_ I prefer an even number here... and despite labeling
this a "game changer" I'm not sure I care that much about this
change... arg and this might sound like it could be misunderstood
again...)

The real reason to use an odd number is to avoid having to use the
casting vote in the CTTE. Considering that we've used the casting vote
exactly once in the entire history of Debian, I'm not sure that
including this is worth the effort if even one person disagrees.
--
Don Armstrong http://www.donarmstrong.com

You could say she lived on the edge... Well, maybe not exactly on the edge,
just close enough to watch other people fall off.
-- hugh macleod http://www.gapingvoid.com/Moveable_Type/archives/000309.html

[Holger Levsen]

Hi,

Post by Don Armstrong
The real reason to use an odd number is to avoid having to use the
casting vote in the CTTE. Considering that we've used the casting vote
exactly once in the entire history of Debian, I'm not sure that
including this is worth the effort if even one person disagrees.

according to https://www.debian.org/devel/tech-ctte the very first tech-ctte
decission was decided by Ian through casting vote...

Thinking aloud: maybe this casting vote is a bad idea, and if the even number
of tech-ctte members cannot agree we must have... a GR? discussions til we
light up some fire until we have white smoke?


cheers,
Holger

[Stefano Zacchiroli]

[ secretary: question for you at the end ]
[ I've addressed this in
https://lists.debian.org/debian-vote/2014/11/msg00165.html ]

Post by Don Armstrong
Also, one of the things that would also be nice to fix is to make the
max number of CTTE members 9 instead of 8, to avoid the casting vote
problem when the CTTE is full.

I've mixed feelings about the "tie breaking" matter in the ctte.

On the one hand, voting is not mandatory (and it is not majority voting
anyhow), so there is no silver bullet rule that can guarantee the
absence of ties, no matter the size of the ctte. On the other hand, one
might try to minimize the chances that a tie will arise, and an
odd-sized ctte will probably do that.

But I don't think this matter is completely independent from the
turn-over rule we are introducing. For instance, I suspect that if we
were to introduce the term limit, on average it will be less likely for
the ctte to be fully staffed (due to the expiries and the fact that the
overall energy spent in periodically restaffing the ctte will be
higher).

The latter argument questions both increasing the maximum size to 9
(rather than, say, reducing it to 7) and the overall usefulness of a

Post by Don Armstrong
I don't believe that we should force the CTTE to have an odd number,
because that is complicated, and may not be worth the effort, either.

Things would indeed be different if we were to fiddle with appointments,
so that after each appointment the ctte has an odd number of members.
You're certainly right it would be complicated.

Post by Don Armstrong
But if this is at all controversial, then we can put this forward later.

I don't think it's necessarily controversial. But my take home message
from the above discussion is that this proposal is less ready thank the
term limit one. That alone might warrant postponing.

Even if it were as ready, I wonder if it wouldn't be better to have a
separate GR. Voting once instead of twice is nice for everyone, but
conflating two separate decisions in a single GR has been proven to be
unwise in the past. And I'm especially wary of doing so with a
constitutional change. Secretary: can you share your thoughts on this
last point with us, what would be best from the ballot preparation POV?

Cheers.

[Neil McGovern]

Post by Stefano Zacchiroli
Even if it were as ready, I wonder if it wouldn't be better to have a
separate GR. Voting once instead of twice is nice for everyone, but
conflating two separate decisions in a single GR has been proven to be
unwise in the past. And I'm especially wary of doing so with a
constitutional change. Secretary: can you share your thoughts on this
last point with us, what would be best from the ballot preparation POV?

If you think you want this as a separate option, I would suggest an amendment to your original text and not accepting it. This way people could (with condorcet) choose between the two.

Neil

[Didier 'OdyX' Raboud]

Post by Neil McGovern

Post by Stefano Zacchiroli
Even if it were as ready, I wonder if it wouldn't be better to have a
separate GR. Voting once instead of twice is nice for everyone, but
conflating two separate decisions in a single GR has been proven to
be unwise in the past. And I'm especially wary of doing so with a
constitutional change. Secretary: can you share your thoughts on
this last point with us, what would be best from the ballot
preparation POV?

If you think you want this as a separate option, I would suggest an
amendment to your original text and not accepting it. This way people
could (with condorcet) choose between the two.

That doesn't work if people want to vote on change A and change B
independently, unless the ballot becomes:

* only A
* only B
* B & A

… at which point two votes in sequence make more sense, IMHO.

OdyX

[Kurt Roeckx]

Post by Stefano Zacchiroli
Even if it were as ready, I wonder if it wouldn't be better to have a
separate GR. Voting once instead of twice is nice for everyone, but
conflating two separate decisions in a single GR has been proven to be
unwise in the past. And I'm especially wary of doing so with a
constitutional change. Secretary: can you share your thoughts on this
last point with us, what would be best from the ballot preparation POV?

What I think doesn't matter. It's the people that propose it that
need to make up their mind on what they want to vote on. People
can always make amendements where one of them only changes 1 of
the 2 things.

I think if the changes are likely to have a large majority after
it, I see no problem combining them. But I would still suggest to
have every change be only about one thing, just like you try to do
it when you make commits.


Kurt

[Didier 'OdyX' Raboud]

Hi zack@,

Thanks for pushing this subject forward, it's a constitutional change I
would likely second.

Post by Stefano Zacchiroli

Post by Anthony Towns
"provided /they/ were appointed" reads to me like it might mean that
if only one of them was appointed that long ago, maybe neither of
them expire. I'm not sure I can think of anything better; maybe
something like "At this time, the terms of members who were
appointed at least 54 months ago automatically expire. Expiry
occurs in order of seniority, and is limited to at most the two
most senior members." would be better? But I'm not sure this is
worth fixing.

This is still pending, and noted in BUGS. I agree this is as a
potential problem, at least if you look at it from a paranoid angle.
I find your suggested wording not immediate, though, and I wonder if
a/ someone else has better suggestion, and b/ whether this is worth
fixing.

What about something along the lines of "At this time, the terms of
members who have been members for more than 54 months automatically
expire." ?

Post by Stefano Zacchiroli
5. A Developer is not eligible to be (re)appointed to the Technical
Committee if they have been a member within the previous 12 months.

Provided that the expiration happens on January first, does this imply
that if A was expired on 01.01.2015, she becomes eligible again on
01.01.2016? As I read the two new clauses, given someone the project
really wants on the TC, she can stay 5 years, break for a year and be
re-appointed, right?

All-in-all, I feel the change goes in the right direction, but I also
feel it only goes halfway through (probably the half we can collectively
agree on though). The two issues I'd like to see fixed on a longer term
are "quite long mandates" (although the fix helps here) and "imperfect
representativity of the diversity of the project caused by self-
appointment", which I'd like to get fixed through some sort of election
through the project. Sorry, I digressed; let's keep that for a later
discussion.

Cheers,
OdyX

[Stefano Zacchiroli]

Post by Didier 'OdyX' Raboud

Post by Stefano Zacchiroli
This is still pending, and noted in BUGS. I agree this is as a
potential problem, at least if you look at it from a paranoid angle.
I find your suggested wording not immediate, though, and I wonder if
a/ someone else has better suggestion, and b/ whether this is worth
fixing.

What about something along the lines of "At this time, the terms of
members who have been members for more than 54 months automatically
expire." ?

I've proposed a solution to this shortly before your message. Can you
look at it and follow-up if you're not happy with it and have an
alternative proposal?

Post by Didier 'OdyX' Raboud

Post by Stefano Zacchiroli
5. A Developer is not eligible to be (re)appointed to the Technical
Committee if they have been a member within the previous 12 months.

Provided that the expiration happens on January first, does this imply
that if A was expired on 01.01.2015, she becomes eligible again on
01.01.2016? As I read the two new clauses, given someone the project
really wants on the TC, she can stay 5 years, break for a year and be
re-appointed, right?

That is correct, yes.

Post by Didier 'OdyX' Raboud
All-in-all, I feel the change goes in the right direction, but I also
feel it only goes halfway through (probably the half we can collectively
agree on though). The two issues I'd like to see fixed on a longer term
are "quite long mandates" (although the fix helps here)

I guess it does, yes. Of course it depends on your notion of "quite
long", but ~5 years matches my intuitive notion of "long but not too
long" terms in board-like settings.

Post by Didier 'OdyX' Raboud
and "imperfect representativity of the diversity of the project caused
by self- appointment", which I'd like to get fixed through some sort
of election through the project. Sorry, I digressed; let's keep that
for a later discussion.

TBH I'm not sure how one could fix that with a hard rule either way, but
if you've specific proposals I'm all ears :) But please let's avoid
making perfect the enemy of the good (...aaaand once again I'm done with
my daily dose of lame proverbs).

Cheers.

[Stefano Zacchiroli]

Post by Stefano Zacchiroli
Here is a draft GR text which builds on Anthony's work and implements
some of the aspects discussed in this thread. See below for
comments/rationales and the attachment for a wdiff.

Updated draft below.

Changelog is:

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

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

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

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

Cheers.

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

---------------------------------------------------------------------------
--- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
+++ constitution.txt.new 2014-11-18 21:17:30.544040579 +0100
@@ -299,8 +299,22 @@
Project Leader may appoint new member(s) until the number of
members reaches 6, at intervals of at least one week per
appointment.
- 5. If the Technical Committee and the Project Leader agree they may
+ 5. A Developer is not eligible to be (re)appointed to the Technical
+ Committee if they have been a member within the previous 12 months.
+ 6. If the Technical Committee and the Project Leader agree they may
remove or replace an existing member of the Technical Committee.
+ 7. Term limit:
+ 1. Membership of the Technical Committee is automatically
+ reviewed on the 1st of January of each year. At this time, the
+ terms of members who were appointed at least four and a half
+ years (54 months) ago automatically expire. Expiry occurs in
+ order of seniority, most senior members first, and is limited
+ to at most 2 members per year.
+ 2. A member of the Technical Committee is said to be more senior
+ than another if they were appointed earlier, or were appointed
+ at the same time and have been a member of the Debian Project
+ longer. In the event that a member has been appointed more
+ than once, only the most recent appointment is relevant.

6.3. Procedure

---------------------------------------------------------------------------

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

[Martin Zobel-Helas]

Hi,

Post by Stefano Zacchiroli
===========================================================================
---------------------------------------------------------------------------
--- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
+++ constitution.txt.new 2014-11-18 21:17:30.544040579 +0100
@@ -299,8 +299,22 @@
Project Leader may appoint new member(s) until the number of
members reaches 6, at intervals of at least one week per
appointment.
- 5. If the Technical Committee and the Project Leader agree they may
+ 5. A Developer is not eligible to be (re)appointed to the Technical
+ Committee if they have been a member within the previous 12 months.
+ 6. If the Technical Committee and the Project Leader agree they may
remove or replace an existing member of the Technical Committee.
+ 1. Membership of the Technical Committee is automatically
+ reviewed on the 1st of January of each year. At this time, the
+ terms of members who were appointed at least four and a half
+ years (54 months) ago automatically expire. Expiry occurs in
+ order of seniority, most senior members first, and is limited
+ to at most 2 members per year.
+ 2. A member of the Technical Committee is said to be more senior
+ than another if they were appointed earlier, or were appointed
+ at the same time and have been a member of the Debian Project
+ longer. In the event that a member has been appointed more
+ than once, only the most recent appointment is relevant.

*second*

[Lucas Nussbaum]

Hi,

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

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

Post by Stefano Zacchiroli
+ 5. A Developer is not eligible to be (re)appointed to the Technical
+ Committee if they have been a member within the previous 12 months.

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

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

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

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

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

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

What do you think?

Lucas

[Stefano Zacchiroli]

Post by Lucas Nussbaum

Post by Stefano Zacchiroli
+ 5. A Developer is not eligible to be (re)appointed to the Technical
+ Committee if they have been a member within the previous 12 months.

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

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

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

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

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

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

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

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

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

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

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

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

Cheers.

[Lucas Nussbaum]

Post by Stefano Zacchiroli

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

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

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

Post by Stefano Zacchiroli

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

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

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

Lucas

[Bdale Garbee]

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

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

Bdale

[Steve Langasek]

Post by Lucas Nussbaum

Post by Stefano Zacchiroli

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

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

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

<snort>

[Lucas Nussbaum]

Post by Steve Langasek

Post by Lucas Nussbaum

Post by Stefano Zacchiroli

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

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

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

<snort>

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

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

Lucas

[Anthony Towns]

Post by Lucas Nussbaum
I don't think that the TC is a stress-full role. Obviously the recent past
proved how the role can be incredibly stressful at times. But there has
also been long periods without much activity, [...]

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

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

Cheers,
aj

[Lucas Nussbaum]

Post by Anthony Towns

Post by Lucas Nussbaum
I don't think that the TC is a stress-full role. Obviously the recent past
proved how the role can be incredibly stressful at times. But there has
also been long periods without much activity, [...]

FWIW, I agree with Steve here. The nature of the tech ctte is that it
only does things when there's some sort of significant enough problem
that can't be dealt with by other means, and that's pretty much always
going to be stressful. If the problem's not significant, no one cares
enough to take it to the ctte; if it's easy, it just gets dealt with. If
it's hard and important, dealing with it will be stressful...
That said, the breaks without activity make it easier, certainly --
I can't imagine someone lasting as DPL or release manager for 16 or 13
or 9 years, for instance.

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

Lucas

[Sam Hartman]

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

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

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

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

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

--Sam

[Anthony Towns]

Post by Lucas Nussbaum
First, some data. The 'age' of each member of the TC (not excluding Russ and
iwj at some point in 1999; ~15.3y

I already did the refs for these in May:

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

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

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

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

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

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

Post by Lucas Nussbaum

Post by Stefano Zacchiroli
+ 5. A Developer is not eligible to be (re)appointed to the Technical
+ Committee if they have been a member within the previous 12 months.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The social pressures here don't work very well. In general, any
approach that has the existing committee decide whether to retain
a member who's already on the committee has the potential for hard
feelings, creating future difficulties working together, and so forth.
This is why I favor some system that requires a pause; that way, no
one is put in the position of having to refuse to reappoint someone
that they've worked with for the last eight years.

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

I found that pretty persuasive personally.

Cheers,
aj

[Lucas Nussbaum]

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

OK, point taken.
So either we find a way to re-appoint a current member that avoids that
social pressure (but that would likely require changing the appointment
procedure entirely), or we drop the idea of not having a mandatory
vacation between two appointments. (which sounds more likely)

Lucas

[David Weinehall]

Post by Lucas Nussbaum

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

OK, point taken.
So either we find a way to re-appoint a current member that avoids that
social pressure (but that would likely require changing the appointment
procedure entirely), or we drop the idea of not having a mandatory
vacation between two appointments. (which sounds more likely)

How about only accepting reappointment during the cooloff period if

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

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

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


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

[Jakub Wilk]

Post by Stefano Zacchiroli
- 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. Membership of the Technical Committee is automatically
+ reviewed on the 1st of January of each year. At this time, the
+ terms of members who were appointed at least four and a half
+ years (54 months) ago automatically expire. Expiry occurs in
+ order of seniority, most senior members first, and is limited
+ to at most 2 members per year.
+ 2. A member of the Technical Committee is said to be more senior
+ than another if they were appointed earlier, or were appointed
+ at the same time and have been a member of the Debian Project
+ longer. In the event that a member has been appointed more
+ than once, only the most recent appointment is relevant.

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

[Stefano Zacchiroli]

Post by Jakub Wilk

Post by Stefano Zacchiroli
- 5. If the Technical Committee and the Project Leader agree they may
+ 5. A Developer is not eligible to be (re)appointed to the Technical
+ Committee if they have been a member within the previous 12 months.
+ 6. If the Technical Committee and the Project Leader agree they may
remove or replace an existing member of the Technical Committee.

Not sure why you had to renumber existing stuff;

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

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

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

Post by Jakub Wilk
but other than that, looks good to me!

Thanks for your feedback!

Cheers.

[Josh Triplett]

Post by Stefano Zacchiroli
- 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. Membership of the Technical Committee is automatically
+ reviewed on the 1st of January of each year. At this time, the
+ terms of members who were appointed at least four and a half
+ years (54 months) ago automatically expire. Expiry occurs in
+ order of seniority, most senior members first, and is limited
+ to at most 2 members per year.
+ 2. A member of the Technical Committee is said to be more senior
+ than another if they were appointed earlier, or were appointed
+ at the same time and have been a member of the Debian Project
+ longer. In the event that a member has been appointed more
+ than once, only the most recent appointment is relevant.

This approach seems like it focuses too much on aggregate committee
turnover, rather than just setting a term limit. In particular, I don't
see any obvious reason to limit expiry to 2 members per year (given that
we have a process for appointing new members, and that we're about to do
so), or to tie expiry to the calendar year (rather than the member's
appointment), and I think the break before re-election could be
incorporated into the term limit. What about something like this:

"""
No Developer may serve on the Technical Committee for more than 4 years
out of any 6 year period. A Developer's term on the Technical Committee
expires if they would exceed this limit.
"""

Exact numbers open for bikeshedding, but does the principle seem sound?

We can leave it implicit that a developer whose term would immediately
expire is not eligible for appointment, since doing so would be
pointless. We don't need rules allowing a developer to stay on the
committee despite their term expiring; we can easily predict such dates
and plan on appointing new members by that time, just as we do for DPLs.
That also eliminates any issues of relative seniority, since we evaluate
each member's term limit in isolation. It also eliminates any
transitional issues, both because we don't link the expiry to any
particular calendar date, and because by the time we pass this we'll
have enough developers on the committee whose terms will *not*
immediately expire that we won't have to appoint more in a rush.

So, the complete diffstat of this proposal is +3-0, rather than +15-1.
:)

- Josh Triplett

[Andrei POPESCU]

[private reply on purpose, since I'm not a DD]

Post by Josh Triplett
"""
No Developer may serve on the Technical Committee for more than 4 years
out of any 6 year period. A Developer's term on the Technical Committee
expires if they would exceed this limit.
"""
Exact numbers open for bikeshedding, but does the principle seem sound?

It does to me, but given the current "age" of the TC members[1] the
practical effect would be that the terms of all TC members except Keith
Packard would expire as soon as the GR passes and assuming no member
ever retires the same will happen every 4 years (as per your suggest
numbers).

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

I would suggest introducing a transitional clause that would state
something like:

As a transitional measure, the terms of all current members that
exceed 4 years will only expire every 6 months, in order of
seniority.

This would need some refining, but I hope you get the point.

Kind regards,
Andrei

[Andrei POPESCU]

Post by Andrei POPESCU
[private reply on purpose, since I'm not a DD]

Which I did not, sorry...

Kind regards,
Andrei

[Hubert Chathi]

Post by Andrei POPESCU

Post by Andrei POPESCU
[private reply on purpose, since I'm not a DD]

Which I did not, sorry...

I think you'll find that constructive messages (as yours was) are
generally welcome on this list, whether it comes from a DD or a non-DD.
--
Hubert Chathi <***@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

[Stefano Zacchiroli]

Post by Josh Triplett
That also eliminates any issues of relative seniority, since we
evaluate each member's term limit in isolation. It also eliminates
any transitional issues, both because we don't link the expiry to any
particular calendar date, and because by the time we pass this we'll
have enough developers on the committee whose terms will *not*
immediately expire that we won't have to appoint more in a rush.

I wonder how you could be so sure about that.

But even if that is the case, replacing the whole (or mostly of) the
current CTTE with a freshly appointed one at the same time is very
likely to induce the problem that after another full term period (4
years or whatever else the bikeshed says) from now you'll have another
large wave of batch replacements. Yes, that could happen anyhow, but is
much more likely to happen if you start enforcing a strict term limit
abruptly to all members, instead of doing so gradually.

So, while your proposal is appealing in the abstract for its simplicity,
it is not really practical (in the current situation) without a
relatively complex transitional measure that make its initial
application gradual.

Post by Josh Triplett
So, the complete diffstat of this proposal is +3-0, rather than +15-1.
:)

Yes, but to achieve a similar effect you'll have a much larger diff to
apply to the transitional measure, that you're trying to sweep under the
carpet :-)

Cheers.

[Anthony Towns]

Post by Josh Triplett
This approach seems like it focuses too much on aggregate committee
turnover, rather than just setting a term limit.

Term limits rather than turnover was what I proposed originally; the
response to that was that people were concerned about it risking too
much churn.

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

Cheers,
aj

[Lucas Nussbaum]

Post by Stefano Zacchiroli
Here is a draft GR text which builds on Anthony's work and implements
some of the aspects discussed in this thread. See below for
comments/rationales and the attachment for a wdiff.
==============================================================================
---------------------------------------------------------------------------
--- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
+++ constitution.txt.new 2014-11-18 11:12:13.665659796 +0100
@@ -299,8 +299,28 @@
Project Leader may appoint new member(s) until the number of
members reaches 6, at intervals of at least one week per
appointment.
- 5. If the Technical Committee and the Project Leader agree they may
+ 5. A Developer is not eligible to be appointed to the Technical Committee
+ if they have been a member within the previous 12 months.
+ 6. If the Technical Committee and the Project Leader agree they may
remove or replace an existing member of the Technical Committee.
+ 1. Membership of the Technical Committee is automatically
+ reviewed on the 1st of January of each year. At this time, the
+ terms of the 2 most senior members automatically expire
+ provided they were appointed at least 54 months ago.
+ 2. A member of the Technical Committee is said to be more senior
+ than another if they were appointed earlier, or were appointed
+ at the same time and have been a member of the Debian Project
+ longer. In the event that a member has been appointed more
+ than once, only the most recent appointment is relevant.
+ 3. At each review round expiries are processed sequentially, most
+ senior member first.
+ 4. No expiry can reduce the size of the Technical Committee to
+ 3 members or fewer. (It might thus happen that up to 4 members of
+ the Technical Committee remain in charge with more than 54 months
+ of seniority on January 1st. In that case, up to 2 of them will
+ expire at the next review round, provided that the committee has
+ been further staffed.)
6.3. Procedure
---------------------------------------------------------------------------
As a transitional measure, if this GR proposal is passed after 2015-01-01,
then the first automatic review of membership of the Technical Committee
happens immediately.
==============================================================================
- The main change wrt the original text by Anthony is that the provision
of not expiring senior members if less-senior ones have resigned is
gone. In its stead, there is a provision that inhibits expiries from
reducing the CTTE size below 4 members. As a result, the math part
with N and R is gone, IMHO simplifying the text.

Hi,

I thought about that change, and I am unsure that this is a good thing.

(Elaborating on the context a bit given the discussion spread over some
time -- two options have been proposed:
- expire the 2 most senior members
- expire the 2-R most senior members, with R the number of resignations
over the last 12 months)

What we want to encourage is, I think, a sane and healthy turnover in
the TC. Ideally, this would happen automatically: members would just
resign when they feel that bringing fresh manpower is profitable to the
TC overall. However, there's a number of social reasons why this doesn't
work so well.

So what we are proposing here is to force the renewal of some members.

Now, let's assume that I'm a member of the TC, not among the two most
senior members, and that I feel a bit exhausted about that, not really
motivated, and not really up to the task anymore. Ideally, I should be
encouraged to resign.
With the 'strictly 2' schema, I have an additional incentive NOT to
resign: if I resign, I cause 3 renewals instead of 2, which might weaken
the TC a bit too much.
With the '2-R' schema, I have an additional incentive to resign: if I
resign, I 'save' someone else more senior than me from getting expired.
(And given I'm not so active anymore, instead of weakening the TC further,
my resignation might even reinforce the TC).


The '2-R' schema could even result in an internal TC discussion: "OK,
the Project wants us to change two members. Are there people that feel
like resigning now? Or should we just fallback to the default of expiring
the two most senior members?"
I think that if this happened, it would be very healthy for the TC.

What do you think?

Lucas

[Didier 'OdyX' Raboud]

Post by Lucas Nussbaum
The '2-R' schema could even result in an internal TC discussion: "OK,
the Project wants us to change two members. Are there people that feel
like resigning now? Or should we just fallback to the default of
expiring the two most senior members?"
I think that if this happened, it would be very healthy for the TC.

I quite like the idea. I was also thinking of something along the lines
of "automatic resignation unless self-extended", similar to what we have
(although mildly working) for DMs. This would be equivalent to saying
that the TC terms are of one year, renewed manually by "stating so", up
to 5 times.

This would allow automatic expiry of members becoming inactive for some
reason, without implying a TC+DPL decision (§6.2.5). This would also put
the "should I continue be part of the TC for a new one-year term"
question explicitly and annually on the table.

OdyX

[Lucas Nussbaum]

Post by Lucas Nussbaum

Post by Stefano Zacchiroli
- The main change wrt the original text by Anthony is that the provision
of not expiring senior members if less-senior ones have resigned is
gone. In its stead, there is a provision that inhibits expiries from
reducing the CTTE size below 4 members. As a result, the math part
with N and R is gone, IMHO simplifying the text.

Hi,
I thought about that change, and I am unsure that this is a good thing.

To clarify: by 'that change', I mean the switch from '2-R most senior
members' to '2 most senior members'. The quoted paragraph is mostly
about something else, but I failed to find another place where that
change was discussed.

Lucas

[Stefano Zacchiroli]

Post by Lucas Nussbaum
(Elaborating on the context a bit given the discussion spread over some
- expire the 2 most senior members
- expire the 2-R most senior members, with R the number of resignations
over the last 12 months)

ACK. For reference this was discussed mostly in [1,2], unfortunately
with not too many people participating. My draft is based on the
apparent potential consensus (between me and AJ, as the main
participants in the discussion). It is indeed an important point, so
thanks for re-raising it.

[1]: https://lists.debian.org/debian-vote/2014/11/msg00041.html
[2]: https://lists.debian.org/debian-vote/2014/11/msg00098.html

That said, I now am convinced that "2" (without "salvaging" by expiries
of non-senior members) is a better model than "2-R". I've pondered your
arguments below, but I don't find them convincing. Specifically,

Post by Lucas Nussbaum
What we want to encourage is, I think, a sane and healthy turnover in
the TC. Ideally, this would happen automatically: members would just
resign when they feel that bringing fresh manpower is profitable to
the TC overall. However, there's a number of social reasons why this
doesn't work so well.

Agreed.

Post by Lucas Nussbaum
Now, let's assume that I'm a member of the TC, not among the two most
senior members, and that I feel a bit exhausted about that, not really
motivated, and not really up to the task anymore. Ideally, I should be
encouraged to resign.
With the 'strictly 2' schema, I have an additional incentive NOT to
resign: if I resign, I cause 3 renewals instead of 2, which might weaken
the TC a bit too much.

This is true only insofar a temporary reduction in CTTE membership
actually weakens the CTTE. I don't think that's the case. Formally, the
Constitution suggests ranges in which the CTTE is somehow considered to
be properly functional; outside those ranges, there is no quality
judgement associate to CTTE size. More generally in management terms,
larger boards are not necessarily "better" than smaller ones (in fact,
in the specific case of efficiency, size is usually considered to be
_negatively_ correlated with it, due to the communication overhead).

But more importantly, we are talking here about *temporary* reductions
in CTTE size, with a time window that might be as small as 0. The CTTE
and the DPL will know in advance that expiries are upcoming, and can
plan new appointments accordingly, potentially doing appointments as
early as January 2nd. If it is known that someone will step in (no
matter whether you know who that person will be or not), then the
negative incentive you mention disappears.

Post by Lucas Nussbaum
With the '2-R' schema, I have an additional incentive to resign: if I
resign, I 'save' someone else more senior than me from getting expired.
(And given I'm not so active anymore, instead of weakening the TC further,
my resignation might even reinforce the TC).

It seems to me that you've an underlying assumption here that
resignation of inactive members are more important than resignation of
senior members. For me they are exactly on the same level, so I don't
see why one should be technically favored over the other.

Also if there are no incentives against resigning (which I maintain as
per my answer to your other argument) I do expect inactive members to
resign no matter whether they are senior or not. And if they do not want
to, then it is much better to have a strict term limit rule, rather than
one allowing for exceptions.

(It is worth noting here that I'm thinking about this master in fully
abstract terms, I do not have any specific present, past, or future
members of the CTTE in mind. Nor I know offhand the current seniority
ranking.)

Post by Lucas Nussbaum
The '2-R' schema could even result in an internal TC discussion: "OK,
the Project wants us to change two members. Are there people that feel
like resigning now? Or should we just fallback to the default of expiring
the two most senior members?"
I think that if this happened, it would be very healthy for the TC.

I agree that this would most certainly happen. But my judgement on it is
that it would be a *bad* thing, not a good one. In fact, I would see
that as a tactical behavior on the part of the CTTE to work around an
agreed upon judgement on the fact that turn-over is good, and that
remaining in charge too long is bad.

Cheers.

[Lucas Nussbaum]

Post by Stefano Zacchiroli

Post by Lucas Nussbaum
Now, let's assume that I'm a member of the TC, not among the two most
senior members, and that I feel a bit exhausted about that, not really
motivated, and not really up to the task anymore. Ideally, I should be
encouraged to resign.
With the 'strictly 2' schema, I have an additional incentive NOT to
resign: if I resign, I cause 3 renewals instead of 2, which might weaken
the TC a bit too much.

This is true only insofar a temporary reduction in CTTE membership
actually weakens the CTTE. I don't think that's the case. Formally, the
Constitution suggests ranges in which the CTTE is somehow considered to
be properly functional; outside those ranges, there is no quality
judgement associate to CTTE size. More generally in management terms,
larger boards are not necessarily "better" than smaller ones (in fact,
in the specific case of efficiency, size is usually considered to be
_negatively_ correlated with it, due to the communication overhead).
But more importantly, we are talking here about *temporary* reductions
in CTTE size, with a time window that might be as small as 0. The CTTE
and the DPL will know in advance that expiries are upcoming, and can
plan new appointments accordingly, potentially doing appointments as
early as January 2nd. If it is known that someone will step in (no
matter whether you know who that person will be or not), then the
negative incentive you mention disappears.

This is true only if you use the number of members as the measure for
the "strength" of the TC. But if instead, you consider the sum of the
experience of all members, more turnover due to resignations at a given
point will have a greater impact.

Of course, the TC will likely be mostly resilient to that. But if we can
avoid that, I think we should.

Post by Stefano Zacchiroli

Post by Lucas Nussbaum
With the '2-R' schema, I have an additional incentive to resign: if I
resign, I 'save' someone else more senior than me from getting expired.
(And given I'm not so active anymore, instead of weakening the TC further,
my resignation might even reinforce the TC).

It seems to me that you've an underlying assumption here that
resignation of inactive members are more important than resignation of
senior members. For me they are exactly on the same level, so I don't
see why one should be technically favored over the other.

Oh yes, sure. I don't care very much about the seniority of members, as
long as they are able to do their job with the level of quality required
by the role. So, yes, I think that the replacement of inactive,
demotivated or no longer suited members is much more important than to
the replacement of the more senior members.

Post by Stefano Zacchiroli
(It is worth noting here that I'm thinking about this master in fully
abstract terms, I do not have any specific present, past, or future
members of the CTTE in mind.

Same here.

Post by Stefano Zacchiroli
Nor I know offhand the current seniority ranking.)

Well, I can't say that, given I did the research to do the stats in

Post by Stefano Zacchiroli

Post by Lucas Nussbaum
The '2-R' schema could even result in an internal TC discussion: "OK,
the Project wants us to change two members. Are there people that feel
like resigning now? Or should we just fallback to the default of expiring
the two most senior members?"
I think that if this happened, it would be very healthy for the TC.

I agree that this would most certainly happen. But my judgement on it is
that it would be a *bad* thing, not a good one. In fact, I would see
that as a tactical behavior on the part of the CTTE to work around an
agreed upon judgement on the fact that turn-over is good, and that
remaining in charge too long is bad.

Note that I agree that turn-over is good.

I also generally agree that remaining in charge too long is bad. However:
- I think that what is "too long" might depend on individual factors
- I don't think that 4 years is a reasonable value for "too long".

Lucas

[Stefano Zacchiroli]

Post by Lucas Nussbaum
This is true only if you use the number of members as the measure for
the "strength" of the TC. But if instead, you consider the sum of the
experience of all members, more turnover due to resignations at a given
point will have a greater impact.

I guess we have different notions of "experience" in mind here. It seems
to me that the one you are using is "how long you have been serving on
the CTTE", right? If it is so, and given that you consider
re-appointments unlikely, I understand that from your POV the overall
experience of the CTTE will suffer if this proposal were to pass.

(As mentioned in a separate mail, I don't think it is that unlikely for
CTTE members to be re-appointed after "vacation", so my perception of
loss is lower, but I'll ignore that for now.)

I think that the experience we should looking for in CTTE members should
be pre-existing, in project areas like dealing with pesky technical
issues (possibly at the intersection of many inter-connected packages),
and in being able to manage standardization-like processes from
discussion to synthesis. I expect this experience to be formed mostly
outside the CTTE, in large packaging teams and/or working as interface
between packaging teams and/or in the policy team.

The only other kind of interesting additional experience that is CTTE
specific is conflict arbitration. It is certainly very important for the
job, but I don't think it is enough, alone, to justify longer terms.
(You probably disagree :-)) Also, it is something that IMHO members
would have to learn elsewhere anyhow (due to their personal life
experiences, previous jobs, professional training, etc).

Post by Lucas Nussbaum
long as they are able to do their job with the level of quality required
by the role. So, yes, I think that the replacement of inactive,
demotivated or no longer suited members is much more important than to
the replacement of the more senior members.

[...]

Post by Lucas Nussbaum
Note that I agree that turn-over is good.
- I think that what is "too long" might depend on individual factors
- I don't think that 4 years is a reasonable value for "too long".

We can certainly discuss on your second point, and possibly have
different values for N on the ballot. That's easy.

But your first point is essentially delegating to case-by-case decisions
what to do, which is by definition not something you can obtain with a
strict rule. I.e., it seems to me that your first point calls in to
question whether we should have a strict rule in the first place.

Cheers.

[Philip Hands]

Stefano Zacchiroli <***@debian.org> writes:

...

Post by Stefano Zacchiroli

Post by Lucas Nussbaum
The '2-R' schema could even result in an internal TC discussion: "OK,
the Project wants us to change two members. Are there people that feel
like resigning now? Or should we just fallback to the default of expiring
the two most senior members?"
I think that if this happened, it would be very healthy for the TC.

I agree that this would most certainly happen. But my judgement on it is
that it would be a *bad* thing, not a good one. In fact, I would see
that as a tactical behavior on the part of the CTTE to work around an
agreed upon judgement on the fact that turn-over is good, and that
remaining in charge too long is bad.

Quite.

This reminds me of a rule that for the EU's framework programs, where
they must make sure that (IIRC) 30% new blood is brought into the review
process every year to try to avoid cronyism.

That sounds like a decent rule, in that it seems to imply that one
replaces the reviewers every 4 years or so, but that's not what actually
happens for various reasons.

The actual outcome is that the same 60+% tend to do reviews year after
year, with the 30% each year mostly replacing the 30% from the year
before.

Of course, with the TC it doesn't matter as much, because the TC is not
allocating millions of Euros of funding.

Even so, if someone wanted to stay in post on the TC for whatever
reason, this '2-R' rule would just encourage them to be difficult to
work with in the hope that a couple of less senior members became fed up
enough to leave early.

It doesn't seem wise to have such an incentive to behave badly.

Cheers, Phil.

[Lucas Nussbaum]

Hi Phil,

Post by Philip Hands
...

Post by Stefano Zacchiroli

Post by Lucas Nussbaum
The '2-R' schema could even result in an internal TC discussion: "OK,
the Project wants us to change two members. Are there people that feel
like resigning now? Or should we just fallback to the default of expiring
the two most senior members?"
I think that if this happened, it would be very healthy for the TC.

I agree that this would most certainly happen. But my judgement on it is
that it would be a *bad* thing, not a good one. In fact, I would see
that as a tactical behavior on the part of the CTTE to work around an
agreed upon judgement on the fact that turn-over is good, and that
remaining in charge too long is bad.

Quite.
This reminds me of a rule that for the EU's framework programs, where
they must make sure that (IIRC) 30% new blood is brought into the review
process every year to try to avoid cronyism.
That sounds like a decent rule, in that it seems to imply that one
replaces the reviewers every 4 years or so, but that's not what actually
happens for various reasons.
The actual outcome is that the same 60+% tend to do reviews year after
year, with the 30% each year mostly replacing the 30% from the year
before.
Of course, with the TC it doesn't matter as much, because the TC is not
allocating millions of Euros of funding.

I struggle to understand if this is a point against the '2-R' rule, or a
general comment about the possible risk that the TC might decide to just
re-appoint members expired at year n-1. I don't see what '2-R' changes
compared to '2' about that.

Post by Philip Hands
Even so, if someone wanted to stay in post on the TC for whatever
reason, this '2-R' rule would just encourage them to be difficult to
work with in the hope that a couple of less senior members became fed up
enough to leave early.
It doesn't seem wise to have such an incentive to behave badly.

I'm unconvinced that this is an actual problem. Being difficult to work
with is one thing; but being difficult to work with in the hope that it
will cause other members to resign so that one can stay one more year on
the Debian TC seems quite a stretch.

Lucas

[Anthony Towns]

Post by Stefano Zacchiroli
That said, I now am convinced that "2" (without "salvaging" by expiries
of non-senior members) is a better model than "2-R". I've pondered your
arguments below, but I don't find them convincing. Specifically,

Note that with Ian, Russ and Colin's resignation announcements we have a
test case of the difference between these two options:

"2": Russ, Ian resign, either (Bdale, Steve expire; Colin resigns) or
(Colin resigns; Bdale, Steve expire) leaving just Andi, Don and
Keith on the committee, with five spots to fill come January,
and Andi and Don due to expire Jan 1st 2016.

or

"2-R": Russ, Ian, Colin resign; nobody expires; Bdale, Steve, Andi, Don,
Keith remain on the committee, with three spots to fill come
January, and Bdale and Steve due to expire Jan 1st 2016.

Cheers,
aj

[Lucas Nussbaum]

Post by Anthony Towns

Post by Stefano Zacchiroli
That said, I now am convinced that "2" (without "salvaging" by expiries
of non-senior members) is a better model than "2-R". I've pondered your
arguments below, but I don't find them convincing. Specifically,

Note that with Ian, Russ and Colin's resignation announcements we have a

If I got this right...

Post by Anthony Towns
"2": Russ, Ian resign, either (Bdale, Steve expire; Colin resigns) or
(Colin resigns; Bdale, Steve expire) leaving just Andi, Don and
Keith on the committee, with five spots to fill come January,
and Andi and Don due to expire Jan 1st 2016.

2016-01-01: Andi and Don expire, 2 replacements
2017-01-01: Keith is the oldest member with 3.09y, nobody expires
2018-01-01: Keith is the oldest member with 4.09y, nobody expires
2019-01-01: Keith membership expires, none of the other does
2020-01-01: we have 5 members over the 4.5y limit, two expire
2021-01-01: we have 3+2=5 members over the 4.5y limit, two expire

Post by Anthony Towns
"2-R": Russ, Ian, Colin resign; nobody expires; Bdale, Steve, Andi, Don,
Keith remain on the committee, with three spots to fill come
January, and Bdale and Steve due to expire Jan 1st 2016.

2016-01-01: Bdale and Steve expire, 2 replacements
2017-01-01: Andi and Don expire, 2 replacements
2018-01-01: Keith is the oldest member with 4.09y, nobody expires
2019-01-01: Keith membership expires, none of the other does
2020-01-01: we have 3 members over the 4.5y limit, two expire
2021-01-01: we have 1+2=3 members over the 4.5y limit, two expire

I think that the "2-R" behaviour is more desirable, as it avoids 2 years
without replacements in 2017 and 2018. Note that this isn't about the
"2-R" rule as we could have the same behaviour by keeping the "2" rule
and simply dropping the transitional measure (and passing the GR after
2015-01-01, or having a transitional measure that annihilates the
expiring on 2015-01-01)

Lucas

[Anthony Towns]

Post by Lucas Nussbaum
I think that the "2-R" behaviour is more desirable, as it avoids 2 years
without replacements in 2017 and 2018. Note that this isn't about the
"2-R" rule as we could have the same behaviour by keeping the "2" rule
and simply dropping the transitional measure (and passing the GR after
2015-01-01, or having a transitional measure that annihilates the
expiring on 2015-01-01)

I think if the "2-R" behaviour is more desirable now, it's worthwhile
being a general rule so if we end up in the same situation in future,
it's still there. I'm still fairly indifferent between the two options
though (I think a committee of just Andi, Don and Keith would actually
be fine), personally; so my preference/vote would probably be "[2] ==
[2-R] > [2 but not until next year]", I guess.

However, another option would be "2-R'" where only retirements of people
who would otherwise be candidates for expiry count. So Russ quitting
after serving 5.8 years would count, but Colin resigning after serving
"just" 3.2 years wouldn't. That doesn't seem like it's especially easy
to specify either though.

What about avoiding all the ifs and buts and math and just giving
committee members a goal, and trusting them to figure out how to best to
adhere to it (and how to balance it against other goals like retaining
institutional memory or whatever)?

Technical Committee members are encouraged to serve for a term of
between three and six years.

If a committee member tried lurking about forever, that would still
provide a "we don't hate you, but it's time" justification for the ctte
to vote to remove a member, or the project as a whole to do so, which
is currently lacking.

I've picked three years as a lower bound, since that's how long both
Colin and I lasted, and six years as an upper bound since it gives a bit
more flexibility than five years and matches about how long Russ lasted.

Cheers,
aj

[Matthias Urlichs]

Hi,

Post by Anthony Towns
Technical Committee members are encouraged to serve for a term of
between three and six years.

What, you seriously want to not increase the amount of Legalese in our
policy? The shame. :-P

Post by Anthony Towns
and six years as an upper bound since it gives a bit
more flexibility than five years

Me like.

[Sam Hartman]

Lucas> (Elaborating on the context a bit given the discussion spread
Lucas> over some time -- two options have been proposed: - expire
Lucas> the 2 most senior members - expire the 2-R most senior
Lucas> members, with R the number of resignations over the last 12
Lucas> months)

Lucas> What we want to encourage is, I think, a sane and healthy
Lucas> turnover in the TC. Ideally, this would happen automatically:
Lucas> members would just resign when they feel that bringing fresh
Lucas> manpower is profitable to the TC overall. However, there's a
Lucas> number of social reasons why this doesn't work so well.
Lucas> which might weaken the TC a bit too much. With the '2-R'
Lucas> schema, I have an additional incentive to resign: if I
Lucas> resign, I 'save' someone else more senior than me from
Lucas> getting expired. (And given I'm not so active anymore,
Lucas> instead of weakening the TC further, my resignation might
Lucas> even reinforce the TC).


Lucas> The '2-R' schema could even result in an internal TC
Lucas> discussion: "OK, the Project wants us to change two
Lucas> members. Are there people that feel like resigning now? Or
Lucas> should we just fallback to the default of expiring the two
Lucas> most senior members?" I think that if this happened, it
Lucas> would be very healthy for the TC.

I think such discussions would be good.

I don't think this conflicts with what I said about term limits earlier
this morning.
While I do think that 4-5 years is a good term length, I do think a lot
of churn can be bad, and 2-r makes a lot of sense to me for the reason
you give above.


--Sam

[Scott Kitterman]

Post by Sam Hartman
Lucas> (Elaborating on the context a bit given the discussion spread
Lucas> over some time -- two options have been proposed: - expire
Lucas> the 2 most senior members - expire the 2-R most senior
Lucas> members, with R the number of resignations over the last 12
Lucas> months)
Lucas> What we want to encourage is, I think, a sane and healthy
Lucas> members would just resign when they feel that bringing fresh
Lucas> manpower is profitable to the TC overall. However, there's a
Lucas> number of social reasons why this doesn't work so well.
Lucas> which might weaken the TC a bit too much. With the '2-R'
Lucas> schema, I have an additional incentive to resign: if I
Lucas> resign, I 'save' someone else more senior than me from
Lucas> getting expired. (And given I'm not so active anymore,
Lucas> instead of weakening the TC further, my resignation might
Lucas> even reinforce the TC).
Lucas> The '2-R' schema could even result in an internal TC
Lucas> discussion: "OK, the Project wants us to change two
Lucas> members. Are there people that feel like resigning now? Or
Lucas> should we just fallback to the default of expiring the two
Lucas> most senior members?" I think that if this happened, it
Lucas> would be very healthy for the TC.
I think such discussions would be good.
I don't think this conflicts with what I said about term limits earlier
this morning.
While I do think that 4-5 years is a good term length, I do think a lot
of churn can be bad, and 2-r makes a lot of sense to me for the reason
you give above.

[responding here because it's the end of the thread right now, not sure where
better]

Given that we've just had significant turnover in th TC, might it not make
sense to have the first term expirations set for a year or two from now? That
would keep this discussion well separated from any current turmoil and I think
it's reasonably clear that we don't, at the moment, suffer from a lack of
turnover in the TC (which AIUI is the motivation for this).

Scott K

[Stefano Zacchiroli]

Post by Scott Kitterman
Given that we've just had significant turnover in th TC, might it not make
sense to have the first term expirations set for a year or two from now? That
would keep this discussion well separated from any current turmoil and I think
it's reasonably clear that we don't, at the moment, suffer from a lack of
turnover in the TC (which AIUI is the motivation for this).

I was reluctant to propose this myself, but I do agree with you. The
*preexisting* problem of basically 0 turnover in the ctte is basically
solved and AFAICT for reasons completely independent from the ongoing
work on this GR. What still needs to be put in place is some rule that
avoid the problem reappears in the future.

So I would personally be in favor of dropping entirely the transitional
measure----FWIW Lucas (original proposer of the measure) has also hinted
at that possibility in <***@xanadu.blop.info>.

I do not understand the reason why AJ in
<***@master.debian.org> stated that he would favor
either of the "2" and "2-R" model over "2 without transitional measure".
So I might be missing something.

I welcome comments on whether people would be against having the "2"
model without the transitional measure, as suggested by Scott (and
Lucas). It certainly is an option that scores very well on the Occam's
Razor scale.

I will note down this in TODO.

Cheers.

[ As a more general status update: as it seems that both the "2" and
"2-R" model has significant support, I'm working on integrating "2-R"
in my Git repo as a separate proposal, so that we can easily vote on
both if they both receive enough seconds (or are proposed by the
DPL. More on this in a separate mail. ]

[Stefano Zacchiroli]

Post by Sam Hartman
While I do think that 4-5 years is a good term length, I do think a
lot of churn can be bad, and 2-r makes a lot of sense to me for the
reason you give above.

Not sure if you've read it Sam, but just in case: I find Phil's example
in <***@hands.com> to be most convincing against the 2-R
model in general. If, OTOH, your objective is avoid churn in the *short*
term, then dropping the transitional measure as mentioned by Scott and
Lucas would be more than enough. (And, in fact, we can even have
intermediate solutions like bumping the transitional measure from 1
months to 6.)

Cheers.

[Hubert Chathi]

Post by Stefano Zacchiroli

Post by Sam Hartman
While I do think that 4-5 years is a good term length, I do think a
lot of churn can be bad, and 2-r makes a lot of sense to me for the
reason you give above.

Not sure if you've read it Sam, but just in case: I find Phil's
the 2-R model in general. ...

I think someone had already mentioned this option, but one way to avoid
the effects of that issue, for those who want to avoid always expiring 2
members, is to expire 2-S members, where S is the number of members who
have resigned since the last review period, and who would have been
expired at the current review period if they had not resigned. So the
resignation of a junior member would not affect the expiry process, but
the resignation of a senior member would mean that we would have one
less expiry.
--
Hubert Chathi <***@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

[Lucas Nussbaum]

Post by Hubert Chathi

Post by Stefano Zacchiroli

Post by Sam Hartman
While I do think that 4-5 years is a good term length, I do think a
lot of churn can be bad, and 2-r makes a lot of sense to me for the
reason you give above.

Not sure if you've read it Sam, but just in case: I find Phil's
the 2-R model in general. ...

I think someone had already mentioned this option, but one way to avoid
the effects of that issue, for those who want to avoid always expiring 2
members, is to expire 2-S members, where S is the number of members who
have resigned since the last review period, and who would have been
expired at the current review period if they had not resigned. So the
resignation of a junior member would not affect the expiry process, but
the resignation of a senior member would mean that we would have one
less expiry.
However, another option would be "2-R'" where only retirements of people
who would otherwise be candidates for expiry count. So Russ quitting
after serving 5.8 years would count, but Colin resigning after serving
"just" 3.2 years wouldn't. That doesn't seem like it's especially easy
to specify either though.

Note that there are two subtle variants:
- only resignations from people > 4.5y count in R' (Anthony's)
- only resignations from people who would have been expired count in S
(yours)

Lucas

[Philip Hands]

Post by Lucas Nussbaum

Post by Hubert Chathi

Post by Stefano Zacchiroli

Post by Sam Hartman
While I do think that 4-5 years is a good term length, I do think a
lot of churn can be bad, and 2-r makes a lot of sense to me for the
reason you give above.

Not sure if you've read it Sam, but just in case: I find Phil's
the 2-R model in general. ...

I think someone had already mentioned this option, but one way to avoid
the effects of that issue, for those who want to avoid always expiring 2
members, is to expire 2-S members, where S is the number of members who
have resigned since the last review period, and who would have been
expired at the current review period if they had not resigned. So the
resignation of a junior member would not affect the expiry process, but
the resignation of a senior member would mean that we would have one
less expiry.
However, another option would be "2-R'" where only retirements of people
who would otherwise be candidates for expiry count. So Russ quitting
after serving 5.8 years would count, but Colin resigning after serving
"just" 3.2 years wouldn't. That doesn't seem like it's especially easy
to specify either though.

- only resignations from people > 4.5y count in R' (Anthony's)
- only resignations from people who would have been expired count in S
(yours)

FWIW I think either of those deals with the concerns I raised, as it's
going to be way too much effort to game that, and I cannot see why
anyone would want to bother to do so.

Cheers, Phil.

[Sam Hartman]

Post by Sam Hartman
While I do think that 4-5 years is a good term length, I do think
a lot of churn can be bad, and 2-r makes a lot of sense to me for
the reason you give above.

Stefano> Not sure if you've read it Sam, but just in case: I find
Stefano> Phil's example in <***@hands.com> to be most
Stefano> convincing against the 2-R model in general. If, OTOH, your
Stefano> objective is avoid churn in the *short* term, then dropping
Stefano> the transitional measure as mentioned by Scott and Lucas
Stefano> would be more than enough. (And, in fact, we can even have
Stefano> intermediate solutions like bumping the transitional
Stefano> measure from 1 months to 6.)

My concern is long-term churn.
I don't find that message compelling and would definitely second an
amendment with 2-r.