[RFC] Rethink the voting / decision making process
john at phrozen.org
Tue May 31 06:05:17 EDT 2016
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/)
>>> Management/Config (procd,netifd,ubus,uci,luci)
>>> 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.
>> 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.
> 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.
More information about the openwrt-adm