Your message dated Wed, 13 Jan 2016 15:32:15 -0500
with message-id <tsltwmh8blc....@mit.edu>
and subject line Multiple Ballots
has caused the Debian Bug report #795855,
regarding Introduction of a formal cloture vote procedure for the TC
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
795855: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795855
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: normal
Hi all,
here's my understanding of the state of our "Introduction of a formal
cloture vote procedure for the TC" discussion.
In June 2014, in answer to a proposal from Ian to introduce a minimum
discussion period in the TC, Steve, referring to a previous TC IRC
discussoin, proposed in <20140628005011.ga8...@virgil.dodds.net> to
introduce a formal cloture vote procedure for the TC, with the following
"strawman"
Le vendredi, 27 juin 2014, 17.50:11 Steve Langasek a écrit :
> - Any member of the TC may call for a cloture vote on a proposed
> ballot at any time.
> - Quorum for a cloture vote is 1/2 + 1 members.
> - A cloture vote must receive 2/3 majority in favor in order to pass.
> - Voting period for cloture is 48 hours, or until the outcome is no
> longer in doubt.
> - Ballot options proposed during the cloture vote shall be included
> on the ballot.
> - If a cloture vote fails, any TC member who voted in favor of
> cloture may not repeat the call for a period of one week following
> the first call. Other members of the TC may call for cloture during
> this time.
> - If a cloture vote fails, any ballot options that are subsequently
> proposed and not withdrawn shall be included on the ballot for the
> issue.
> - If, two weeks after the original call for cloture, there have been
> no further ballot options proposed, voting proceeds on the original
> ballot.
>
> Features:
>
> - If there is procedural consensus, we can act as quickly as we need
> to.
> - If someone tries to CFV too early, whether because of an error
> in judgement or because they're trying to cut off debate, a
> "cooldown" period applies, ensuring that a failed cloture vote
> actually leaves room for further discussion
> - However, as soon as any one person who has voted against cloture is
> satisfied with a revised ballot, they can call for cloture again
> and the vote can move forward
> - A CFV can largely not be used to prevent a minority viewpoint being
> represented on the ballot, since additional ballot options can be
> submitted during the cloture vote and are guaranteed to be
> included.
> - Voting down cloture cannot be used to prevent a question from
> coming to a vote; anyone opposed to cloture must still put in the
> effort to come up with alternative ballot options or the vote will
> still happen.
>
> Misfeatures:
>
> - A member of the TC can ensure "irrelevant" ballot options are
> included on the ballot, possibly spoiling the vote. I don't think
> this is a real issue. But then, I also fundamentally disagree with
> Bdale's characterization of the init system ballot proposals as
> "conflation"; so I consider this the lesser evil compared with the
> status quo, and think it should not be possible for any member of
> the TC to ever do again what Bdale did in that case.
This proposal was answered by Anthony in <CAJS_LCXtwOTZxPefbUjXh_x8-
sq0oafy571lgg4yz0xjzzo...@mail.gmail.com> with the following alternative
strawman:
Le dimanche, 29 juin 2014, 20.35:56 Anthony Towns a écrit :
> - Any member of the TC may call for votes on a ballot at any time.
> - When calling for votes, the TC member may propose any combination
> of resolutions they believe is appropriate to be considered on the
> ballot, provided they fall under the ctte's constitutional powers.
> - When voting on the ballot, TC members may rank the proposed options
> from 1 to n in the normal manner for Debian ballots.
> - An additional "Cloture" option will be automatically added to the
> ballot.
> - The Cloture option may only be marked "Y" to approve cloture, or
> "N" to deny cloture.
> - The Cloture option is the default option for the SRP. A "Y" vote
> for cloture is treated as ranking the default option below all
> others (including unranked options). A "N" vote is treated as
> ranking the default option above all others.
> - In the event that cloture fails (ie, the default option wins the
> SRP), the TC members should discuss the reasons for the failure and
> produce a new ballot that is able to pass cloture.
>
> (SRP=Standard Resolution Procedure)
The discussion stalled there, let's use this very bug to discuss this
issue.
Cheers, OdyX
signature.asc
Description: This is a digitally signed message part.
--- End Message ---
--- Begin Message ---
The discussion in the last couple of TC meetings has been to close out
this bug and for me to try and write things up a bit.
today, you can gain some significant process power by calling for a vote
on a ballot where options that some TC members want to vote on are not
on the ballot.
Doing that has created significant frustration.
To me the obvious question is why don't you vote on a ballot with all
the options people want.
There seem to be some concerns that having a lot of options on the
ballot can lead to problems.
I didn't understand why and I went off to discuss with Bdale who was one
of the people most concerned about that prospect.
He pointed back to the GR regarding binary blobs for firmware in the
kernel.
In that case there were a number of options on the ballot.
The question he and the RMs were hoping to answer was could we make a
release.
However, some of the options, including the winning option did not
directly answer that question.
More generally, in a case where there's not agreement on what the
question should be, you can run into a case where different options on
the ballot are answering different questions.
For example in the Systemd case, some folks wanted to focus directly on
the question of the default init system for Jessie. Others wanted to
answer some broader policy questions about linking and interdependence.
If you take the approach of putting it all on one ballot, then you're
throwing the question to the voters.
You may well get an answer back that doesn't answer a question you
thought important.
If you think that's important to solve, then you might want a solution
along the lines of this bug plus a procedure for deciding what options
get on a ballot.
No one on the TC now seems interested in sponsoring this, so we've
decided to close it, allowing anyone who does want to try and push it
forward to reopen.
I'd like to express my opinion about why I think this is a bad idea.
I think there are legitimate disagreements about what the questions are.
I trust our TC members (and our general members for GRs) to do as good
of a job as anyone at figuring out the questions the project needs to
answer.
Yes, sometimes, as we did in the binary blob case, we'll get some
criteria, and there'll be additional work to figure out how those
criteria apply to the current situation.
Sometimes, as in the Systemd upgrade case, we'll realize that we didn't
answer a question we need to answer.
My belief is that the other approaches I can see are open to significant
process manipulation and political issues and produce overall
lower-quality results. Some small group is not going to be in a better
position to decide what questions need answering and when; they can
decide for their needs, but the project (or TC for TC decisions) is in
the best place to determine the project's (or TC's) needs overall.
Yes, sometimes we'll mystify and frustrate ourselves.
Debugging is hard:-)
--- End Message ---
