[RFC] Rethink the voting / decision making process

John Crispin john at phrozen.org
Mon Jun 6 03:56:48 EDT 2016

On 05/06/2016 19:33, Felix Fietkau wrote:
> On 2016-05-31 12:02, Conor O'Gorman wrote:
>> If there is a census on a topic, of respected project participants, 
>> there does not need to be a vote? Or they can determine what is to be 
>> voted on. But the discussion should be visible. In a particular area 
>> there will be a group of 'respected participants'. But this is just one 
>> suggested road, the meritocratic sub-committee road, according to google.
>> The divisions you have do not consider any of the technical areas I have 
>> mentioned. Who determines what kernel release is used? When the 
>> toolchain moves? How procd/ubus features advance. Effectively at the 
>> moment it is a consensus of core guys. It just might not be that visible.
> When it comes to features, voting should only be used when there is no
> consensus. If we try to plan everything ahead of time and vote on all
> kinds of changes, it only invites pointless bikeshedding discussions and
> developer frustration.
> In my opinion, it is absolutely essential that we adjust the voting
> rules to properly clarify what people can vote on: We must not allow
> people to push through proposals on how other developers should spend
> their time, or what other developers should build.
> If somebody makes a proposal to add some intrusive changes to the code,
> it always has to involve that person also doing the work and refining it
> enough to get it accepted by the relevant maintainers.
> - Felix

the important thing is that we agree on what can be voted on. you
mentioned some good things here. we need to split voting into 2 groups

1) adm/orga stuff, this is stuff like release timing, infrastructure,
new team members, change of governance rules

2) technical stuff, we should not encourage long bike shedding
discussions over the general direction. the voting should be used to
resolve situations where there is no consensus. also intrusive or
controversial changes should be proposed and asked to be endorsed.
asking for an ensdorsement should only be allowed for work you want to
do yourself. (e.g. i cant proposed a vote that felix should do xyz on
mac80211). we should also consider that veto votes should be done in
combination with offering alternative solutions


More information about the openwrt-adm mailing list