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

Re: Changing how we handle non-free firmware

On Tue, Aug 30, 2022 at 03:27:46AM -0500, Richard Laager wrote:
> On 8/29/22 16:02, Kurt Roeckx wrote:
> > It's my current interpretation that all voting options, even if they
> > might conflict with the DSC, will be on the ballot, and might not
> > require a 3:1 majority. That is, I don't think the Secretary can decide
> > not to include an option that might conflict, or put a 3:1 majority
> > requirement on it because they think it conflicts.
> > 
> > However, if an option that might conflict wins, the Secretary might
> > have to decide if it conflicts or not, and if it conflicts void the
> > GR.
> I'm having trouble reconciling the two positions of "[not] put a 3:1
> majority requirement on it because...it conflicts" and "it conflicts void
> the GR".

I think that the Secretary when running a vote should just follow the
procedures for the vote. There is no text saying that the Secretary
should make sure that the option is valid. If there are enough people
to put an option on the ballot, the Secretary should put that option
on the ballot, even when it's clearly invalid. The Secretary can of
course say that they think it's not a valid option, and what might need
to change for it to be, but I think it should be on the ballot even
when not valid. We can still deal with it being not valid if it ends
up winning.

> The only way I can see to reconcile your positions is if a GR is not allowed
> to supersede a Foundation Document by implication, but must do so
> explicitly. Is that your rationale?

I have not made any decision about this yet, but if asked, will most
likely say so.

It's at least a reason why an option might not be valid.

> Regardless of that, and probably more importantly, I object to the idea that
> a GR option winning could result in the whole GR being voided. Our voting
> system is explicitly designed to take into account supermajority
> requirements. A GR option failing a supermajority requirement should fail by
> itself, not take down the whole GR with it.

I'm not sure it's a good idea to reinterpret the results with that
option removed. I think if an option wins and is later determine not
to be valid, the GR should just be done again.

> Since there's a good chance you have to make the determination either way, I
> think it's far better to make that determination before the vote than after.
> Making the determination now gives people the option to amend their GR
> options before we go through a vote. That saves time and energy.

I'm not sure how fast I will be to make such determinations.

> https://www.debian.org/vote/2008/vote_003
> https://www.debian.org/vote/2006/vote_007
> https://www.debian.org/vote/2006/vote_001
> https://www.debian.org/vote/2004/vote_004

Note that I've been Secretary since February 2009.

Disagreement about how vote 2008/vote_003 was run is what made the
previous Secretary quit.

I like to discussion about anything related to this, so that I can at
least get an idea what the consensus is.


Reply to: