[RFC] Rethink the voting / decision making process

Conor O'Gorman i at conorogorman.net
Tue May 31 06:02:38 EDT 2016

On 31/05/16 10:22, John Crispin wrote:
> On 31/05/2016 11:09, Conor O'Gorman wrote:
>> On 30/05/16 17:06, Jo-Philipp Wich wrote:
>>> Hi Conor,
>>> I am still looking around...
>>> The first candidate I looked at was Debian but its project policy
>>> documents read like German tax law, not exactly the simple, yet
>>> democratic project rules I had in mind ;(
>>> ~ Jo
>> Some googling yesterday suggested the idea of sub-committees.
>> I suggest a possible arrangement:
>> Build system (stuff in include/)
>> Toolchain
>> Kernel
>> Platforms
>> Management/Config (procd,netifd,ubus,uci,luci)
>> Packages
>> Documentation
>> Repo, Build and Test Infrastructure
>> Community/Corporate interaction
>> There may not be formal sub-committees, but I think it is useful to
>> consider some sub-divisions of the project.
>> Conor
> i think you are running down the wrong road here. if you start voting on
> implementation details then this will kill the operational ability of
> the project. the areas of voting should be
> * design (website, logo, ...)
> * infrastructure (server locations, services, ....)
> * release (timing, naming, ...)
> * industrial relations (conferences, funding, ...)
> * governance (NGO governance, trademark, rules, ...)
> these are the areas that require voting.
> 	John

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.


More information about the openwrt-adm mailing list