[RFC] Rethink the voting / decision making process

[John Crispin]

On 31/05/2016 12:02, Conor O'Gorman wrote:
> 
> 
> 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.

the kernel used is decided as part of the release governance

in regards to procd, that is what i mean, you want a TSC and not a
voting subdivision. what you are sugegsting is that group A decides what
group B should do, which imho wont work. the solution would be a TSC and
that is out of scope of the voting process.

	John