[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)

On Mon, Apr 19, 2021 at 01:04:21PM -0700, Russ Allbery wrote:
> 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.

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

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

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".


Reply to: