Technical committee resolution

[Anthony Towns]

Hello world,

I've been thinking for a while [0] it'd be good to do a real revamp of
the tech ctte. It's been pretty dysfunctional since forever, there's
not much that can be done internally to improve things, and since it's
almost entirely self-appointed and has no oversight whatsoever the only
way to change things externally is constitutional change.

Here's an idea. I'd rather not push it very much, but since no one else
seems like proposing much change here; I thought I'd at least go that far.

Composition
~~~~~~~~~~~

======================================================================
Replace section "6.2. Composition" (of the tech-ctte) with:

6.2. Composition

   1. The Technical Committee consists of up to 8 Developers.

   2. When there are fewer than 8 members, the Project Leader may appoint
      any Developer to to the Technical Committee provided that at
      least one existing member of the Technical Committee supports the
      appointment, or there are no existing members of the Technical
      Committee.

   3. When there are 8 members, the Project Leader may appoint any
      Developer to the Technical Committee replacing the longest serving
      current member, provided there have not already been 2 or more
      appointments to the Technical Committee during the current Leader's
      term.

   4. Members of the Technical Committee may resign at any time by giving
      notice to the other members and the Project Leader.

   5. As the primary duties of the Technical Committee is to resolve
      difficult and often contentious technical decisions, the Project
      Leader should evaluate potential members on both their technical
      ability and also their ability to build a consensus around technical
      solutions.

