[vote] Update OpenWrt rules

[Hauke Mehrtens]

Hi David and Zoltan,

Thank you David for your response and taking the time to answer the 
mails, I  agree with you.

@Zoltan We are discussing these rule changes since months on the mailing 
list. The idea was to get all the feedback before the vote. I even send 
mails to all members directly because many are not reading the mailing 
list any more. It would have been very helpful if you could have voiced 
your concerns before.


On 10/28/25 11:45, David Woodhouse wrote:
> On Tue, 2025-10-28 at 11:15 +0100, Zoltan HERPAI wrote:
>> Hi,
>>
>> On Thu, 23 Oct 2025, Hauke Mehrtens wrote:
>>
>>> Hi,
>>>
>>> I propose to replace the current OpenWrt rules to the below
>>> version.
>>> This is an official vote. The vote should conclude on 27th November
>>> 2025.
>>>
>>> These are the old rules: https://openwrt.org/rules
>>>
>>> This vote follows the old rules. It needs a two third approval rate
>>> among all
>>> OpenWrt project members to get accepted.
>>>
>>>
>>> Voting page: https://openwrt.org/voting/2025-10-23-rule-update
>> [...]
>>> _**Voting**_
>>>
>>> * All active members have the right to vote and are encouraged
>>>   to liberally exercise this voting right in order to
>>>   maintain 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.
>>>   A simple approval is required.
>>> * All active members who participate in the new vote or voted in
>>> the
>>>   past 6 months before the new vote was started are considered
>>> active
>>>   voters.
>>>   If less than 3 votes occurred in the past 6 months the last 3
>>> votes
>>>   are considered to determine the active voters.
>>> * For a simple approval, the proposal must achieve a two-thirds
>>> majority
>>>   among the active members who participate in the vote.
>>>   Additionally, it must receive approval from at least 50% of the
>>> active
>>>   voters, regardless of whether they participated in the vote.
>>> * For a change to these rules, a 75% majority among the active
>>> members
>>>   who participate in the vote must approve,
>>>   as well as 50% approval from the active voters.
>>> * Neutral votes are considered half-approvals.
>>> * Any votes and decisions will be made public on the project
>>> website.
>>>
>>> _**Infrastructure**_
>>>
>>> * Project infrastructure should be outsourced to FOSS community
>>> operated
>>>   services whenever possible in order to allow members
>>>   to focus on actual development efforts.
>>> * Any infrastructure that is operated by the project
>>>   itself shall be administered by at least three different people
>>>   to reduce the likelihood of the project getting locked out
>>>   due to administrators being unreachable.
>>> * Responsible administrators for the various services shall be
>>>   documented publicly.
>>
>> Hi,
>>
>> No. Can't see why abstaining should count as half-approval, this is a
>> flawed idea, being close to the lines of gerrymandering.
> 
> It doesn't. Where did you get that idea?
> 
> If you don't have a strong opinion about a motion, there are two things
> you can do:
> 
>   1. Just don't vote at all.
>   2. Explicitly cast a 'neutral vote' to say "I've seen this, and I
>      don't mind either way".
> 
> If people don't vote at all, that's when we have concerns about
> gerrymandering, and votes being pushed through without sufficient
> consensus. That's precisely *why* we have a requirement for quorum.
> 
> That's what the second option is for, to allow someone to explicitly
> say that they *were* present and paying attention for the purposes of
> quorum, but that they just didn't have a strong opinion about the
> actual question.

I agree here with David.

>> I also don't agree on outsourcing our infrastructure - keeping it in-house
>> requires resources indeed, which we scarcely have. However, in case of
>> services going down or being shut down, keeping them in-house saves us
>> from being locked out from the very services we have or need without our
>> control ("when will XYZ service be back?"), whatever trusted the
>> outsourced service providers might be.
> 
> I think our experience has been that with services being maintained by
> individual members, that tends to give a single point of failure which
> community resources wouldn't have. But that's not a hard and fast
> constitutional rule being proposed anyway; only a preference. We can
> still make decisions on a case-by-case basis and not be bound be it.

The content of these rules regarding infrastructure did not change.

These are the current active rulers:
 > 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.

I think they did not change since the founding of LEDE.
I also would like to keep them. We are not good at hosting 
infrastructure, see our git.openwrt.org server which has a uptime of 
about 90% nowadays. If you want to change them I would suggest to start 
a separate discussion with a better proposal.

The background of these rules were some problems in the OpenWrt project 
before the LEDE fork. Some infrastructure was hosted by some OpenWrt 
members who would be in legal trouble if they would provide root access 
to the resources to others because of some local laws in Hungary. If 
this resource was not available it often took some time till it was 
fixed because these people could not provide 24/7 support.
>> Also, while highlighting the importance of a vote is appreciated, stating
>> that "if you want further changes to this topic, please approve the vote
>> about this very topic" also sounds flawed to me - sorry Rich.
> 
> Seems eminently sensible to me. We need to go and dig up dormant
> contributors one last time (probably by direct email instead of the
> openwrt-adm list which they're filing into a folder and ignoring), and
> persuade them to vote. Otherwise the project is mired in bureaucracy
> and can't ever make any decisions anyway. We can fine-tune the details
> afterwards once we can be more agile.
> 
> The only reason to *object* to that is if you think it's some kind of
> bait-and-switch and would allow the rules to be subsequently changed to
> be completely different instead of just 'fine-tuning'. But you're not
> even objecting to the substance of the "we need better management of
> quorum requirements" anyway, are you?

Hauke