[RFC] Rethink the voting / decision making process

[Jo-Philipp Wich]

Hi David,

> Voting should take place over a few days (life happens), possibly with a
> provision for early voting. It should not require that people be online
> at a specific time.

Yeah, that is what became clear very quickly, even with the majority of
people being in Europe.

> The question of who votes is a tricky one.
> [...]
>
> So I would suggest that:
>  
> 1. someone with enough recent commits merged should be able to vote
> 
> 2. someone with lots of recent posts on the mailing lists/forums should
> be able to vote
> 
> 3. someone who is providing infrastructure support for LEDE should be
> allowed to vote even if they are not producing code/posts
> 
> 4. someone who is doing a lot of work on bug triaging should be allowed
> to vote (this may just count as posts per #2
> 
> 5. similar to #4, companies/individuals who are contributing significant
> equipment/services to LEDE should have a vote (they vote with their feet
> if nothing else, let them vote directly if they want)
> 
> It is going to be neccessary to prevent excessive bike-shedding by
> people not producing code, so I would suggest making it so that the
> number of voters based on posts be limited to the top N, where N is the
> number of people with recent enough commits or something similar.
> 
> 
> And since commits can be pulled from OpenWRT, this will mean that
> OpenWRT developers are going to be able to vote in LEDE.
> 
> Allowing votes based on the number of posts opens the potential for
> someone who is making lots of negative posts to get a vote.
> 
> In both of these cases, I would say that to start with, see if you can
> live with a small number of 'bad' voters in the pool. While you could
> setup a mechanism to ban voters, the very existance of such a mechanism
> is going to cause problems, let alone invoking it. If there are enough
> LEDE people, a few votes by people hostile to LEDE isn't going to
> matter. If the numbers start getting significant enough, the rules can
> be changed (before they become large enough to dictate the rules)

I very much agree here, we just need to figure out a somewhat objective
way to measure "activity" of a given person.

Maybe the following would work:

 - Add something similar to the 5 activity indicators above to the rules
 - Assume voters to fulfill those criteria and only scrutinize if
   suddenly an unfamiliar face appears
 - In edge cases let the majority decide whether the person is accepted
   as voter (yay, meta-voting :))

> how many commits should be needed? measured by commits or lines-of-change?

I'd handle that similar to the edge case situation for persons; if the
impact of their commits is not obvious then it should be resolved
through discussions among the voting members.

We all know that seemingly simple changes could've required weeks to
debug or reverse engineer something while large commits could be just
reformatting churn...

> how recent should the commits need to be? someone who hasn't contributed
> in a month should definantly be allowed to vote, someone who hasn't
> contributed in 5 years shouldn't (at least not based on being a
> committer, they may qualify based on posts)

I think a time frame between 3 to 6 months is reasonable, means when
there is zero activity from someone during the last three to six months
then his vote should probably be nonbinding, but I think this is an
unlikely edge case of for "bad voters".


~ Jo