[RFC] Rethink the voting / decision making process
john at phrozen.org
Mon Jun 6 04:02:05 EDT 2016
On 05/06/2016 22:12, David Lang wrote:
> On Sun, 5 Jun 2016, Jo-Philipp Wich wrote:
>> 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?
the way it worked until now is that we invited people based on their
constructive, focused and usefull contributions. personally i would like
to see people also contribute commits to get a voting right.
> Is it a simple majority of people who vote? or a simple majority of all
for rule/governance changes we should got for a 2/3 vote
> 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?)
until now people were very responsive and we had apparent results within
1 hour. also i'd like to note that until now we had no "i dont want
that" votes. all votes till now were unanimous.
> Add these details and I think you have a good document on how lede
> decisions are made.
yes, i think we should try to draft a proposal this or next week and put
it up for public review.
>> 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.
when we get to that point we should introduce a delegation system
More information about the openwrt-adm