Debian Bug report logs - #636783
proposed constitution fix for super-majority within the tech ctte

Package: tech-ctte; Maintainer for tech-ctte is Technical Committee <debian-ctte@lists.debian.org>;

Reported by: Andreas Barth <aba@not.so.argh.org>

Date: Fri, 5 Aug 2011 21:51:02 UTC

Severity: normal

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Fri, 05 Aug 2011 21:51:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org>:
New Bug report received and forwarded. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 05 Aug 2011 21:51:05 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@not.so.argh.org>
To: submit@bugs.debian.org
Subject: proposed constitution fix for super-majority within the tech ctte
Date: Fri, 5 Aug 2011 23:48:27 +0200
Package: tech-ctte

Hi,

I'm asking the tech ctte to propose the following GR. Reason for going
via the tech ctte is that this is really only relevant for the tech
ctte.

A.6.3.2 currently says:
| An option A defeats the default option D by a majority ratio N, if
| V(A,D) is strictly greater than N * V(D,A). 

This means that if we need 3:1 majority, we still need more than 3:1
majority, which is with only at maximum 7 people voting relevant. (The
same applies for normal GRs, but with the number of developers, it's
way less relevant.) (If we are 8 people, this statement means that if
6 people vote in favor, and 2 against, we haven't reached
3:1-majority. Which is of course wrong.)


Therefor, I propose to replace this by:
A.6.3.2:
| An option A defeats the default option D by a majority ratio of 1,
| if V(A,D) is strictly greater than V(D,A). An option A defeats the
| default option D by a majority ratio of N, if V(A,D) is equals or
| greater than N * V(D,A).

(I don't like the ways it's written - better ideas?)




Andi




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Sat, 06 Aug 2011 06:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Anthony Towns <aj@erisian.com.au>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 06 Aug 2011 06:03:03 GMT) Full text and rfc822 format available.

Message #10 received at submit@bugs.debian.org (full text, mbox):

From: Anthony Towns <aj@erisian.com.au>
To: Andreas Barth <aba@not.so.argh.org>, 636783@bugs.debian.org, debian-ctte@lists.debian.org
Cc: submit@bugs.debian.org
Subject: Re: Bug#636783: proposed constitution fix for super-majority within the tech ctte
Date: Sat, 6 Aug 2011 16:01:20 +1000
On Sat, Aug 6, 2011 at 07:48, Andreas Barth <aba@not.so.argh.org> wrote:
> Therefor, I propose to replace this by:
>
> A.6.3.2:
> | An option A defeats the default option D by a majority ratio of 1,
> | if V(A,D) is strictly greater than V(D,A). An option A defeats the
> | default option D by a majority ratio of N, if V(A,D) is equals or
> | greater than N * V(D,A).
> (I don't like the ways it's written - better ideas?)

I don't think it makes sense to have different rules for when M=1 to
when M=!1; so I'd suggest having a separate "supermajority ratio" that
does the >= thing, and is never =1.
Here's a possible patch (fingers crossed that gmail doesn't screw it
up too badly)

 --- /usr/share/doc/debian/constitution.txt	2010-01-12 07:14:08.000000000 +1000
+++ supercons.txt	2011-08-06 15:56:35.593975118 +1000
@@ -81,11 +81,11 @@

    Together, the Developers may:
     1. Appoint or recall the Project Leader.
-    2. Amend this constitution, provided they agree with a 3:1 majority.
+    2. Amend this constitution, provided they agree with a 3:1 supermajority.
     3. Make or override any decision authorised by the powers of the
        Project Leader or a Delegate.
     4. Make or override any decision authorised by the powers of the
-       Technical Committee, provided they agree with a 2:1 majority.
+       Technical Committee, provided they agree with a 2:1 supermajority.
     5. Issue, supersede and withdraw nontechnical policy documents and
        statements.
        These include documents describing the goals of the project, its
@@ -97,7 +97,7 @@
             critical to the Project's mission and purposes.
          2. The Foundation Documents are the works entitled "Debian Social
             Contract" and "Debian Free Software Guidelines".
-         3. A Foundation Document requires a 3:1 majority for its
+         3. A Foundation Document requires a 3:1 supermajority for its
             supersession. New Foundation Documents are issued and existing
             ones withdrawn by amending the list of Foundation Documents in
             this constitution.
@@ -256,10 +256,10 @@
     3. Make a decision when asked to do so.
        Any person or body may delegate a decision of their own to the
        Technical Committee, or seek advice from it.
-    4. Overrule a Developer (requires a 3:1 majority).
+    4. Overrule a Developer (requires a 3:1 supermajority).
        The Technical Committee may ask a Developer to take a particular
        technical course of action even if the Developer does not wish to;
-       this requires a 3:1 majority. For example, the Committee may
+       this requires a 3:1 supermajority. For example, the Committee may
        determine that a complaint made by the submitter of a bug is
        justified and that the submitter's proposed solution should be
        implemented.
@@ -518,8 +518,6 @@
        ballot that includes an option for the original resolution, each
        amendment, and the default option (where applicable).
     2. The default option must not have any supermajority requirements.
-       Options which do not have an explicit supermajority requirement
-       have a 1:1 majority requirement.
     3. The votes are counted according to the rules in A.6. The default
        option is "Further Discussion", unless specified otherwise.
     4. In cases of doubt the Project Secretary shall decide on matters of
@@ -561,13 +559,13 @@
        default option which do not receive at least R votes ranking that
        option above the default option are dropped from consideration.
     3. Any (non-default) option which does not defeat the default option
-       by its required majority ratio is dropped from consideration.
+       is dropped from consideration.
          1. Given two options A and B, V(A,B) is the number of voters who
             prefer option A over option B.
-         2. An option A defeats the default option D by a majority ratio
-            N, if V(A,D) is strictly greater than N * V(D,A).
-         3. If a supermajority of S:1 is required for A, its majority
-            ratio is S; otherwise, its majority ratio is 1.
+         2. An option A defeats the default option D provided that:
+              (a) V(A,D) is strictly greater than V(D,A); and
+              (b) if a supermajority of N:1 is required, then V(A,D)
+                  is greater than or equal to N * V(D/A).
     4. From the list of undropped options, we generate a list of pairwise
        defeats.
          1. An option A defeats an option B, if V(A,B) is strictly greater
@@ -601,8 +599,8 @@
    When the Standard Resolution Procedure is to be used, the text which
    refers to it must specify what is sufficient to have a draft resolution
    proposed and/or sponsored, what the minimum discussion period is, and
-   what the voting period is. It must also specify any supermajority
-   and/or the quorum (and default option) to be used.
+   what the voting period is. It must also specify the default option to be
+   used, the quorum required, and any supermajority requirements.

 B. Use of language and typography

Cheers,
aj

--
Anthony Towns <aj@erisian.com.au>




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Sat, 06 Aug 2011 06:03:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Anthony Towns <aj@erisian.com.au>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 06 Aug 2011 06:03:08 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Sat, 06 Aug 2011 11:51:31 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 06 Aug 2011 11:51:32 GMT) Full text and rfc822 format available.

Message #20 received at 636783@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@not.so.argh.org>
To: 636783@bugs.debian.org
Subject: Re: Bug#636783: proposed constitution fix for super-majority within the tech ctte
Date: Sat, 6 Aug 2011 13:48:48 +0200
* Anthony Towns (aj@azure.humbug.org.au) [110806 11:31]:
> On Sat, Aug 6, 2011 at 07:48, Andreas Barth <aba@not.so.argh.org> wrote:
> > Therefor, I propose to replace this by:
> >
> > A.6.3.2:
> > | An option A defeats the default option D by a majority ratio of 1,
> > | if V(A,D) is strictly greater than V(D,A). An option A defeats the
> > | default option D by a majority ratio of N, if V(A,D) is equals or
> > | greater than N * V(D,A).
> > (I don't like the ways it's written - better ideas?)
> 
> I don't think it makes sense to have different rules for when M=1 to
> when M=!1; so I'd suggest having a separate "supermajority ratio" that
> does the >= thing, and is never =1.
> Here's a possible patch (fingers crossed that gmail doesn't screw it
> up too badly)

Actually, we could shrink that to:

> -         2. An option A defeats the default option D by a majority ratio
> -            N, if V(A,D) is strictly greater than N * V(D,A).
> +         2. An option A defeats the default option D provided that:
> +              (a) V(A,D) is strictly greater than V(D,A); and
> +              (b) if a supermajority of N:1 is required, then V(A,D)
> +                  is greater than or equal to N * V(D/A).

Which I think is better than my proposal.

(Not that I think the other changes are wrong - but somehow I have an
uneasy feeling about editorial-only changes to the constitution.)


Andi




Information stored :
Bug#636783; Package tech-ctte. (Sun, 14 Aug 2011 22:15:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Peter Palfrader <weasel@debian.org>:
Extra info received and filed, but not forwarded. (Sun, 14 Aug 2011 22:15:06 GMT) Full text and rfc822 format available.

Message #25 received at 636783-quiet@bugs.debian.org (full text, mbox):

From: Peter Palfrader <weasel@debian.org>
To: Anthony Towns <aj@erisian.com.au>, 636783-quiet@bugs.debian.org
Subject: Re: Bug#636783: proposed constitution fix for super-majority within the tech ctte
Date: Mon, 15 Aug 2011 00:11:36 +0200
Hey,

On Sat, 06 Aug 2011, Anthony Towns wrote:

> -         2. An option A defeats the default option D by a majority ratio
> -            N, if V(A,D) is strictly greater than N * V(D,A).
> -         3. If a supermajority of S:1 is required for A, its majority
> -            ratio is S; otherwise, its majority ratio is 1.
> +         2. An option A defeats the default option D provided that:
> +              (a) V(A,D) is strictly greater than V(D,A); and
> +              (b) if a supermajority of N:1 is required, then V(A,D)
> +                  is greater than or equal to N * V(D/A).
                                                     ^^^^^^
ITYM V(D,A), i.e. a comma seperates the two parameters of V.

Cheers,
-- 
                           |  .''`.       ** Debian **
      Peter Palfrader      | : :' :      The  universal
 http://www.palfrader.org/ | `. `'      Operating System
                           |   `-    http://www.debian.org/




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Sat, 20 Aug 2011 14:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 20 Aug 2011 14:27:03 GMT) Full text and rfc822 format available.

Message #30 received at 636783@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@not.so.argh.org>
To: 636783@bugs.debian.org
Subject: Re: Bug#636783: proposed constitution fix for super-majority within the tech ctte
Date: Sat, 20 Aug 2011 16:23:59 +0200
* Peter Palfrader (weasel@debian.org) [110814 22:11]:
> Hey,
> 
> On Sat, 06 Aug 2011, Anthony Towns wrote:
> 
> > -         2. An option A defeats the default option D by a majority ratio
> > -            N, if V(A,D) is strictly greater than N * V(D,A).
> > -         3. If a supermajority of S:1 is required for A, its majority
> > -            ratio is S; otherwise, its majority ratio is 1.
> > +         2. An option A defeats the default option D provided that:
> > +              (a) V(A,D) is strictly greater than V(D,A); and
> > +              (b) if a supermajority of N:1 is required, then V(A,D)
> > +                  is greater than or equal to N * V(D/A).
>                                                      ^^^^^^
> ITYM V(D,A), i.e. a comma seperates the two parameters of V.

As I got no further comments from other people of the tech ctte, this
can only mean that everyone agrees with this version, or is not
interessted.

So, unless someone proposes another option, I intend to call for
votes in a week so that I know better which of the two options it is.


Andi




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Sat, 27 Aug 2011 16:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 27 Aug 2011 16:45:03 GMT) Full text and rfc822 format available.

Message #35 received at 636783@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: debian-ctte@lists.debian.org
Cc: 636783@bugs.debian.org
Subject: Re: Bug#636783: proposed constitution fix for super-majority within the tech ctte
Date: Sat, 27 Aug 2011 17:43:30 +0100
Andreas Barth writes ("Bug#636783: proposed constitution fix for super-majority within the tech ctte"):
> > > +         2. An option A defeats the default option D provided that:
> > > +              (a) V(A,D) is strictly greater than V(D,A); and
> > > +              (b) if a supermajority of N:1 is required, then V(A,D)
> > > +                  is greater than or equal to N * V(D/A).
> >                                                      ^^^^^^
> > ITYM V(D,A), i.e. a comma seperates the two parameters of V.
> 
> As I got no further comments from other people of the tech ctte, this
> can only mean that everyone agrees with this version, or is not
> interessted.

