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

Re: Changing how we handle non-free firmware



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


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 think it's reasonable to take the position that GRs can only amend the constitution explicitly. The constitution is written in legalistic language and there is obvious value in having the rules written in one place.

For the Foundation Documents, it seems less cut-and-dried. This is especially true if, for example, a GR could purport to override a Foundation Document temporarily (still by 3:1 majority).

Whether permanently superseding part of the DSC by implication is constitutionally permissible is different from whether it is a good idea. The former is a question for the Secretary. The latter is a question for the Developers through the GR.


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.

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.

It also just doesn't look good for the Secretary to void the GR based on which option won. That makes it look like you're doing so because you disagree with the result. I'm not saying that is the case here. I'm saying the optics are worse with deciding after, so I think you should decide before.


In my view, if the Secretary determines that a GR option is constitutionally defective (for whatever reason), it should not be on the ballot. I think you should (in this and all GRs) rule each GR option one of:
- requires 1:1
- requires 2:1
- requires 3:1
- invalid


https://www.debian.org/vote/2008/vote_003 is precedent for:
  - a GR option could supersede a Foundation Document implicitly,
  - a GR option could supersede a Foundation Document temporarily (not
    relevant here, but I made the point above), and
  - that such options require 3:1.

https://www.debian.org/vote/2006/vote_007 is precedent for:
  - a GR option could supersede a Foundation Document permanently and
    explicitly but without amending its text, and
  - that such an option requires 3:1.

https://www.debian.org/vote/2006/vote_001 is precedent for:
  - a GR option could supersede a Foundation Document permanently and
    implicitly (though curiously the vote statement says "DFSG article 3
    would need to be changed, or at least clarified.")
  - that interpreting a Foundation Document needs only 1:1.

https://www.debian.org/vote/2004/vote_004 is precedent for:
  - a GR option could supersede a Foundation Document temporarily
    (though this took a very different approach than 2008-003 did
    later).

--
Richard

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


Reply to: