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 <o...@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
