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. There's no maximum discussion period defined, which means fixes for that risk introducing a filibuster. * Calling for votes is defined as a separate action from the end of the discussion period, but in practice the constitution allows any developer to call for a GR vote via an abuse of process that probably wasn't intended, and even apart from that, the set of people who can call for a vote is strange and not very defensible. * Calling for votes is even more of a disaster for Technical Committee votes, as we have alas discovered. * The length of the process is therefore not predictable, which means that people can't plan around deadlines for making changes to the ballot and instead we get procedural arguments around last-minute changes. * The constitution reuses the term "amendment" for both changes to a ballot option and for introducing a new ballot option in ways that make it very hard to understand what some of the rules mean. * The original proposer of the GR gets weird powers in the process that don't seem appropriate and can be abused. * 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). * The constitution says that any place the Standard Resolution Procedure is invoked must state what the default option is, but then doesn't do that. * 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. 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. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
