[RFC] Rethink the voting / decision making process

[Felix Fietkau]

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