[haiku-development] Re: Formalize voting rules

  • From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Fri, 13 Nov 2015 10:46:58 +0100

On 11/13/2015 01:06 AM, Jonathan Schleifer wrote:

Suggestions? Additions?

Different to how we did it so far is: 1.) A definition of when a vote
reached a decision. Right now, that has been completely undefined as
far as I know, which meant you could declare a decision to be reached
after just one vote in theory ;). 2.) Addition of a quorum

I'm not fond of the 51% rule. The status quo is to wait for a week (or a given time in the mail that started the vote, but not less than a week), and then just look at the votes given in that time to reach a conclusion.

Usually, we don't have very controversial decisions to make, and since developers are lazy (and rightly so), they don't cast their vote when they are already 4 +1s and no -1 -- the end result is already clear so there is no need to steal everyone's time by asking for even more mails to be written.
There is also no need to track who is an active developer, and who isn't in that case: those that really care will vote. Let the others choose to not be involved without blocking anything.

I don't think there were any issues with the votes we had in the past, so I see little reason to make them extra complicate for little to no benefit.

However, I see some merit in your proposal, and would suggest to label such a mechanism specifically, and use it for "game changing" or fundamental votes, like "ditch gcc, and switch to clang", or "expel Axel as he breaks the build too often" :-)

In that case, either the one starting the vote would refer to that extra rules, or some other developer would ask for those rules when he thinks that this vote is so special.

In general, the first rule should be that we have to discuss before having a vote at all. That already includes only people actually interested in the topic.

Bye,
Axel.

Other related posts: