Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52980
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.153 as permitted sender)
Message-ID: <4DEBFE9F.102@sugarcrm.com>
Date: Sun, 05 Jun 2011 15:09:35 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Zeev Suraski <zeev@zend.com>
CC: Pierre Joye <pierre.php@gmail.com>, 
 PHP Internals <internals@lists.php.net>
References: <887FE7CFF6F8DE4BB3A9535F53AFD06A4930609E@il-ex2.zend.net> <4DEBE420.50005@sugarcrm.com> <887FE7CFF6F8DE4BB3A9535F53AFD06A4930624C@il-ex2.zend.net>
In-Reply-To: <887FE7CFF6F8DE4BB3A9535F53AFD06A4930624C@il-ex2.zend.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Voting Process
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> Honestly there are other parts about the voting process that are much
> hotter potatoes than the points I brought up - such as who gets to
> vote, is 50%+1 enough or do we need stronger majorities for
> substantial language changes (67%/75%), can someone who failed
> passing an RFC just put it up for another vote right away or is there
> some sort of a cool-off period, etc. etc.  I think all of these need
> to be answered before we let this RFC govern how we do feature
> definition.

I think we shouldn't over-formalize this. Certainly if about 50% of 
voters are against something, it does not have consensus. But I do not 
think specifying hard percentages would do us much good, especially if 
we do it without considering case in point. Some things are OK to decide 
on simple majority (like things that have two equally good options and 
we have to choose one, or things that are matters of taste/style, etc.), 
some may require more strong consensus, especially big changes, but I'd 
have very hard time formalizing this upfront.

Currently the "Feature selection and development" basically says "we'd 
have a public vote on features". It doesn't specify how exactly is the 
process for a vote, and while again I think your proposal is good, I 
don't see why it has to be part of this RFC - e.g., if we agree that we 
have to have RFCs and formal non-ML public vote, let's fix that and then 
talk about how exactly we do the vote. The RFC itself says nothing of 
"how", so I don't see why we should mix the question of "should we do 
it" with "let's decide how exactly we going to do it".
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227