Remove 6.1(6) ("The Technical Committee may ... Together with the Project
Leader, appoint new members to itself or remove existing members.").

Replace 5.1(6) ("The Project Leader may ... Together with the Technical
Committee, appoint new members to the Committee.") with "Appoint new
members to the Technical Committee."
======================================================================

The idea is to encourage DPLs to appoint two new members during their
term, so we get new blood in the committee, and people don't get stuck in
the committee until they eventually fade away from the project. The last
appointment to the committee at the moment was during Branden's term as
DPL; and as best I can tell, Ian and Manoj have been on the ctte for its
entire existance. We've got a pretty good depth of talent, and there's no
reason to monopolise the vast powers of the technical committee the way
we are. There's nothing stopping the DPL from suggesting the oldest two
TC members resigning, then reappointing them (so they become the youngest
two TC members), if we actually do want to keep particular people on.

That removes the possibility for the tech ctte and the DPL combined
to remove a member of the tech ctte; that's something that's only ever
been used when people have vanished, and if there'd been two new members
appointed each year replacing people, wouldn't have been needed.

Overruling maintainers
~~~~~~~~~~~~~~~~~~~~~~

======================================================================
Change 6.1(4) from "Overrule a Developer (requires a 3:1 majority)." to
"Overrule a Developer (requires a 2.5:1 majority)."
======================================================================

Given the way vote counting is defined later, that means that 1 vote
for FD is the same as 2.5 votes for overruling a developer; so 3 votes
(or more) in favour are required to defeat 1 vote against, and 6 votes
in favour are required to defeat 2 votes against (since there are only
at most 8 members, you can't have 7 votes for and 2 against; and 3 votes
against can't be defeated; the Chairman's casting vote also can't save
an option that's got 5 votes for and 2 against).

Since this has caused some angst, it seems sensible to do it at the same
time.

Cheers,
aj

[0] http://lists.debian.org/debian-vote/2005/03/msg00518.html

[Anthony Towns]

On Mon, Mar 10, 2008 at 01:48:28PM +1100, Anthony Towns wrote:
>    5. As the primary duties of the Technical Committee is to resolve
                       ^^^^^^

That should be "duty", before anyone else points it out... (Props to
Hubert Chathi)

Cheers,
aj


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Barth]

* Anthony Towns (aj@...) [080310 03:49]:
>    3. When there are 8 members, the Project Leader may appoint any
>       Developer to the Technical Committee replacing the longest serving
>       current member, provided there have not already been 2 or more
>       appointments to the Technical Committee during the current Leader's
>       term.

> The idea is to encourage DPLs to appoint two new members during their
> term, so we get new blood in the committee, and people don't get stuck in
> the committee until they eventually fade away from the project.

Though I agree the idea in general, I don't think mechanically replacing
the two longest serving members is a good idea. It might be better to
allow the DPL to just replace any two members of the ctte. On the other
hand, I would keep the current addition policy "as default".

So, I would replace your 2. with the current text, and your 3. with:
  3. During any DPL term, the DPL might appoint up to two new members
     unilaterally. He might replace an existing member, or add them as
     additional members at his choice, provided the maximum number of eight
     members is not exceeded.

> ======================================================================
> Change 6.1(4) from "Overrule a Developer (requires a 3:1 majority)." to
> "Overrule a Developer (requires a 2.5:1 majority)."
> ======================================================================
>
> Given the way vote counting is defined later, that means that 1 vote
> for FD is the same as 2.5 votes for overruling a developer; so 3 votes
> (or more) in favour are required to defeat 1 vote against, and 6 votes
> in favour are required to defeat 2 votes against (since there are only
> at most 8 members, you can't have 7 votes for and 2 against; and 3 votes
> against can't be defeated; the Chairman's casting vote also can't save
> an option that's got 5 votes for and 2 against).

I would rather prefer to fix the definition that 3:1 majority *really*
is a 3:1 majority.


Cheers,
Andi
--
  http://home.arcor.de/andreas-barth/


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[David Newgas]

On Mon, 2008-03-10 at 13:48 +1100, Anthony Towns wrote:
>    3. When there are 8 members, the Project Leader may appoint any
>       Developer to the Technical Committee replacing the longest serving
>       current member, provided there have not already been 2 or more

Perhaps "such" should be insereted here, so that appointments under
clause 2 do not count towards the clause 3 appointment limit?

>       appointments to the Technical Committee during the current Leader's
>       term.

(IANADD)

Cheers,
--
David Newgas


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lars Wirzenius-5]

On ma, 2008-03-10 at 13:48 +1100, Anthony Towns wrote:
> The idea is to encourage DPLs to appoint two new members during their
> term, so we get new blood in the committee,

Would it then be better to limit the term of tech-ctte members to, say,
two years? Or three years? With the option that they may be
re-appointed/elected/selected/whatever immediately, of course. This
would force the consideration of new blood rather than making it
dependent on the whim of the DPL.



--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Anthony Towns]

On Mon, Mar 10, 2008 at 11:19:35AM +0200, Lars Wirzenius wrote:
> On ma, 2008-03-10 at 13:48 +1100, Anthony Towns wrote:
> > The idea is to encourage DPLs to appoint two new members during their
> > term, so we get new blood in the committee,
> Would it then be better to limit the term of tech-ctte members to, say,
> two years? Or three years?

Two years would mean four new TC members each year, which would be a lot
of churn; three years would be 2.7 members on average.

The other thing about that is our current membership is something like:

        Bdale (chair) - over six years
        Andi          - two years two months
        Ian           - ten years?
        Steve         - two years two months
        Manoj         - ten years?
        Anthony       - two years two months

A two year limit would completely refresh the tech-ctte; a three year
limit would refresh half of it now, the other half by the end of the year.

That'd also make the DPL likely to just reappoint existing members, which
would be a bad habit to get into.

> With the option that they may be
> re-appointed/elected/selected/whatever immediately, of course. This
> would force the consideration of new blood rather than making it
> dependent on the whim of the DPL.

I'd suspect having the ctte suddenly disappear would force the DPL to
reappoint the previous members immediately and lose the chance to spend
some time considering new blood; ymmv.

Cheers,
aj

[Josselin Mouette]

Le lundi 10 mars 2008 à 09:21 +0100, Andreas Barth a écrit :
> * Anthony Towns (aj@...) [080310 03:49]:
> > The idea is to encourage DPLs to appoint two new members during their
> > term, so we get new blood in the committee, and people don't get stuck in
> > the committee until they eventually fade away from the project.
>
> Though I agree the idea in general, I don't think mechanically replacing
> the two longest serving members is a good idea. It might be better to
> allow the DPL to just replace any two members of the ctte.

How about considering ctte members having failed to participate in two
consecutive decisions as having resigned?

> On the other
> hand, I would keep the current addition policy "as default".

Agreed. The DPL could have the ability to sneak in, but only when the
current process doesn’t work for some reason.

--
 .''`.
: :' :      We are debian.org. Lower your prices, surrender your code.
`. `'       We will add your hardware and software distinctiveness to
  `-        our own. Resistance is futile.

[MJ Ray-2]

Anthony Towns <aj@...> wrote:
>    1. The Technical Committee consists of up to 8 Developers.

Why drop the suggested minimum of 4?  Does this mean a one-man
tech-ctte would be fine?

>    3. When there are 8 members, the Project Leader may appoint any
>       Developer to the Technical Committee replacing the longest serving
>       current member, provided there have not already been 2 or more
>       appointments to the Technical Committee during the current Leader's
>       term.

What should happen in a tie of service length?

Is it necessary to specify the 8 in more than one place?

> [...] There's nothing stopping the DPL from suggesting the oldest two
> TC members resigning, then reappointing them (so they become the youngest
> two TC members), if we actually do want to keep particular people on. [...]

Is that healthy?  Having a minimum break is pretty common on other
groups and might help keep things fresh.

Andreas Barth <aba@...> wrote:
> So, I would replace your 2. with the current text, and your 3. with:
>   3. During any DPL term, the DPL might appoint up to two new members
>      unilaterally. He might replace an existing member, or add them as
>      additional members at his choice, provided the maximum number of eight
>      members is not exceeded.

I don't think that makes sense.  s/might/may/ or s/might/can/ please.

I'd also s/eight// because there seems no need to repeat the maximum
size and it could make future amendments smaller.

Josselin Mouette <joss@...> wrote:
> How about considering ctte members having failed to participate in two
> consecutive decisions as having resigned?

Maybe three rather than two, but I like that idea better than maximum
term lengths between appointments, FWIW.

Regards,
--
MJ Ray http://mjr.towers.org.uk/email.html tel:[phone] -
Webmaster-developer, statistician, sysadmin, online shop builder,
consumer and workers co-operative member http://www.ttllp.co.uk/ -
Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Barth]

