Bug#636783: Bug#795855: #636783 - New bugs for individual issues
On Tue, Aug 18, 2015 at 08:23:44PM +0200, Steve Langasek wrote:
> On Tue, Aug 18, 2015 at 11:12:08AM -0700, Josh Triplett wrote:
> > On Mon, 17 Aug 2015 15:39:06 +0200 Didier 'OdyX' Raboud <odyx@debian.org> wrote:
> > > - #795855
> > > Introduction of formal cloture vote for the TC
>
> > > - #795857
> > > TC chair appointment
>
> > Given context, I think these originally shotgunned proposals (especially
> > these two) need careful re-evaluation, to figure out how much actual
> > point they have and how much they're just a reflection of a past spite.
>
> > The "cloture" proposal honestly seems like a needless pile of additional
> > process. Anyone can call for a vote at any time, and I don't think
> > that's a bug; if people agree that a vote is warranted, they can vote,
> > and if they don't, they can vote "further discussion". If even a simple
> > majority is opposed to holding a vote, they can all vote "Further
> > Discussion". Anyone else can *also* call for a vote at any time, if
> > they feel there's another issue to discuss.
>
> > So, I would suggest that the "cloture" proposal should be consigned to a
> > historical note along with the fit of pique it came from.
>
> This was no fit of pique.
To clarify explicitly, since I realized that my offhand comment may not
have been entirely clear: I was not suggesting that your considered
proposal for cloture was a fit of pique; that would be ridiculous. I
was suggesting that the original series of sudden complaints about TC
processes and composition, as a whole, constituted a fit of pique. Or
perhaps a full-fledged tantrum of pique. Your proposal, while I
disagree with it, nonetheless seems like a genuine and considered
attempt to consider and address one of those particular complaints.
> I consider the fact that any single member of the
> TC can cut short discussion by calling a vote to be a serious bug in a
> process that is otherwise designed to favor consensus instead of mere
> majority rule. It is precisely at those times that the TC has not found
> consensus that the process should be proofed against procedural abuses
Even if you consider this an issue, I don't think this is the right way
to fix it.
I think it makes sense to retain the ability to call for a vote on a
specific question at any time. But at the same time, it should be
*explicitly* clear that Further Discussion is always a viable option,
and furthermore, there should be a straightforward way to say "cut that
out". Thus, rather than voting on whether to vote, the TC can simply
vote, which will either result in an answer, *or* (determined by the
same vote) result in an expression of dissatisfaction with the current
proposals and a desire to seek other options.
I would also suggest that the TC has encountered this situation
precisely once in a long history of decisions (including fairly
controversial decisions). (There were plenty of situations where the TC
was too quick and eager to take action, but only one where anyone at all
suggested that a TC member was too quick to call for a vote.) And I
would further suggest that that situation was rather unique to the
particular type of decision requested of the TC, because it had a unique
meta-recursion problem. Under most circumstances, the problem of
constructing a ballot is, if not easy, then at least easier than solving
the problem being voted on. For that particular case, ballot
construction reduced to the question being voted on, precisely because
Debian's usual failure mode^W^Wconsensus-building approach of "let's do
everything!!1!" effectively reduced to one of the other controversial
ballot options in the first place.
The primary proposal here for a cloture process also has an additional
misfeature not mentioned: a non-majority subset of the TC (3 members in
an 8-member TC) can indefinitely block a vote, which is itself a
procedural abuse (with extra bonus diffusion of responsibility), except
it seems to be by design. In a situation in which there is no consensus
and the only solution is a vote, and the ballot itself cannot reach
consensus either (being precisely as contentious as the question at
hand), this cloture process allows the indefinite delay of the vote.
As such a delay may well align with one of the desired outcomes, that
process change itself seems rife with potential procedural abuses.
All that said, my argument here against adding a cloture process only
applies to the original proposal of a separate cloture vote with
supermajority and automatic inclusion of additional proposed options,
and not to the alternative proposal.
The alternative proposal (from AJ), modulo naming, effectively reduces
to "you can only rank FD at the top or bottom, and you are encouraged to
vote FD at the top if you are not satisfied with the ballot". That
actually sounds rather reasonable. So does the cool-off-period part of
the original proposal; if FD wins, it makes sense to require Further
Discussion to actually take place. Though I suspect that would
naturally happen anyway.
(And if someone were to *actually* engage in procedural abuse, and
there's actual agreement on that point, then the right approach isn't to
force a vote or non-vote via cloture, but rather to remove the person
abusing the TC process from the committee and continue without them.
And if there *isn't* agreement on that point, then the right approach is
to get over it and vote, which includes voting for Further Discussion if
desired, and convincing other people to vote likewise.)
> (which I still consider the call for votes on the init system to have been,
> regardless of whether there was any malicious intent).
And personally, I think if that *hadn't* been done, the TC would
probably still be fighting over variant issue #407 subclause 3 of what
color the 23rd ballot should be, and why in the meantime volunteers had
not yet materialized from the ether and set about to rewrite an init
system to satisfy TC member personal sensibilities. I don't see how
it's a procedural abuse to actually vote on the question the TC was
asked, rather than simultaneously seeking to answer an unasked and (as
demonstrated by GR) unwanted question.
I also think it's entirely too easy for *either* side of that past
debate to frame any number of actions on both sides as "procedural
abuse"; most such accusations already occurred at the time and thus do
not need revisiting here. I think most of those generalize to the
meta-issue I mentioned earlier in this mail, about how that particular
debate was uniquely positioned to make meta-decisions devolve into the
main decision. I'd also suggest that that past committee decision was
painful enough without dredging up grievances from it here (the
avoidance of which was a significant motivation for my original mail to
this bug). To the extent a process improvement is desirable here, let's
see if we can manage to actually talk about that process improvement
*without* reopening the discussion on all the meta-issues of that
particular debate. I will endeavor to do the same myself.
- Josh Triplett
Reply to: