Revising OpenWrt Rules - Minimal-invasive approach

[Fernando Frediani]

Hi Irme

Adrian seems to have reduced the proposed changes which seems pretty 
reasonable for what they meant to improve. They are not major changes 
and seems well written.

Adding a 2 weeks limiting period for voting doesn't solve the issue of 
decisionmakers not reachable for long periods in a row.
Also agree with Adrian that fixed voting period is not always good. Only 
a minimum time may be interesting to have.

Fernando

On 30/11/2020 12:18, Adrian Schmutzler wrote:
> Hi Imre,
>
>> -----Original Message-----
>> From: Imre Kaloz [mailto:kaloz at dune.hu]
>> Sent: Montag, 30. November 2020 16:14
>> To: Adrian Schmutzler <mail at adrianschmutzler.de>; openwrt-
>> adm at lists.openwrt.org
>> Subject: Re: Revising OpenWrt Rules - Minimal-invasive approach
>>
>> Hey,
>>
>> I still don't see how this would make any sensible difference.
>>
>> I suggest simply adding a single change limiting the voting period of any topic
>> to 2 weeks. Problem solved.
> this whole discussion mixes wo different things:
>
> 1. One subject is to open the role of "committers" to other people whose contributions are not primarily code, and thus rename it to something more appropriate. This was the task that the last meeting produced and this is what my proposal is about.
> 2. Another subject is that some people would prefer a fixed voting period. I personally don't like that and this is not included in my proposal here.
>
> Rich's proposal however addresses both subjects, and rewrites most of the other stuff as well.
>
> Best
>
> Adrian
>
>>
>> Imre
>>
>> ________________________________________
>> From: openwrt-adm <openwrt-adm-bounces at lists.openwrt.org> on behalf
>> of Adrian Schmutzler <mail at adrianschmutzler.de>
>> Sent: Sunday, November 29, 2020 22:43
>> To: openwrt-adm at lists.openwrt.org
>> Subject: Revising OpenWrt Rules - Minimal-invasive approach
>>
>> Hi again to this old thread,
>>
>>> My main problem is that a lot of descriptive text is added that - in
>>> my opinion
>>> - is not necessary.
>>>
>>> After all, the proposal reads more like a (explanatory) comment to a
>>> set of rules than a set of rules itself. (E.g. point 3 is actually not
>>> a rule at all, but just an explanation why the other rules are chosen
>>> like they are. In a law or constitution, stuff like that would be
>>> moved into a preamble.)
>>>
>>> And where it actually adds a new precise detail (the vote deadline),
>>> my personal view is that this shouldn't be carved into stone, as it
>>> would make us inflexible. (I'd actually also drop point 7 entirely, as
>>> its first part is actually trivial).
>>>
>>> So, my problem is a general one. I will try to have a look how we can
>>> resolve this situation (always speaking from my personal point of
>>> view, of course) during the next few days.
>> I've had a look at the rules and tried to implement the changes in a more
>> minimal-invasive way. This essentially takes up the motivation of the decision
>> maker tasks from Rich's proposal, but keeps everything else to the existing
>> set of rules. I.e. this is only about the "decision maker" role and how it is
>> named and framed, but not touching the other things.
>>
>> This approach will only change the rules 1, 4 and 5, while everything else is
>> untouched except for the replacement of "committer" with "decision
>> maker". Update rules 1, 4, 5:
>>
>> 1. The OpenWrt project is governed by a group of „decision makers“, who
>> have demonstrated a strong commitment to OpenWrt, e.g. by high quality
>> contributions of code, documentation, organization and/or leadership. The
>> only role distinction within the project is between decision makers and non-
>> decision-makers, there is no core developer group or other specially
>> privileged members.
>>
>> 4. Decision makers being unreachable for three months in a row shall get
>> their status revoked in order to retain the ability to do majority votes among
>> the remaining active decision makers.
>>
>> 5. Decision makers have the right to get access to all project compartments,
>> there is no partial or otherwise restricted access.
>>
>> Apart from that, we have a typo in rule 9:
>>
>> likelyhood -> likelihood
>>
>> Of course, this is just meant as an offer as well, aiming at those people that
>> don't want to rewrite the entire set of rules.
>>
>> Best
>>
>> Adrian
>>
>> _______________________________________________
>> openwrt-adm mailing list
>> openwrt-adm at lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-adm