[RFC] Rethink the voting / decision making process

[David Lang]

On Sun, 5 Jun 2016, Jo-Philipp Wich wrote:

> Hi,
>
> so thinking more about it and about the input of your guys I'd propose
> the following adjustments:
>
> - We define the group of voters as those people being mentioned on the
>  about page and decouple the commit requirement, means commit access
>  implies voting but not every voter must be a committer
>
> - Appointing new voters happens after a simple majority decision
>
> People qualifying as voters are those being publicly active in the
> package feeds or mailing lists, regardless of whether this activity
> happens in the form of patches or general feedback.
>
> It is then up to the people deciding on the appointment to judge whether
> some suggested person qualifies.

Sounds reasonable to me.

Are you going to be looking for people to suggest themselves? or are you going 
to be reaching out to people you think are 'active enough' to invite them?

Is it a simple majority of people who vote? or a simple majority of all voters? 
What sort of timeframe to vote (i.e. if something doesn't get a majority in 3 
days is it dead? or a week?)

Add these details and I think you have a good document on how lede decisions are 
made.

> I like the idea of technical subcommittees but I am not sure whether
> we're a big enough group for this yet - it probably makes no sense to
> divide 13 people into several committees, for me this sounds like
> something that should be done if the project approaches the 50-100
> people mark.

even then, I think it's only worth splitting if you find that too many people 
don't care enough to vote or are bothered by the admin traffic on a topic they 
don't care about. Default to 'big tent' decisions.

David Lang