[RFC] Rethink the voting / decision making process
david at lang.hm
Thu May 26 14:04:56 EDT 2016
On Thu, 26 May 2016, Jo-Philipp Wich wrote:
> 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
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
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
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
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
More information about the openwrt-adm