Do we need to talk about OpenWrt Rules?

[Fernando Frediani]

I mostly agree with Rich

Decisions have to be taken sometimes and the worst scenario can be not 
take any decision.

One important thing I would highlight though is that certain topic may 
require extra time to be discussed and explored fully and it is up to 
the person willing to propose it to find out the right time to call a 
vote, not too soon in order to give enough time for people to put up all 
their point of views and not too late to leave the topic to cool down.

Another important thing is to try to feel how critical certain proposed 
changes may be, even if there is a majority of decisonmakers supporting 
it. If the difference is too tight for those not willing to support 
perhaps, it can be a good exercise to evaluate to suspend its vote until 
more decisionmakers can be convinced. Yes I know the majority will 
always take the final decision but sometimes it may not be worth to 
dissatisfy people who have been real long term contributors and do their 
best to reach a consensus (which doesn't mean unanimity at all).

Best regards
Fernando

On 09/12/2020 21:08, Rich Brown wrote:
> Thanks again for these thoughts. Let me respond with some ideas for tomorrow's meeting:
>
>> On Nov 29, 2020, at 4:54 PM, Adrian Schmutzler <mail at adrianschmutzler.de> wrote:
>>
>> I personally don't think that our weakness in this aspect is the lack of a predefined timespan or other regulations on voting. I'd rather see the different availability of certain people and the frequent case that only a fraction of people is interested in a certain topic/aspect as the main problem for reaching a decision. I don't see how a stronger formalization helps us there.
> I have to disagree - I believe that the conditions you describe (the lack of formality of the process and the unavailability of knowledgeable people) are *exactly* the problem we face. Let me use the recent discussion on the OpenWrt-Adm list about whether to require a certificate for LuCI as an example:
>
> - There was significant discussion - pro and con - on the list.
> - Everyone got to state their opinion. It was a strong, well-argued conversation.
> - All that work - did we ever decide? I don't think so.
>
> This is what I mean about "tiptoeing up to a decision." We do all the hard work to lay out the issues, then never finish, never choose one path over the other.
>
> I prefer a bias toward making a decision, even if it's saying "No" to something that might be interesting someday. Even though it can be scary to choose one path over another, we have plenty of things we wish to do. Choosing one means that we can finish it, and bring back the alternative later on if it still seems like a good idea.
>
> What's the harm in not deciding? It means that people who want to base their new work on a particular feature are frozen in place, hoping it will be implemented, but not able to work on something they find interesting or useful.
>
>> Apart from that, I personally think that the current flexibility in creating votes better suits our situation with different votes on different subjects.
> I suspect that my description of the voting process (items #3 & #4 in https://openwrt.org/playground/richb/rules-rc3) was too brief, and obscured my intent. Let me expand:
>
> When a topic interests the OpenWrt group, but needs a formal decision (I would include voting for members) we should follow this process:
>
> a) Any decision maker can make a brief README to describe the proposal, then make a motion asking the group to discuss the proposal
> b) If a second decision maker believes it is worth discussing formally, they can second that motion
> c) Discussion ensues... It can go on as long as seems useful. At some point, all parties and positions will have been heard.
> d) At that point, any decision maker can "call the question" (perhaps updating the original proposal/README to reflect newly gained information) and request a vote on the proposal. That person can set the time for the vote.
> e) (It may be that certain parties wish to continue the discussion, or modify the README, or change the duration of the vote. But at some point, there will be a final proposal to bring to a vote.)
> f) All decision makers vote. The person who called the question tracks votes, reminds members of the deadline, and reports the final vote count.
>
> This sounds cumbersome, except that it's mostly what we do anyway, except for actually getting to a vote. Some examples:
>
> 1) New decision maker. Someone writes a short bio ("Fred Flintstone has done fantastic work revamping the build system. I move that he become a decision maker.") If someone seconds that proposal, there can be a discussion, followed by a call for votes.
>
> 2) Use HTTPS for LuCI. Someone draws up a README saying what it would do, how it might work, how much testing has occurred, how much more work is required, etc. (Note that this information would be really useful when it comes time to write the wiki page...) After someone seconds the motion, we discuss the proposal, which might go through several revisions as new information comes to light. Ultimately, there can be a call for votes, and then a time window for voting.
>
>> There might be topics that require a shorter timespan, while for others the timespan could and should be longer without problems. One improvement in this context might be if the person starting the vote would define the timespan directly in the vote, and when it's over, it's over. But I do consider putting a fixed timespan into the rules as a drawback.
> I agree. That value should not be defined in the rules - whoever calls the question should set the timespan.
>
>> Eventually, many things are unresolved not because the rules of a vote were unclear, but because nobody started that vote in the first place.
> And that's the major reason that I put forth this procedure. First, so that it's clear how someone might start a vote, second, so that a good idea can be formally approved and we can "get on with it", and finally, if there's a lack of support for an idea, that we feel OK about deciding not to spend further time on it.
>
> Thanks - "see" you tomorrow.
>
> Rich
> _______________________________________________
> openwrt-adm mailing list
> openwrt-adm at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-adm