* MJ Ray (mjr@...) [080310 12:46]:
> Andreas Barth <aba@...> wrote:
> > So, I would replace your 2. with the current text, and your 3. with:
> >   3. During any DPL term, the DPL might appoint up to two new members
> >      unilaterally. He might replace an existing member, or add them as
> >      additional members at his choice, provided the maximum number of eight
> >      members is not exceeded.
>
> I don't think that makes sense.  s/might/may/ or s/might/can/ please.

may is probably better - that was german english, sorry.

> I'd also s/eight// because there seems no need to repeat the maximum
> size and it could make future amendments smaller.

Agreed.



Cheers,
Andi
--
  http://home.arcor.de/andreas-barth/


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Manoj Srivastava]

On Mon, 10 Mar 2008 13:48:28 +1100, Anthony Towns
<aj@...> said:  

>    3. When there are 8 members, the Project Leader may appoint any
>       Developer to the Technical Committee replacing the longest
>       serving current member, provided there have not already been 2
>       or more appointments to the Technical Committee during the
>       current Leader's term.

        This is a bad idea. The length of term of service is a bad
 indicator of utility of the member to Debian. Consider this scenario:
 what if the longest serving members are the most active members of the
 team, and the newer members being mostly MIA, you have just degraded
 the tech ctte's utility.

        The grounds for removing people should be whether they are
 present at all (which is the criteria used when we last shed  people
 from the ctte), or some measure of the quality of contribution.

        Most of the arguments posited against term limits apply here;
 because this is just term limits in disguise (with a term limit of 4
 years).

        manoj
--
"Love your country but never trust its government." from a hand-painted
road sign in central Pennsylvania
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Russ Allbery-2]

Anthony Towns <aj@...> writes:

> I've been thinking for a while [0] it'd be good to do a real revamp of
> the tech ctte. It's been pretty dysfunctional since forever, there's not
> much that can be done internally to improve things, and since it's
> almost entirely self-appointed and has no oversight whatsoever the only
> way to change things externally is constitutional change.

I'd be interested in hearing more specifics on how you think it's
disfunctional and why you think this change will fix the problems that you
see.  I think I have a vague idea of how you're connecting the dots, but
I'd rather not try to read your mind.  :)

--
Russ Allbery (rra@...)               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Joerg Jaspert]

On 11320 March 1977, Anthony Towns wrote:

>    1. The Technical Committee consists of up to 8 Developers.

How about making that a 9, and then have members with defined service
times, so you end up with 3 new members every year?

With the other options as you wrote them that might mean the same 3 get
appointed, if they did good work and the DPL wants to keep them, but it
would give a maximum time a non/low-active member would be on.


Then add some rule that missing two (or three, or whatever number) votes
the TC did means an immediate removal, with the DPL appointing someone
new for the remaining time of the "kicked" member.

Where missed would count unless one gives a good reason why one doesnt
vote on it. (Vacation, ill, personally involved in the case, like Ian
right now would be with dpkg, ...)

>    4. Members of the Technical Committee may resign at any time by giving
>       notice to the other members and the Project Leader.

And that would then also leave the DPL the option to appoint an interim
member.

Of course such short appointments shouldn't be done if its mostly
senseless, like for a period of 3 til 6 months, unless the committee
would drop below the 4 members.


--
bye, Joerg
"Gna, schon wieder Seti [...] Dabei ist es schon schwierig genug, auf
*diesem* Planeten intelligentes Leben zu finden."
[Charly Kuehnast in dasr]


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Michael Banck]

On Mon, Mar 10, 2008 at 09:57:15AM -0500, Manoj Srivastava wrote:

> On Mon, 10 Mar 2008 13:48:28 +1100, Anthony Towns
> <aj@...> said:  
>
> >    3. When there are 8 members, the Project Leader may appoint any
> >       Developer to the Technical Committee replacing the longest
> >       serving current member, provided there have not already been 2
> >       or more appointments to the Technical Committee during the
> >       current Leader's term.
>
>         This is a bad idea. The length of term of service is a bad
>  indicator of utility of the member to Debian. Consider this scenario:
>  what if the longest serving members are the most active members of the
>  team, and the newer members being mostly MIA, you have just degraded
>  the tech ctte's utility.
>
>         The grounds for removing people should be whether they are
>  present at all (which is the criteria used when we last shed  people
>  from the ctte), or some measure of the quality of contribution.
>
>         Most of the arguments posited against term limits apply here;
>  because this is just term limits in disguise (with a term limit of 4
>  years).

AJ explicitely commented that it would be possible for the DPL to
remove/reappoint somebody at one go, essentially making them the
youngest standing member on the TC and recognizing their utility.


Michael


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Manoj Srivastava]

On Mon, 10 Mar 2008 18:02:20 +0100, Michael Banck <mbanck@...> said:

> On Mon, Mar 10, 2008 at 09:57:15AM -0500, Manoj Srivastava wrote:
>> On Mon, 10 Mar 2008 13:48:28 +1100, Anthony Towns
>> <aj@...> said:
>>
>> >    3. When there are 8 members, the Project Leader may appoint any
>> >       Developer to the Technical Committee replacing the longest
>> >       serving current member, provided there have not already been
>> >       2 or more appointments to the Technical Committee during the
>> >       current Leader's term.
>>
>> This is a bad idea. The length of term of service is a bad indicator
>> of utility of the member to Debian. Consider this scenario: what if
>> the longest serving members are the most active members of the team,
>> and the newer members being mostly MIA, you have just degraded the
>> tech ctte's utility.
>>
>> The grounds for removing people should be whether they are present at
>> all (which is the criteria used when we last shed people from the
>> ctte), or some measure of the quality of contribution.
>>
>> Most of the arguments posited against term limits apply here; because
>> this is just term limits in disguise (with a term limit of 4 years).

> AJ explicitely commented that it would be possible for the DPL to
> remove/reappoint somebody at one go, essentially making them the
> youngest standing member on the TC and recognizing their utility.

        Which brings to mind the other, subtle impact of this proposal:
 this removes one of the Debian institutions that was not under the
 thumb of the project leader; and makes the line of command more
 central, making the project leader more powerful than before.

        I am uncertain whether this is good or bad; but thinking back to
 the times of Bruce, central authority with only a heavy weight
 impeachment kind of process (even if term limited by one year) was
 something people back then were somewhat leery of, so not everything in
 Debian is under direct control or authority of a single office bearer.

        I have no idea is I am the only one left that is uneasy about
 such concentration of authority, or whether my fears are overblown, but
 I do think this aspect merits pondering.

        manoj
--
Moebius always does it on the same side.
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Manoj Srivastava]

On Mon, 10 Mar 2008 17:49:02 +0100, Joerg Jaspert <joerg@...> said:

> On 11320 March 1977, Anthony Towns wrote:
>> 1. The Technical Committee consists of up to 8 Developers.

> How about making that a 9, and then have members with defined service
> times, so you end up with 3 new members every year?

        Where is the use case for added churn and loss of institutional
 memory?  Is there an addded benefit for the tech ctte, just added new
 embers, with no effort made to ensure responsiveness of new members?

        With new members added routinely, is there any mechanism to
 ensure the new members are indeed technically competent, and not just
 chums of the DPL?

        Are these changes actually addressing the problems or
 dysfunction of the tech ctte, or we just making chnages for changes
 sake?  Which particular dysfunction is being addressed?  Do we have
 reason to believe that churn will solve that dysfunction?

        Why is the DPL the proper mechanism to bring forth this change?

        manoj
--
Trespassers will be shot.  Survivors will be SHOT AGAIN!
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Florian Weimer]

* Andreas Barth:

> So, I would replace your 2. with the current text, and your 3. with:
>   3. During any DPL term, the DPL might appoint up to two new members
>      unilaterally. He might replace an existing member, or add them as
>      additional members at his choice, provided the maximum number of eight
>      members is not exceeded.

This is ambiguous.  Can the DPL replace two members or just one?

(And, BTW, does the Constitution make gender assumptions WRT to the DPL
in other places? 8-)


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Barth]

* Florian Weimer (fw@...) [080310 22:27]:
> * Andreas Barth:
>
> > So, I would replace your 2. with the current text, and your 3. with:
> >   3. During any DPL term, the DPL might appoint up to two new members
> >      unilaterally. He might replace an existing member, or add them as
> >      additional members at his choice, provided the maximum number of eight
> >      members is not exceeded.
>
> This is ambiguous.  Can the DPL replace two members or just one?

I thought of two - do you have a better text available.

> (And, BTW, does the Constitution make gender assumptions WRT to the DPL
> in other places? 8-)

s/He/The DPL/

Cheers,
Andi
--
  http://home.arcor.de/andreas-barth/


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact