[haiku-development] Re: Formalize voting rules
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 13 Nov 2015 12:47:40 +0100
On 13.11.2015 01:06, Jonathan Schleifer wrote:
[If you don't have commit access and thus no voting rights, you can stop
reading now.]
Since we had the discussion about formalizing our voting rules, here's my
proposal for it:
1.) Haiku is a democratic project, where all decisions are made by the
developers.
2.) Developers is defined as all persons having commit access to the main Haiku
repository. Active developers is defined as all persons having used their
commit access within the last 365 days.
3.) Only a developer can start a vote.
4.) Each developer has exactly 1 vote on each topic to be voted on.
5.) In order to reach a decision, at least 51% of the active developers need to
cast their vote. Should this quorum not be reached within 1 month, no decision
is reached. After another month, the topic can be proposed again and voted on
again.
I don't really see the point of a quorum. If someone doesn't cast a vote
they are not interested enough in the topic to bother, which I would
consider abstention. I suspect that in many of the votes in the past --
mostly for granting commit access -- the quorum wouldn't have been
reached. Forcing people to cast an explicit +/-0 vote (or risk stalling
the decision making process) creates unnecessary overhead.
I also find a month way too long. I guess even on vacation most people
read their mail every few days at least. In the past votes were usually
only open for a week or two (sometimes even less), depending on gravity
and urgency of the issue. AFAIK that never has been a problem, so I
don't really see a reason to require a long voting period.
6.) In case of a tie, no decision is reached. The same procedure as in 5.)
applies.
Suggestions? Additions?
There had been a discussion regarding formalizing the voting procedure
several years ago and it led to a generally accepted result -- or at
least no one seem to disagree. Koki wrote a summarizing email, which I'm
too lazy to look up ATM, but maybe someone else has a link at hand.
There are a few points that I hopefully recall correctly:
* Votes may not be started out of the blue. They have to be preceded by
a mailing list discussion. There also should be an agreement on what to
vote on exactly in order to avoid unclear or suggestive questions and
answers.
* Besides developers with commit access also other
recognized/distinguished contributors have a vote in non-development
related matters. It's a bit more complicated to decide who has this
status as there is no (need for a) formal process to grant it as there
is with commit access.
CU, Ingo
Other related posts:
