Discussion on Addressing Voting Issues and Proposed Update to Committer Rules

[Rich Brown]

Hauke,

This is terrific work. It aligns with what I hoped would occur. I have tuned up the wording, preserving most of the original text, while (hopefully) making the rules more concise and more operational.

I uploaded the rules you sent to a github repo, so that it's easier to see the changes I am suggesting:

See the updated document at: https://github.com/richb-hanover/OpenWrtRules/blob/main/OpenWrt%20Rules.md Check out the diff's at: https://github.com/richb-hanover/OpenWrtRules/commit/d9f3a7860e79be33bec09f18868f2fda833d3622

Here are the major changes: 

* Removed reference to LEDE. (It's ancient history - we merged back in January 2018.)

* Separated the rules into sections. The headings don't really change the rules, but organize the big topics. I don't feel strongly that these headings need appear in the final set of rules.

* I very much like the change in terminology from "committer" to "member". But the change demands rules that specify who has commit rights, so there's a new section.

* I changed the wording that any active member could "request that a non-participating member switch to inactive status" (instead of "be moved to inactive status") The resulting actions are the same: if that member agrees, they become inactive; if they wish to remain active, they can; if there is no response, they become inactive. (I would counsel a second mail notification, but that doesn't need to be in the OpenWrt Rules.)

* Voting: I gave names to "Rule Change votes" (75%) and "simple approval votes" (two-thirds). Project matters, development direction, and new members all require a simple approval.

* I propose using the term "administrators" for the people who take care of our systems.

QUESTIONS: 

1. Do these voting thresholds work in practice? If we exclude obviously "non-participating" people (perhaps people who haven't emailed to openwrt-adm in the last 90 or 365 days) from previous votes, could we have passed all the recent proposals?

2. Is there a reason to distinguish between a two-thirds vote from a 75% vote (it's not that much different...)

3. Do we need to distinguish between approval and "no opinion" votes? A proposal that generated a lot of "no opinion" responses would fail the simple (two-thirds) approval. Is that what we desire? [1]

I invite additional comments. 

Thanks again,

Rich

[1] For example, I would tend to vote +1 for people who are proposed to become members. For anyone who has a long-enough history of contributions to be proposed, I am happy to embrace them: they've worked hard for OpenWrt. But for matters of infrastructure, (hypothethical example, "should we switch from git to mercurial?" :-), I would likely vote "no opinion" because I don't understand the issues, and would defer to others' opinions. But would that "no opinion" vote cause the proposal to fail?

> On May 4, 2025, at 19:10, Hauke Mehrtens <hauke at hauke-m.de> wrote:
> 
> On 5/4/25 20:57, Baptiste Jonglez wrote:
>> Hi Hauke,
>> On 03-05-25, Hauke Mehrtens wrote:
>>> As many of you are aware, we've been facing significant challenges with
>>> voting in the project for the past few years. A key issue is the large
>>> number of inactive committers, which has led to the failure of the last two
>>> votes. Although I've participated in several private email discussions and
>>> face-to-face conversations about this problem, I don't believe it's been
>>> formally raised on the openwrt-adm list yet.
>>> 
>>> The current rule regarding inactive committers is not functioning as
>>> intended:
>>>> Committers being unreachable for three months in a row shall get
>>>> their commit and voting rights revoked in order to retain the ability
>>>> to do majority votes among the remaining active committers.
>>> 
>>> Proposal for an Inactive Committer Category
>>> 
>>> I’d like to propose introducing a formal “inactive committer” category. The
>>> core idea is to provide a clearer distinction between active and inactive
>>> participants, as well as improve security by reducing the number of people
>>> with access to our repositories.
>> Thanks for the proposal.  It is a good compromise because the current rule
>> can feel like an exclusion, which is probably why it isn't used in practice.
> 
> Thank you for reading it in detail and giving good feedback.
> 
>> However, I think it hides two larger issues:
>> 1) a technical voting issue: "simple majority" in the rules is ambiguous.
>> Simple majority usually means "more 'yes' than 'no' among the people who voted".
>> What we do in practice is called "absolute majority": counting "yes" votes
>> and having to reach 50% of all members with voting rights.
> 
> I think we should update the rules to be clear what we want in this proposal too. I do not like ambiguous rules.
> 
>> When the size of the group grows, it is inevitable that we get lower vote
>> participation, and absolute majority is hard to reach.
>> We could switch to a simple majority vote with quorum.  It would look like this:
>> - more "yes" than "no"
>> - AND at least Q "yes", where Q is the quorum as a function of the voting population N
>> Debian seems to use Q = 3/2 * sqrt(N).  With 42 total voters, it yields a quorum of 10.
>> In a local association, we use Q = sqrt(3*N).  With 42 total voters, it yields a quorum of 12.
>> Of course, this quorum would only apply to simple decisions.  Decisions
>> with more impact should have a higher quorum (1/2 = absolute majority, or
>> even 2/3 like our current rule 11 for updating the rules).
> 
> I like such a rule update. I do not know if these numbers are the best, but having a lower quorum would be very nice.
> 
> I would add this to my proposal.
> 
> I would prefer:
> * more "yes" then "no" and "Q = 2 * sqrt(N)" for normal votes
> * 2/3 "yes" and "Q = 1/2 * N" for rules changes.
> 
>> 2) a social issue: in practice, "contributors" is a larger group than
>>    "committers" and we may want to extend voting rights for all
>>    contributors.
>> For example, it's been years since I haven't committed anything, so I
>> would be totally fine to lose commit access.  But I'm still involved in
>> other areas (infrastructure, buildbot, wiki admin) and I would still like
>> to participate in decisions.
>> This is more a long-term discussion, and is maybe less of a priority than
>> the current situation with blocked votes.
> 
> We could change the word committers into members. As this proposal touches this part anyway.
> 
> Maybe we should remove or change this rule too:
> > There shall be only full commit rights in any case, no partial access
> > or otherwise restricted access to the repositories.
> 
> If you do not want commit access you do not need it. I do not have root access to all servers, because I do not need it.
> 
> Hauke<7d9db0a9-1c42-4e91-bf39-e184cee8a97f.png>_______________________________________________
> openwrt-adm mailing list
> openwrt-adm at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-adm