[RFC] Rethink the voting / decision making process

[David Lang]

On Thu, 26 May 2016, Jo-Philipp Wich wrote:

> Hi,
>
> as you might have noticed, the current voting rules are extremely
> simple, IRC centric and not clearly defined.
>
> In order to reach a wider audience I'd ask for your input on how we
> could rework that mechanism to be more fair and representing in the future.
>
> Below are a few random thoughts of mine, with no particular opinion from
> my side yet.
>
>
> 1) Decouple voting right from committer right
>
> Does it make sense at all to keep the committer / voter coupling at all?
> Would it help to redefine committer as someone whose changes got merged?
>
> 2) Dealing with inactive persons
>
> Shall inactive persons lose their voting rights at all? Do we even need
> such a mechanism? Shall we maybe just count majorities within a circle
> of people attending / registering for a vote? That would probably
> eliminate the inactive people problem...
>
> 3) Voting process
>
> During various IRC sessions we decided to try http://liquidfeedback.org/
> - imho this would remove the real time IRC constraints from votes and
> any topic could be freely decided by each member within a suitable time
> frame. Is there anyone with experience in Liquid Feedback who likes to
> share some insights?
>
> 4) Voting proposals
>
> How shall we decide what to even vote on? Shall anyone be free to
> propose something? If so, how?

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.

The question of who votes is a tricky one.

I do not think that it should be restricted to people who have recent commits 
accepted into trunk. People who review code, but don't generate it, people who 
answer questions so that the programmers don't have to, people who contribute to 
documentation (even if they aren't the one with the name in the commit) are all 
very valuable. Even people who just maintain a customized build publicly are 
valuable.

I participate in Rsyslog development, but I have very few code contributions, 
and the most recent of those are several years old. But my analysis of design 
issues prompted the main developer to call me out by name in one of his 
presentations early on (long before I contributed any code), and if you ask a 
question, the odds are about 70% that I will be the one who answers the 
question.

By the current OpenWRT/LEDE voting logic, I should be a nobody who has no right 
to say anything.

But people who get heavily involved are investing their time and acting as 
advocates and should not be locked out.


On the other hand, we saw the mess with Busybox where a developer who had 
essentially abandoned the project a decade or more ago popped up and started 
making demands when they clarified their license to be GPLv2 only (in 
recognition that they were merging GPLv2 source and so the results could not be 
GPLv3 or newer)


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)


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

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)


David Lang