Discussion on Addressing Voting Issues and Proposed Update to Committer Rules

[Hauke Mehrtens]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 7d9db0a9-1c42-4e91-bf39-e184cee8a97f.png
Type: image/png
Size: 123519 bytes
Desc: not available
URL: <http://lists.openwrt.org/pipermail/openwrt-adm/attachments/20250505/4e9c4823/attachment.png>