Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:53044
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Mon, 06 Jun 2011 12:32:07 -0400
Message-ID: <14.C2.23189.4010DED4@pb1.pair.com>
To: internals@lists.php.net
References: <887FE7CFF6F8DE4BB3A9535F53AFD06A4930609E@il-ex2.zend.net>
 <4DEBE420.50005@sugarcrm.com>
 <887FE7CFF6F8DE4BB3A9535F53AFD06A4930624C@il-ex2.zend.net>
User-Agent: slrn/pre1.0.0-18 (Linux)
Subject: Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on
 the wiki! (Was: [PHP-DEV] 5.4 moving forward))
From: weierophinney@php.net (Matthew Weier O'Phinney)

On 2011-06-05, Zeev Suraski <zeev@zend.com> wrote:
> I'm fine if the entire 'Feature selection and development' part goes
> out of the RFC, but if there's any reference to how features are
> determined, we'd better get it right.
>
> Making changes once we've approved this RFC is going to be much
> tougher.  This is big stuff - it's no coincidence we didn't have such
> guidelines for almost 15 years.
>
> 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, 

This is a tough one. I'm typically in favor of having the vote be
completely open to anybody. However, since we're talking language
features, there are a lot of other considerations -- internals folks
will have a much better idea of what the BC and support ramifications
are.

Perhaps two votes should be considered? A "general population" vote, and
an "internals" vote? This would show discrepancies between what users of
PHP want, and how internals is voting. If internals votes against a
feature that the general population has approved, I would expect to see
some sort of "executive summary" showing what technical issues are at
play that led to the internals vote. This would serve as a good
historical record -- and also potentially show where bias lies within
the internals community.

> is 50%+1 enough or do we need stronger majorities for substantial
> language changes (67%/75%), 

I think anything less than a strong majority (2/3 or 3/4) often is
indicative of either ambivalence or strongly competing ideas. The
question is where that threshold should be set (I'd lean towards 2/3
vote.)

> 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, 

I'd argue a 2-3 week period in which to re-work the proposal and
incorporate feedback from the prior discussion/voting periods.

> etc. etc.  I think all of these need to be answered before we let this
> RFC govern how we do feature definition.
>
> Zeev
>
> > -----Original Message-----
> > From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
> > Sent: Sunday, June 05, 2011 11:17 PM
> > To: Zeev Suraski
> > Cc: Pierre Joye; PHP Internals
> > Subject: Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on
> > the wiki! (Was: [PHP-DEV] 5.4 moving forward))
> > 
> > Hi!
> > 
> > > I'd still like to hear from others what they think about my
> > > proposal.  I'd like to update the Release Process RFC with these
> > > suggestions if people like them.
> > 
> > I think these voting process additions totally make sense. But I am
> > not sure it makes sense to put everything in one release RFC. The
> > reason for that is that we don't want to endlessly amend and improve
> > the RFC without having it actually agreed upon, I would rather
> > prefer to agree on what we agree, have it as base for the future and
> > then add other stuff. I've noticed a tendency on the list to lose
> > the major goal behind endless amendments and tweaks and not doing
> > what we agree on because we disagree on some minor detail. So maybe
> > it would make sense to have release RFC separate (without spelling
> > out the voting process there) and voting RFC separate which would
> > define the voting process?

-- 
Matthew Weier O'Phinney
Project Lead            | matthew@zend.com
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc