Discussion on Addressing Voting Issues and Proposed Update to Committer Rules

[Hauke Mehrtens]

On 5/30/25 22:16, elias at eliashaisch.de wrote:
> Thank you all for your efforts! Overall, I really like the proposed 
> changes.
> 
> That said, I’d like to suggest introducing a deadline for certain votes 
> — or, technically speaking, a TTL (Time To Live) for each vote. In 
> addition, a standardized and slightly more assertive call to participate 
> in voting could be helpful. Voting is important, and while the right to 
> vote should not be restricted lightly, the importance of participation 
> should be clearly emphasized.
 > > For rule changes, a longer TTL might be appropriate. Perhaps something
> like this is already in place and I simply overlooked it. My thinking is 
> that even active members may occasionally be unavailable. Rule changes 
> tend to be less urgent but are also less frequent — and therefore 
> deserve adequate time for discussion.

My proposal contains this sentence:
 >  The proposal must clearly describe the suggested changes and include 
a specific deadline for when the voting period will end.

I explicitly did not add a minimum or maximum voting deadline, so we can 
do a fast vote if we have a urgent problem.

> Moreover, I believe the current proposal better reflects the actual 
> dynamics of a software project like this — one that operates at the 
> intersection of political and commercial interests from various segments 
> of society. It’s important to acknowledge this reality, since decisions 
> in such projects often have not just technical, but also social 
> implications.
> 
> Of course, additions like this can always be made later and should not 
> delay the current vote. I encourage all of you to support this rule 
> change. It moves the project forward and makes its development more 
> transparent and accessible.
> 
> Elias
> 
> 29.05.2025 20:42:26 Hauke Mehrtens <hauke at hauke-m.de>:
> 
>     Thank you for al the good input.
> 
>     I updated the proposal to also change the voting rules.
>     I restricted the votes to Yes/No votes. A vote like: "Where do we
>     want to host: own git, github or gitlab?" would not be possible any
>     more. Someone would have to propose a change where we can vote
>     approve or disprove to.
> 
>     I also changed the number of votes needed. Normal votes need 2/3 of
>     participating voters approval and 1/3 of all. For rule changes I
>     changed it to 75% of participating voters and 50% of all.
> 
>     I also reordered the rules a bit.
> 
>     I would also like to change committers to members. This would allow
>     us to add people who do not contribute code to become a OpenWrt team
>     member. To improve this I also removed the rule that everyone needs
>     full commit rights.
> 
>     Everyone who is currently listed as committer will become a active
>     member after this rule change.
> 
>     If no one disagrees I would like to do an official vote with the
>     version changing committers to members.
> 
>     If I accidentally changed any other meaning in the rules please tell
>     me now.
> 
>     Hauke
> 
> 
>     The current version with committers:
>     ------
>     The roles within the OpenWrt (formerly LEDE) project are: active
>     committers, inactive committers, and non-committers. There is no
>     core developer group or any other specially privileged members.
>     Committers may voluntarily switch between active and inactive status
>     at any time.
>     The commit credentials of inactive committers are revoked and will
>     be restored upon their return to active status.
>     Any active committer may request that another committer be moved to
>     inactive status. This request must be sent by email to the person
>     concerned, with the openwrt-adm mailing list in CC. If the person
>     either agrees or does not respond within 30 days, they will be moved
>     to inactive status.
>     There shall be only full commit rights in any case, no partial
>     access or otherwise restricted access to the repositories.
>     All active committers have the right to vote and are invited to
>     liberally exercise this voting right in order to keep a broad
>     consensus on project matters.
>     To propose changes to project matters or the overall development
>     direction, a formal proposal must be sent to the openwrt-adm mailing
>     list. The proposal must clearly describe the suggested changes and
>     include a specific deadline for when the voting period will end.
>     Active committers may vote to either approve or disapprove the
>     proposal.
>     For the proposal to be accepted, it must achieve a two-thirds
>     majority approval among the active committers who participate in the
>     vote. Additionally, it must receive approval from at least one-third
>     of all active OpenWrt committers, regardless of whether they
>     participated in the vote.
>     Changes to these rules require a 75% majority among the active
>     committers who participate in the vote, as well as 50% approval from
>     all active OpenWrt committers.
>     Frequent contributors may become committers after a simple vote
>     among existing active committers. Project members are free to
>     suggest suitable candidates.
>     Any votes and decisions made will be made public on the project
>     websites.
>     Project infrastructure should be outsourced FOSS community operated
>     services whenever possible in order to allow project members to
>     focus on actual development efforts.
>     Any infrastructure that cannot be outsourced and/or is operated by
>     the project itself shall be administrable by at least three
>     different people to reduce the likelyhood of the project getting
>     locked out due to operators being unreachable. Responsible operators
>     for the various services shall be documented publicly.
>     The project will not offer email accounts under its project domain
>     for privacy and equality reasons.
>     Be nice to each other.
>     ------
> 
>     The current version with change to members.
>     ------
>     The roles within the OpenWrt (formerly LEDE) project are: active
>     members, inactive members, and non-members. There is no core
>     developer group or any other specially privileged members.
>     Members may voluntarily switch between active and inactive status at
>     any time.
>     The commit credentials of inactive members are revoked and will be
>     restored upon their return to active status.
>     Any active member may request that another member be moved to
>     inactive status. This request must be sent by email to the person
>     concerned, with the openwrt-adm mailing list in CC. If the person
>     either agrees or does not respond within 30 days, they will be moved
>     to inactive status.
>     All active members have the right to vote and are invited to
>     liberally exercise this voting right in order to keep a broad
>     consensus on project matters.
>     To propose changes to project matters or the overall development
>     direction, a formal proposal must be sent to the openwrt-adm mailing
>     list. The proposal must clearly describe the suggested changes and
>     include a specific deadline for when the voting period will end.
>     Active members may vote to either approve or disapprove the proposal.
>     For the proposal to be accepted, it must achieve a two-thirds
>     majority approval among the active members who participate in the
>     vote. Additionally, it must receive approval from at least one-third
>     of all active OpenWrt members, regardless of whether they
>     participated in the vote.
>     Changes to these rules require a 75% majority among the active
>     members who participate in the vote, as well as 50% approval from
>     all active OpenWrt members.
>     Frequent contributors may become members after a simple vote among
>     existing active members. Project members are free to suggest
>     suitable candidates.
>     Any votes and decisions made will be made public on the project
>     websites.
>     Project infrastructure should be outsourced FOSS community operated
>     services whenever possible in order to allow project members to
>     focus on actual development efforts.
>     Any infrastructure that cannot be outsourced and/or is operated by
>     the project itself shall be administrable by at least three
>     different people to reduce the likelyhood of the project getting
>     locked out due to operators being unreachable. Responsible operators
>     for the various services shall be documented publicly.
>     The project will not offer email accounts under its project domain
>     for privacy and equality reasons.
>     Be nice to each other.
>     ------
> 
>     _______________________________________________
>     openwrt-adm mailing list
>     openwrt-adm at lists.openwrt.org
>     https://lists.openwrt.org/mailman/listinfo/openwrt-adm
>