I think the version I quote (as amended) is the best.

> So, unless someone proposes another option, I intend to call for
> votes in a week so that I know better which of the two options it is.

However, there are a couple of other things that we maybe want to
think about including in our GR:

* Explicitly being allowed to have private discussions on the subject
  of who should maintain a particular package.  The options should be:
    - private discussions when we feel it appropriate
    - private discussions only for appointments and maintainerships
    - status quo

* Possibly increasing the maximum size of the committee.  I would be
  happy with 12, given the busy nature of the existing members.

* An advisory resolution which gives the project a way to formally
  give us some guidance on how ready we should be to overrule
  developers.  A wording something like:

    In the past the Technical Committee have been slow and reluctant
    to overrule a maintainer unless all the members are absolutely
    convinced that the maintainer's decision was wrong.

    Option A: This is the correct approach.

    Option B: TC members should be willing to vote to overrule
        if they feel that the maintainer's decision was wrong;
        the supermajority requirement is sufficient to guard
        against overruling in questionable cases.

If we do want to ask the developers to vote on any of these, we should
arrange that all the votes can be run concurrently.  Ideally on a
single ballot, but with multiple independent questions.

Ian.




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Mon, 19 Mar 2012 04:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 19 Mar 2012 04:12:03 GMT) Full text and rfc822 format available.

Message #40 received at 636783@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: 636783@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: Bug#636783: proposed constitution fix for super-majority within the tech ctte
Date: Sun, 18 Mar 2012 21:09:45 -0700
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> Andreas Barth writes:

>> As I got no further comments from other people of the tech ctte, this
>> can only mean that everyone agrees with this version, or is not
>> interessted.

> I think the version I quote (as amended) is the best.

I agree with that proposal and think it would be a worthwhile amendment.
I'd be happy to see someone drive this forward.

Andreas, did you want us to vote on whether to bring this forward as a GR,
or was this bug more in the way of a medium for discussion?

>> So, unless someone proposes another option, I intend to call for votes
>> in a week so that I know better which of the two options it is.

> However, there are a couple of other things that we maybe want to
> think about including in our GR:

Your message seems to have killed all further discussion of this.  :)

I would be happy to go forward with the GR to fix the supermajority rule
by itself, since I think it's uncontroversial and could be easily passed.
However, commenting on the other things you mention:

> * Explicitly being allowed to have private discussions on the subject
>   of who should maintain a particular package.  The options should be:
>     - private discussions when we feel it appropriate
>     - private discussions only for appointments and maintainerships
>     - status quo

This seems like a good idea, and I would tend to vote for private
discussions when we feel it appropriate.  Realistically, I don't see how
one can stop people from having private conversations anyway when they
know each other; it's just a natural thing for people to do, and those
discussions happen in person at DebConf or in other media that isn't
easily recorded even if we wanted to.

> * Possibly increasing the maximum size of the committee.  I would be
>   happy with 12, given the busy nature of the existing members.

If there are people interested in helping drive things to resolution, that
would be helpful, as we're not currently doing a stellar job on that
front.

> * An advisory resolution which gives the project a way to formally
>   give us some guidance on how ready we should be to overrule
>   developers.  A wording something like:

>     In the past the Technical Committee have been slow and reluctant
>     to overrule a maintainer unless all the members are absolutely
>     convinced that the maintainer's decision was wrong.

>     Option A: This is the correct approach.

>     Option B: TC members should be willing to vote to overrule
>         if they feel that the maintainer's decision was wrong;
>         the supermajority requirement is sufficient to guard
>         against overruling in questionable cases.

Hm.  That's interesting, yes.  I have no idea what the outcome of that
vote would be, and I'd be curious to see how it turned out.  I think this
should be a separate GR, though; I don't think it's really related to the
above procedural issues.

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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Mon, 19 Mar 2012 20:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 19 Mar 2012 20:21:03 GMT) Full text and rfc822 format available.

Message #45 received at 636783@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Andreas Barth <aba@ayous.org>
Cc: 636783@bugs.debian.org
Subject: Re: Bug#636783: proposed constitution fix for super-majority within the tech ctte
Date: Mon, 19 Mar 2012 13:16:42 -0700
Andreas Barth <aba@ayous.org> writes:
> * Russ Allbery (rra@debian.org) [120319 05:10]:

>> I would be happy to go forward with the GR to fix the supermajority rule
>> by itself, since I think it's uncontroversial and could be easily passed.

> Good. In that case I think we should just call for votes, and vote it,
> and do the other topics in different GRs?

I'd be fine with that personally.

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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Tue, 20 Mar 2012 11:42:12 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 20 Mar 2012 11:42:18 GMT) Full text and rfc822 format available.

Message #50 received at 636783@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 636783@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: Bug#636783: proposed constitution fix for super-majority within the tech ctte
Date: Tue, 20 Mar 2012 11:39:54 +0000
Russ Allbery writes ("Re: Bug#636783: proposed constitution fix for super-majority within the tech ctte"):
> > * Explicitly being allowed to have private discussions on the subject
> >   of who should maintain a particular package.  The options should be:
> >     - private discussions when we feel it appropriate
> >     - private discussions only for appointments and maintainerships
> >     - status quo
> 
> This seems like a good idea, and I would tend to vote for private
> discussions when we feel it appropriate.  Realistically, I don't see how
> one can stop people from having private conversations anyway when they
> know each other; it's just a natural thing for people to do, and those
> discussions happen in person at DebConf or in other media that isn't
> easily recorded even if we wanted to.

I think I agree.  Perhaps we should offer that as the only option for
change.

How about this:

  In Constitution 6.3 (wdiff -i):

    3. Public [-discussion and-] decision-making.

       [-Discussion,-]
       Draft resolutions and amendments, and votes by members
       of the committee, are made public on the Technical Committee public
       discussion list. There is no separate secretary for the Committee.

  Rationale:

  On occasion we have been asked to decide on controversial matters
  such as maintainership of packages.  Allowing the TC to officially
  hold private conversations will make it much easier for us to take
  on a mediation role, which necessarily involves talking to each side
  in private.

  It will also make it easier for people to informally seek the advice
  of the TC.  On a number of occasions recently, enquirers have
  emailed TC members' personal addreses to sound out our opinions.
  This has worked well; however it is not clear that Constitution
  permits it.  This situation should be regularised.

  Actual decisionmaking will still take place in public of course.

> > * Possibly increasing the maximum size of the committee.  I would be
> >   happy with 12, given the busy nature of the existing members.
> 
> If there are people interested in helping drive things to resolution, that
> would be helpful, as we're not currently doing a stellar job on that
> front.

I still think we should formally allocate issues to TC members as they
come in.

Do you agree that the maximum size should be increased ?  It would
look something like this perhaps:

  In Constitution 6.2(1) and (2), increase the maximum size of the
  Technical Committee from 8 to 12.

  Rationale:

  The TC is currently at its maximum size of 8.  However TC members
  tend to be very busy people so there is still something of a
  shortage of effort.  We would like to have the option to increase
  the size of the committee to see if that helps get decisions made in
  a more timely fashion.

> > * An advisory resolution which gives the project a way to formally
> >   give us some guidance on how ready we should be to overrule
> >   developers.  A wording something like:
> 
> >     In the past the Technical Committee have been slow and reluctant
> >     to overrule a maintainer unless all the members are absolutely
> >     convinced that the maintainer's decision was wrong.
> 
> >     Option A: This is the correct approach.
> 
> >     Option B: TC members should be willing to vote to overrule
> >         if they feel that the maintainer's decision was wrong;
> >         the supermajority requirement is sufficient to guard
> >         against overruling in questionable cases.
> 
> Hm.  That's interesting, yes.  I have no idea what the outcome of that
> vote would be, and I'd be curious to see how it turned out.  I think this
> should be a separate GR, though; I don't think it's really related to the
> above procedural issues.

Certainly, yes, but we should hold it concurrently.

Do you have any opinions about wording, rationale, etc. ?

Ian.




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Tue, 20 Mar 2012 18:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@ayous.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 20 Mar 2012 18:24:03 GMT) Full text and rfc822 format available.

Message #55 received at 636783@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@ayous.org>
To: 636783@bugs.debian.org
Subject: Re: Bug#636783: proposed constitution fix for super-majority within the tech ctte
Date: Tue, 20 Mar 2012 18:54:20 +0100
* Ian Jackson (ijackson@chiark.greenend.org.uk) [120320 13:01]:
> This would be in the form of a TC resolution along these lines:
> 
>   For the purposes of accepting or rejecting amendments to this GR
>   proposal, according to Constitution A.1(2), we delegate to <name>
>   the power to accept amendments, and to each of our other members the
>   power to veto the acceptance of amendments (as if each TC member was
>   a sponsor).  The Committee reserves the right to overrule, by means
>   of a TC resolution on whether to accept an amendment.

good point. Who?


Andi




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Tue, 20 Mar 2012 18:45:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 20 Mar 2012 18:45:06 GMT) Full text and rfc822 format available.

Message #60 received at 636783@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 636783@bugs.debian.org
Subject: Re: Bug#636783: proposed constitution fix for super-majority within the tech ctte
Date: Tue, 20 Mar 2012 11:43:37 -0700
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> I think I agree.  Perhaps we should offer that as the only option for
> change.

> How about this:

>   In Constitution 6.3 (wdiff -i):

>     3. Public [-discussion and-] decision-making.

>        [-Discussion,-]
>        Draft resolutions and amendments, and votes by members
>        of the committee, are made public on the Technical Committee public
>        discussion list. There is no separate secretary for the Committee.

>   Rationale:

>   On occasion we have been asked to decide on controversial matters
>   such as maintainership of packages.  Allowing the TC to officially
>   hold private conversations will make it much easier for us to take
>   on a mediation role, which necessarily involves talking to each side
>   in private.

>   It will also make it easier for people to informally seek the advice
>   of the TC.  On a number of occasions recently, enquirers have
>   emailed TC members' personal addreses to sound out our opinions.
>   This has worked well; however it is not clear that Constitution
>   permits it.  This situation should be regularised.

>   Actual decisionmaking will still take place in public of course.

This looks fine to me.

> I still think we should formally allocate issues to TC members as they
> come in.

I'm also okay with this, and I'm happy to take on more issues.  I'm trying
to drive our current issues through to completion as much as I can right
now, as you've probably noticed.

> Do you agree that the maximum size should be increased ?  It would
> look something like this perhaps:

I'm not sure on this.  To me, it hasn't felt like our problems have so
much been with manpower as with an unwillingness to just create a ballot
and vote on something.  The conversation drifts into silence rather than
resulting in a call for votes.  I think we should try to be better at
recognizing the point of diminishing returns and call for a vote, which
would let us handle things more efficiently.

Separately, though, I do agree with checking with the current TC members
to see if they have time to devote to the TC going forward.

>   In Constitution 6.2(1) and (2), increase the maximum size of the
>   Technical Committee from 8 to 12.

>   Rationale:

>   The TC is currently at its maximum size of 8.  However TC members
>   tend to be very busy people so there is still something of a
>   shortage of effort.  We would like to have the option to increase
>   the size of the committee to see if that helps get decisions made in
>   a more timely fashion.

I don't actually disagree with this, though, and I'd probably vote for it.
I'm just not sure it's horribly important.

>>>     In the past the Technical Committee have been slow and reluctant
>>>     to overrule a maintainer unless all the members are absolutely
>>>     convinced that the maintainer's decision was wrong.

>>>     Option A: This is the correct approach.

>>>     Option B: TC members should be willing to vote to overrule
>>>         if they feel that the maintainer's decision was wrong;
>>>         the supermajority requirement is sufficient to guard
>>>         against overruling in questionable cases.

>> Hm.  That's interesting, yes.  I have no idea what the outcome of that
>> vote would be, and I'd be curious to see how it turned out.  I think
>> this should be a separate GR, though; I don't think it's really related
>> to the above procedural issues.

> Certainly, yes, but we should hold it concurrently.

> Do you have any opinions about wording, rationale, etc. ?

I'm okay with the wording above, personally.

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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Tue, 20 Mar 2012 21:57:19 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 20 Mar 2012 21:57:21 GMT) Full text and rfc822 format available.

Message #65 received at 636783@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 636783@bugs.debian.org
Subject: Re: Bug#636783: proposed constitution fix for super-majority within the tech ctte
Date: Tue, 20 Mar 2012 14:56:35 -0700
Stefano Zacchiroli <leader@debian.org> writes:

> Let me then re-propose something that I have proposed at DebConf11 (or
> was it DebConf10?) during the tech-ctte session. I suggest to the
> tech-ctte to hold periodic public IRC meetings, *just* to go through the
> list of open issues. It can be as quick as 30 minutes every 1 or 2
> months, and it doesn't matter if only a few members could attend each
> meeting. I have the impression that it would be enough to reduce the
> duration of (2) by guaranteeing that, periodically, outstanding issues
> are re-considered.

I think it was at 11; at least, I don't remember it, and I was at 10.  :)

I would be willing to make time to attend a public IRC meeting for this
purpose.

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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Tue, 20 Mar 2012 22:15:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 20 Mar 2012 22:15:08 GMT) Full text and rfc822 format available.

Message #70 received at 636783@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 636783@bugs.debian.org
Subject: Re: Bug#636783: proposed constitution fix for super-majority within the tech ctte
Date: Tue, 20 Mar 2012 15:12:25 -0700
On Tue, 20 Mar 2012, Russ Allbery wrote:
> I would be willing to make time to attend a public IRC meeting for
> this purpose.

I would as well. I believe we are all primarily in Europe and North
America, so this should be fairly easy to do, even if it's just for
15-30 minutes every month.


Don Armstrong

-- 
For a moment, nothing happened. Then, after a second or so, nothing
continued to happen.
 -- Douglas Adams

http://www.donarmstrong.com              http://rzlab.ucr.edu




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Tue, 20 Mar 2012 23:15:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 20 Mar 2012 23:15:08 GMT) Full text and rfc822 format available.

Message #75 received at 636783@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 636783@bugs.debian.org
Subject: Re: Bug#636783: proposed constitution fix for super-majority within the tech ctte
Date: Tue, 20 Mar 2012 23:13:32 +0000
Don Armstrong writes ("Bug#636783: proposed constitution fix for super-majority within the tech ctte"):
> On Tue, 20 Mar 2012, Russ Allbery wrote:
> > I would be willing to make time to attend a public IRC meeting for
> > this purpose.
> 
> I would as well. I believe we are all primarily in Europe and North
> America, so this should be fairly easy to do, even if it's just for
> 15-30 minutes every month.

I'm definitely up for this too.

Ian.




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Fri, 09 Aug 2013 13:18:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 09 Aug 2013 13:18:04 GMT) Full text and rfc822 format available.

Message #80 received at 636783@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 636783@bugs.debian.org
Subject: Proposed draft GR proposal drafts
Date: Fri, 9 Aug 2013 14:14:10 +0100
I'm about to post 4 draft TC resolutions.  These have been largely
unchanged since the last time this was discussed.  But I'll leave it a
week or so before calling for a vote on each of these TC resolutions.

So now there will be one final round of review and consideration by
the TC of:
  * The wording of the proposed GR
  * Whether there are any other issues that should be done now
  * The wording of the amendment promise boilerplate

I suggest that as the driver of the process I should be the main
person to handle proposed amendments/improvements, although the
amendment promise wording gives any TC member that power.

Thanks,
Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Fri, 09 Aug 2013 13:21:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 09 Aug 2013 13:21:05 GMT) Full text and rfc822 format available.

Message #85 received at 636783@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 636783@bugs.debian.org
Subject: Constitutional Amendment: Fix duplicate section numbering.
Date: Fri, 9 Aug 2013 14:18:45 +0100
===== TC RESOLUTION STARTS =====

1. The Debian Technical Committee hereby exercises its power in
   4.2(1) of the Debian Constitution to propose the following
   General Resolution:

   ----- GENERAL RESOLUTION STARTS -----

   Constitutional Amendment: Fix duplicate section numbering.

   The current Debian Constitution has two sections numbered A.1.
   This does not currently give rise to any ambiguity but it is
   undesirable.

   Fix this with the following semantically neutral amendment:

    - Renumber the first section A.1 to A.0.

   ----- GENERAL RESOLUTION ENDS -----

2. It is not practical for the TC to vote to accept/reject individual
   amendments to the GR proposal.  The TC would wish to delegate its
   power to accept amendments, to avoid needing the collection of
   sponsors for uncontroversial changes.  However the Secretary has
   advised that this is not constitutionally acceptable.

   Therefore, to achieve roughly the same effect, the TC makes the
   following promise.  If any TC member gives notice that the TC
   accepts an amendment, then at least one of the following will
   happen:

     (a) the TC will use its own power under A.1(1) to arrange that
         the amendment appears on the GR ballot as an option;

     (b) the TC will use its power under A.1(1) to propose and
         its power under A.1(2) to accept the amendment, so that
         the amendment is incorporated in the version voted on; or

     (c) A member of the TC will publicly notify the amendment's
         proposer that the amendment will not be accepted after all.
         In this case TC will wait at least 7 more days before calling
         for a vote, to give time for the amendment's proposer to
         collect sponsors.

===== TC RESOLUTION ENDS =====



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Fri, 09 Aug 2013 13:21:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 09 Aug 2013 13:21:08 GMT) Full text and rfc822 format available.

Message #90 received at 636783@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 636783@bugs.debian.org
Subject: Constitutional Amendment: TC Supermajority Fix
Date: Fri, 9 Aug 2013 14:19:00 +0100
=== TC RESOLUTION STARTS ===

1. The Debian Technical Committee hereby exercises its power in
   4.2(1) of the Debian Constitution to propose the following
   General Resolution:

   ----- GENERAL RESOLUTION STARTS -----

   Constitutional Amendment: TC Supermajority Fix

   Prior to the Clone Proof SSD GR in June 2003, the Technical
   Committee could overrule a Developer with a supermajority of 3:1.

   Unfortunately, the definition of supermajorities in the SSD GR has a
   fencepost error.  In the new text a supermajority requirement is met
   only if the ratio of votes in favour to votes against is strictly
   greater than the supermajority ratio.

   In the context of the Technical Committee voting to overrule a
   developer that means that it takes 4 votes to overcome a single
   dissenter.  And with a maximum committee size of 8, previously two
   dissenters could be overruled by all 6 remaining members; now that
   is no longer possible.

   This change was unintentional, was contrary to the original intent
   of the Constitution, and is unhelpful.

   Therefore, amend the Debian Constitution as follows:

   (i) Replace "majority" with "supermajority" everywhere a ratio
   other than 1:1 is specified.  That is, in
      4.1(2) -- Developers' power to amend the Constitution
      4.1(4) -- Developers' power to overrule the TC
      4.1(5)(3) -- Developers' power to amend Foundation Documents
      6.1(4) -- TC's power to overrule a Developer (both occurrences)
   replace the word "majority" with "supermajority".

   (ii) In A.6(3):

       3. Any (non-default) option which does not defeat the default
          option by its required majority ratio is dropped from
          consideration.
           1. Given two options A and B, V(A,B) is the number of voters
              who prefer option A over option B.
    -      2. An option A defeats the default option D by a majority
    -         ratio N, if V(A,D) is strictly greater than N * V(D,A).
    -      3. If a supermajority of S:1 is required for A, its majority
    -         ratio is S; otherwise, its majority ratio is 1.
    +      2. An option A defeats the default option D by its
    +         required majority ratio if both:
    +          (a) V(A,D) is strictly greater than V(D,A); and
    +          (b) if a supermajority of N:M is required for A,
    +              M * V(A,D) is greater than or equal to N * V(D,A).

   (iii) In A.3(2) "Voting procedure", delete as follows:
	 2. The default option must not have any supermajority requirements.
    -       Options which do not have an explicit supermajority requirement
    -       have a 1:1 majority requirement.

   The effect is to fix the fencepost bug, and make the wording
   consistent, by always referring to "supermajorities" where
   applicable.  A 1:1 vote will need strictly more in favour than
   against, but an N:1 vote will need only exactly N:1.  This will
   also have a (negligible) effect on any General Resolutions
   requiring supermajorities.

   For the avoidance of any doubt, this change does not affect any
   votes (whether General Resolutions or votes in the Technical
   Committee) in progress at the time the change is made.

   ----- GENERAL RESOLUTION ENDS -----

2. It is not practical for the TC to vote to accept/reject individual
   amendments to the GR proposal.  The TC would wish to delegate its
   power to accept amendments, to avoid needing the collection of
   sponsors for uncontroversial changes.  However the Secretary has
   advised that this is not constitutionally acceptable.

   Therefore, to achieve roughly the same effect, the TC makes the
   following promise.  If any TC member gives notice that the TC
   accepts an amendment, then at least one of the following will
   happen:

     (a) the TC will use its own power under A.1(1) to arrange that
         the amendment appears on the GR ballot as an option;

     (b) the TC will use its power under A.1(1) to propose and
         its power under A.1(2) to accept the amendment, so that
         the amendment is incorporated in the version voted on; or

     (c) A member of the TC will publicly notify the amendment's
         proposer that the amendment will not be accepted after all.
         In this case TC will wait at least 7 more days before calling
         for a vote, to give time for the amendment's proposer to
         collect sponsors.

===== TC RESOLUTION ENDS =====



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Fri, 09 Aug 2013 13:21:11 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 09 Aug 2013 13:21:11 GMT) Full text and rfc822 format available.

Message #95 received at 636783@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 636783@bugs.debian.org
Subject: Advice to the TC on overruling maintainers
Date: Fri, 9 Aug 2013 14:19:05 +0100
=== TC RESOLUTION STARTS ===

1. The Debian Technical Committee hereby exercises its power in 4.2(1)
   of the Debian Constitution to propose a General Resolution,
   and according to A.1(1) the TC also proposes an amendment.

   The proposed texts of the two resulting options for the General
   Resolution are as follows:

   ----- GENERAL RESOLUTION STARTS, COMMON INTRODUCTORY TEXT -----

   Advice to the TC on overruling maintainers

   In the past the Technical Committee have been reluctant to overrule
   a maintainer unless all the members are absolutely convinced that
   the maintainer's decision was wrong.

   The TC has sought the views of the Developers.  Accordingly, the
   Developers advise, in their (non-binding) opinion, that:

   ----- GENERAL RESOLUTION OPTION A -----

   The Technical Committee's approach so far has been correct.

   ----- GENERAL RESOLUTION OPTION B -----

   Technical Committee members should be willing to vote to overrule if
   they feel that the maintainer's decision was wrong; the
   supermajority requirement is sufficient to guard against overruling
   in questionable cases.

   ----- GENERAL RESOLUTION ENDS -----

2. It is not practical for the TC to vote to accept/reject individual
   amendments to the GR proposal.  The TC would wish to delegate its
   power to accept amendments, to avoid needing the collection of
   sponsors for uncontroversial changes.  However the Secretary has
   advised that this is not constitutionally acceptable.

   Therefore, to achieve roughly the same effect, the TC makes the
   following promise.  If any TC member gives notice that the TC
   accepts an amendment, then at least one of the following will
   happen:

     (a) the TC will use its own power under A.1(1) to arrange that
         the amendment appears on the GR ballot as an option;

     (b) the TC will use its power under A.1(1) to propose and
         its power under A.1(2) to accept the amendment, so that
         the amendment is incorporated in the version voted on; or

     (c) A member of the TC will publicly notify the amendment's
         proposer that the amendment will not be accepted after all.
         In this case TC will wait at least 7 more days before calling
         for a vote, to give time for the amendment's proposer to
         collect sponsors.

===== TC RESOLUTION ENDS =====



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Fri, 09 Aug 2013 13:21:14 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 09 Aug 2013 13:21:14 GMT) Full text and rfc822 format available.

Message #100 received at 636783@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 636783@bugs.debian.org
Subject: Constitutional Amendment: Permit TC to hold informal private conversations
Date: Fri, 9 Aug 2013 14:19:07 +0100
===== TC RESOLUTION STARTS =====

1. The Debian Technical Committee hereby exercises its power in
   4.2(1) of the Debian Constitution to propose the following
   General Resolution:

   ----- GENERAL RESOLUTION STARTS -----

   Constitutional Amendment: Permit TC to hold informal private conversations

   On a number of occasions recently, enquirers have emailed TC
   members' personal addreses to informally seek members' views.  This
   has worked well; however it is not clear that Constitution permits
   it.  This situation should be regularised.

   On occasion the TC has been asked to decide on maintainership of
   packages.  It is very difficult to hold the necessary discussions,
   which inevitably involve discussion of personalities, in public.

   At the moment the TC is unable to take on a mediation role, since
   mediation necessarily involves each party to a dispute conversing
   privately with the mediator.  The TC should be able to mediate if
   the TC, and parties to a dispute, wish it to do so.

   Actual decisionmaking must still place in public of course.

   Therefore, amend the Debian Constitution 6.3 as follows (wdiff -i):

     3. Public [-discussion and-] decision-making.

	[-Discussion,-]
	Draft resolutions and amendments, and votes by members of the
	committee, are made public on the Technical Committee public
	discussion list. There is no separate secretary for the
	Committee.

        [+<cite>The Technical Committee should limit private
        discussions to situations where holding the conversation in
        public would be infeasible or counterproductive.</cite>+]

   ----- GENERAL RESOLUTION ENDS -----

2. It is not practical for the TC to vote to accept/reject individual
   amendments to the GR proposal.  The TC would wish to delegate its
   power to accept amendments, to avoid needing the collection of
   sponsors for uncontroversial changes.  However the Secretary has
   advised that this is not constitutionally acceptable.

   Therefore, to achieve roughly the same effect, the TC makes the
   following promise.  If any TC member gives notice that the TC
   accepts an amendment, then at least one of the following will
   happen:

     (a) the TC will use its own power under A.1(1) to arrange that
         the amendment appears on the GR ballot as an option;

     (b) the TC will use its power under A.1(1) to propose and
         its power under A.1(2) to accept the amendment, so that
         the amendment is incorporated in the version voted on; or

     (c) A member of the TC will publicly notify the amendment's
         proposer that the amendment will not be accepted after all.
         In this case TC will wait at least 7 more days before calling
         for a vote, to give time for the amendment's proposer to
         collect sponsors.

===== TC RESOLUTION ENDS =====



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Sun, 11 Aug 2013 14:30:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 11 Aug 2013 14:30:04 GMT) Full text and rfc822 format available.

Message #105 received at 636783@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 636783@bugs.debian.org
Subject: Re: Bug#636783: Proposed draft GR proposal drafts
Date: Sun, 11 Aug 2013 15:27:04 +0100
On Fri, Aug 09, 2013 at 02:14:10PM +0100, Ian Jackson wrote:
> I'm about to post 4 draft TC resolutions.  These have been largely
> unchanged since the last time this was discussed.  But I'll leave it a
> week or so before calling for a vote on each of these TC resolutions.

FWIW I have no objection to any of these four drafts.

-- 
Colin Watson                                       [cjwatson@debian.org]



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Mon, 30 Sep 2013 15:12:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bdale Garbee <bdale@gag.com>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 30 Sep 2013 15:12:04 GMT) Full text and rfc822 format available.

Message #110 received at 636783@bugs.debian.org (full text, mbox):

From: Bdale Garbee <bdale@gag.com>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: 636783@bugs.debian.org
Subject: Re: Bug#636783: Advice to the TC on overruling maintainers
Date: Mon, 30 Sep 2013 09:09:17 -0600
[Message part 1 (text/plain, inline)]
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

Ian, my apologies for the delay.  I promised you after our dinner
conversation at Debconf that I would try to articulate my concerns with
this GR proposal.  Here's my best stab at it as of today...

>    In the past the Technical Committee have been reluctant to overrule
>    a maintainer unless all the members are absolutely convinced that
>    the maintainer's decision was wrong.

I disagree with this assertion.  I'd be happier if the text focused on
the effect rather than the possible motivation.  That effect might be
that the TC has appeared to be slow to bring such motions to a vote?  If
so, saying that without trying to guess at committee member motivations
would make me happier about this paragraph of preamble.

>    The TC has sought the views of the Developers.  Accordingly, the
>    Developers advise, in their (non-binding) opinion, that:
>
>    ----- GENERAL RESOLUTION OPTION A -----
>
>    The Technical Committee's approach so far has been correct.
>
>    ----- GENERAL RESOLUTION OPTION B -----
>
>    Technical Committee members should be willing to vote to overrule if
>    they feel that the maintainer's decision was wrong; the
>    supermajority requirement is sufficient to guard against overruling
>    in questionable cases.

So, continuing my thought above, the problem with this proposed GR in my
mind is that I already feel willing to vote to overrule if I feel the
maintainer's decision was wrong.  So it's not clear to me that this GR
as worded would "give me any new information" from the Developers.

One reason I can think of that *I* think has caused some such motions to
not be acted on very promptly in the past are honest differences of
opinion about what is right and wrong, that led to a perceived lack of
consensus.  In those cases, maybe just voting on it and gaining a
concrete sense of the position of the TC might have been more effective
in some cases than waiting to try and build a stronger consensus?

The other reason I can think of that some such motions don't get taken
to a vote quickly is when a specific local decision might seem wrong,
but choosing to vote to overrule the maintainer feels like it might do
more harm to the overall project than allowing the maintainer's
apparently bad "local" decision to stand.  I'm having a hard time
articulating a specific example of this, but I have the sense that this
may be one root cause of delay in some of the "who should be the
maintainer of this thing" questions we've faced in the past.  

Where this leaves me is that while I do not object at all to the idea of
using a GR to discover the consensus of Developer opinion on when to
overrule a maintainer, I'm not happy about the assertion of motives in
the preamble, and remain unconvinced that the alternatives as written
would actually lead *me* to an actionable change in personal behavior
regarding voting on TC motions.  That causes me to question the utility
of this proposed GR.

Bdale
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Thu, 27 Feb 2014 18:27:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 27 Feb 2014 18:27:04 GMT) Full text and rfc822 format available.

Message #115 received at 636783@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 636783@bugs.debian.org
Subject: TC constitutional issues
Date: Thu, 27 Feb 2014 18:26:11 +0000
Briefly, mostly for my own notes:

 * 2:1 supermajority for TC overrides should be abolished (seems
   we are probably agreed on this - speak now if not)

 * FD threshold needs to be >= always, not >.  Requirement to get
   >> 4/8 voting X > FD was exploitable and bad news.

 * Possible minimum discussion period for TC resolutions.

 * Clarify ownership of resolution draft versions; what we actually
   did in the end for the 2nd real vote is clearly what the
   constitution intends but it's hard to see how this works in the
   actual text.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Fri, 28 Feb 2014 02:06:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bdale Garbee <bdale@gag.com>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 28 Feb 2014 02:06:05 GMT) Full text and rfc822 format available.

Message #120 received at 636783@bugs.debian.org (full text, mbox):

From: Bdale Garbee <bdale@gag.com>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 636783@bugs.debian.org
Subject: Re: Bug#636783: TC constitutional issues
Date: Thu, 27 Feb 2014 19:01:54 -0700
[Message part 1 (text/plain, inline)]
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

>  * 2:1 supermajority for TC overrides should be abolished (seems
>    we are probably agreed on this - speak now if not)

I'm fine with this.

>  * FD threshold needs to be >= always, not >.  Requirement to get
>    >> 4/8 voting X > FD was exploitable and bad news.

There have been other suggestions about how to change our voting system
that might have the same effect.  I don't consider myself an expert
here, just pointing out that there may be some fix other than >= that
we should consider.  

>  * Possible minimum discussion period for TC resolutions.

I'd prefer this not change.  The circumstances that led to my recent use
of no-wait CFVs was extremely unusual, and in the past we've used this
ability to quickly come to closure on issues where there was strong
consensus.  However, if others on the TC also want to impose a
(reasonably short) minimum discussion period, I guess I'm ok with it.

Bdale
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Fri, 28 Feb 2014 02:33:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 28 Feb 2014 02:33:05 GMT) Full text and rfc822 format available.

Message #125 received at 636783@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 636783@bugs.debian.org
Subject: Re: Bug#636783: TC constitutional issues
Date: Thu, 27 Feb 2014 18:28:49 -0800
Bdale Garbee <bdale@gag.com> writes:
> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

>>  * Possible minimum discussion period for TC resolutions.

> I'd prefer this not change.  The circumstances that led to my recent use
> of no-wait CFVs was extremely unusual, and in the past we've used this
> ability to quickly come to closure on issues where there was strong
> consensus.  However, if others on the TC also want to impose a
> (reasonably short) minimum discussion period, I guess I'm ok with it.

Adding a minimum discussion period means that any dispute over
construction of a ballot will always be resolved in favor of adding more
ballot options.  That may be fine and people should just vote down all the
other options.  I'm not sure what I think about that.  I have a vague but
unsubstantiated feeling that lots of ballot options leads to a higher
likelihood of weird edge cases and tactical cases in the voting system,
but maybe it doesn't if we fix the FD dropping issue that we specifically
ran into.

An alternative would be to have an explicit cloture vote in the case of a
dispute over adding more options to a ballot, or some other similar level
of indirection such as a vote over what ballot to vote on.

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



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Fri, 28 Feb 2014 07:12:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@ayous.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 28 Feb 2014 07:12:04 GMT) Full text and rfc822 format available.

Message #130 received at 636783@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@ayous.org>
To: 636783@bugs.debian.org
Subject: Re: Bug#636783: TC constitutional issues
Date: Fri, 28 Feb 2014 08:09:07 +0100
* Ian Jackson (ijackson@chiark.greenend.org.uk) [140227 19:27]:
>  * 2:1 supermajority for TC overrides should be abolished (seems
>    we are probably agreed on this - speak now if not)

I prefer if any decision to override the TC is statistically safe,
i.e. not just one vote above 50%. For the init system decision I
expected this to be the case anyways (so I'm happy with the GR rider),
but for "normal overrides" I would prefer something like 55% or "at
least 20 votes more" or so. (I don't have any detailed opinion on what
is adequate, but I prefer it to be a bit more than 1:1).


Andi



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Fri, 28 Feb 2014 11:15:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 28 Feb 2014 11:15:04 GMT) Full text and rfc822 format available.

Message #135 received at 636783@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Andreas Barth <aba@ayous.org>, 636783@bugs.debian.org
Subject: Re: Bug#636783: TC constitutional issues
Date: Fri, 28 Feb 2014 11:12:25 +0000
Andreas Barth writes ("Bug#636783: TC constitutional issues"):
> * Ian Jackson (ijackson@chiark.greenend.org.uk) [140227 19:27]:
> >  * 2:1 supermajority for TC overrides should be abolished (seems
> >    we are probably agreed on this - speak now if not)
> 
> I prefer if any decision to override the TC is statistically safe,
> i.e. not just one vote above 50%. For the init system decision I
> expected this to be the case anyways (so I'm happy with the GR rider),
> but for "normal overrides" I would prefer something like 55% or "at
> least 20 votes more" or so. (I don't have any detailed opinion on what
> is adequate, but I prefer it to be a bit more than 1:1).

Do you think it likely that the project might have a series of GRs
with contradictory outcomes ?

I think that if feeling is very close the right answer is to have it
decided by bare majority in a GR.  If you did as you suggest, and the
override GR failed 200 in favour vs 199 against, the holding of a
another GR would be nearly inevitable.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#636783; Package tech-ctte. (Fri, 28 Feb 2014 18:24:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@ayous.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 28 Feb 2014 18:24:04 GMT) Full text and rfc822 format available.

Message #140 received at 636783@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@ayous.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 636783@bugs.debian.org
Subject: Re: Bug#636783: TC constitutional issues
Date: Fri, 28 Feb 2014 19:20:23 +0100
* Ian Jackson (ijackson@chiark.greenend.org.uk) [140228 12:15]:
> Andreas Barth writes ("Bug#636783: TC constitutional issues"):
> > * Ian Jackson (ijackson@chiark.greenend.org.uk) [140227 19:27]:
> > >  * 2:1 supermajority for TC overrides should be abolished (seems
> > >    we are probably agreed on this - speak now if not)
> > 
> > I prefer if any decision to override the TC is statistically safe,
> > i.e. not just one vote above 50%. For the init system decision I
> > expected this to be the case anyways (so I'm happy with the GR rider),
> > but for "normal overrides" I would prefer something like 55% or "at
> > least 20 votes more" or so. (I don't have any detailed opinion on what
> > is adequate, but I prefer it to be a bit more than 1:1).
> 
> Do you think it likely that the project might have a series of GRs
> with contradictory outcomes ?

For the init system or overall?



For any decision we should make sure that we have a statistically
working vote. For normal cases however we don't have any default
option we should reasonably fall-back to, so I don't think we should
change there anything. For overridings however we could fall-back to
the original decision.


> I think that if feeling is very close the right answer is to have it
> decided by bare majority in a GR.  If you did as you suggest, and the
> override GR failed 200 in favour vs 199 against, the holding of a
> another GR would be nearly inevitable.

I'm not convinced. Actually it means that the developers at large are
don't consider overriding necessary enough. I'm also not convinced the
next GR would have more in favour, or more against.



Andi



Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Apr 16 16:13:47 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.