On Mon, Apr 19, 2021 at 01:04:21PM -0700, Russ Allbery wrote: > Jonathan Carter <j...@debian.org> writes: > > > I think that framing the problems and noting them while the last GR is > > still fresh in our collective memories will be really useful. I don't > > think anyone should feel too much pressure right now to come up with > > solutions, and I'd urge any group of people who are brainstorming on > > this whether on a public channel or among some Debian friends to not yet > > propose any kind of GR or anything major like that just yet. > > I'm certainly not in any hurry to do anything like that. :) And I also > expected everyone to not want to get into it in detail until after the > release is out. > > For the record, because some folks in this discussion have been worried > that this is about one specific vote or another, here's a (nonexhaustive) > list of concerns that I have that I think we should fix. This isn't > really intended to open a discussion or get into solutions and I probably > therefore won't respond to more discussion of that right now (I promise, I > will later and won't propose any surprise GRs). This is just to give > people a feel of what some of us mean when we talk about procedural flaws: > > * The length of the discussion period is ill-defined in multiple ways, > which has repeatedly caused conflicts. It only resets on accepted > amendments but not new ballot options, which makes little logical sense > and constantly confuses people.
I agree; I believe it should be the opposite (i.e., it should reset on new ballot options but not on modifying already accepted options) [...] > * A formal amendment has to be sponsored like a new GR before it can be > accepted, but the original proposer of a GR can make their own amendment > without having it be sponsored. These two rules make no sense in > combination (which is probably why the first rule is rarely, perhaps > never, enforced). I'm not entirely sure what you mean by that. Can you clarify? [...] > * There's a reasonable argument that using a default option of "none of > the above" would be clearer to people who have not participated in a lot > of Debian votes but who have experience with other voting systems where > that's a more typical default option. I can understand the issue with FD, but I don't think NOTA is a good alternative. I think any other language should be explicit about what the result will be, and what it will *not* be. NOTA does do that, IMO; it does not clarify that the discussion may restart, and that a new vote may appear; it just states that none of the presented options are appropriate. The default option means "we don't have a valid option on the ballot, we would therefore like to cancel the vote and possibly do it over"; I would therefore prefer the default option to state something like "cancel the vote, possibly restart it" or some such. > Also, some folks (not including > me, but I do understand) have been unhappy with the plain English > implications of "further discussion" for some time and often feel > obliged to propose a ballot option that's functionally equivalent but > isn't seen as calling for more discussion. Not sure whether you consider this an issue, but I don't see that as a problem. There is a difference between "we can't reach an agreement and therefore decide on a no-outcome vote" (which the default option is), and "we have considered all the options and decide that a no-outcome vote is the best result" (which an explicit no-outcome ballot option represents). To put it otherwise, due to the nature of the default option, an explicit no-outcome ballot option is *not* functionally equivalent to the default option, in my opinion, since the default option means "this doesn't work, let's not do this and maybe try again", and an explicit no-outcome ballot option explicitly means "this doesn't work, let's not do that again". -- w@uter.{be,co.za} wouter@{grep.be,fosdem.org,debian.org}