[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

* 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: