Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)
Jonathan Carter <jcc@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 (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: