[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.
Conor
More information about the openwrt-adm
mailing list