Bug#636783: Bug#795857: Bug#795855: Bug#636783: Bug#795855: #636783 - New bugs for individual issues
> "Bdale" == Bdale Garbee writes: Bdale> Sam Hartman writes: >> I'm just sying having seen it used once I'd rather decide never >> to go there again. Bdale> For what it's worth, I agree. I'll note that for this to be fair we need to be able to push back on two different kinds of pressure pushed against ballot options. Some members of the TC wanted to be able to vote for options focused on only a choice of technology. Others wanted to include language related to linking of technology. If we believe it's important that we not act to prevent ballot options from being on the ballot, then sometimes we get ballots were some options answer more questions (or different questions) than others. And the deciding factor for whether it is one ballot kind of needs to be TC members wanting to be able to rank the options together. So, to be concrete, it means sometimes you get D and DT on the same ballot. And yeah, that's kind of strange. But in my opinion it's what falls out when we decide not to strategically block each other from having the options we value on the ballot. (And yeah, perhaps you want to do some trimming of options no one claims they care about even if it means that one of the obvious possibilities doesn't even get voted.)
Bug#795857: Bug#795855: Bug#636783: Bug#795855: #636783 - New bugs for individual issues
Sam Hartman writes: > I'm just sying having seen it used once I'd rather decide never to go > there again. For what it's worth, I agree. Even in the worst of times, I'm personally just fine with extreme boundary conditions being left to human sensibility. We have a pretty effective set of checks and balances in place already. If there are simple changes we can make that further reduce the probability of emotions ever running that high again, I'm all for making them (changing to an odd number of members on the TC, having a simple rule that ensures periodic voting for the TC chair, etc)... but adding greater complexity is something I believe we should only do as a last resort. Bdale signature.asc Description: PGP signature
Bug#741573: Proposed draft of ballot to resolve menu/desktop question
On Wednesday 19 August 2015 10:57:43 Sam Hartman wrote: > > "Don" == Don Armstrong writes: > >> While we're not overturning anything in the sense of an override > >> here, I think we owe an explanation for our actions, and I feel > >> really strongly about that. > > Don> Ideally the patch and its rationale should stand alone without > Don> the need for a separate text. But that said, if you disagree > Don> that the rationale is not sufficient once it exists, I'll > Don> either try to modify it or draft a separate text. > > No, a rationale that explains why option D is better than A/B is all I'm > asking for. >From my technical POV I think Option D is better than A/B because it is a more clear technical solution, and saying "there is one menu to care about" The current A/B thing ended up as a standard compromise that tries to leave everyone equally unhappy, and ending everyone having to decide for them selves which menus to cater for. I don't think A/B is a particular good solution but is immensely better than doing nothing. Option D is what I was hoping for we would end up with in some years after letting the debian menu bitrot for another couple of years. In option D4, I'd though like if "Debian Desktop" or similar was involved, as it is likely the debian desktop maintainers (XFCE, Plasma, Gnome, LX(DE|Qt), ..) who are closest to the users in this regard. >From my social POV I'd love to see B win because I really think that there was a good enough consensus to be able to move on with issues like that. If we hadn't had the double-role of menu maintainer and policy editor, I'm pretty sure we wouldn't have gotten here in the first place. But as Debian is a technical project consisting of social individuals, I would hope to see D>B>A>Z>C as the final result. /Sune - the one who initiated this mess
Bug#795855: Bug#636783: Bug#795855: #636783 - New bugs for individual issues
I think that calling for a vote and knowingly dropping options from a ballot actually harms the TC process. It is a strategic technique that I think can change the outcome of the process. I think that strategy does more harm than good and I'd like to forbid it. However, I think that I trust the membership of the TC enough to believe that if we forbid that strategy, it will be sufficiently ineffective to be used even if no formal enforcement exists. To be clear, I do not condemn the use of that strategy in the past. I'm just sying having seen it used once I'd rather decide never to go there again.
Bug#741573: Proposed draft of ballot to resolve menu/desktop question
> "Don" == Don Armstrong writes: >> While we're not overturning anything in the sense of an override >> here, I think we owe an explanation for our actions, and I feel >> really strongly about that. Don> Ideally the patch and its rationale should stand alone without Don> the need for a separate text. But that said, if you disagree Don> that the rationale is not sufficient once it exists, I'll Don> either try to modify it or draft a separate text. No, a rationale that explains why option D is better than A/B is all I'm asking for.
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 > > 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. Tho
