Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52982
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=FnhEuJouiaBnHMbdsAHB9OSmVQ6VU/5odDlBlJlf9mYQ73PRU5tbJHWieemCa9aWhT
         mjcgumEjw4V6+R6aprnvbUOhVnlqj7YUskyXmZc0J9hz5ksdI2dhyjq7jwAaP+Cd7wks
         2wbrnDrimvy724aGcGnj10AaPD5jdyvV4juzI=
MIME-Version: 1.0
In-Reply-To: <887FE7CFF6F8DE4BB3A9535F53AFD06A4930624C@il-ex2.zend.net>
References: <887FE7CFF6F8DE4BB3A9535F53AFD06A4930609E@il-ex2.zend.net>
	<4DEBE420.50005@sugarcrm.com>
	<887FE7CFF6F8DE4BB3A9535F53AFD06A4930624C@il-ex2.zend.net>
Date: Mon, 6 Jun 2011 00:20:36 +0200
Message-ID: <BANLkTinYvBYMW+ySw-a+w+NtBXy7hR=49A@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the
 wiki! (Was: [PHP-DEV] 5.4 moving forward))
From: pierre.php@gmail.com (Pierre Joye)

On Sun, Jun 5, 2011 at 10:55 PM, 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.

Getting it totally out makes little sense as it brings us to the point
where we have no idea how we decide what gets in or not, the RMs, etc.

> Making changes once we've approved this RFC is going to be much tougher. =
=A0This is big stuff - it's no coincidence we didn't have such guidelines f=
or almost 15 years.

That was not the reason, the lack of will to define such processes was
the reason despite the numerous requests to have one from in and
outside the core team.

> Honestly there are other parts about the voting process that are much hot=
ter 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 chang=
es (67%/75%), can someone who failed passing an RFC just put it up for anot=
her vote right away or is there some sort of a cool-off period, etc. etc. =
=A0I think all of these need to be answered before we let this RFC govern h=
ow we do feature definition.

I'd to go with a 60% for language syntax, 50+1 for new exts or sapis.
Other question is who can vote. For one, I like to have external
people being able to vote, like frameworks/apps lead developers as
well as @php.net in general (docs people at the same level than core
devs, no diff).



However I'd to say as well as I have no issue at all to define the
basis of the voting system in it and add a note that it may be tuned
later once we have more experiences. That's perfectly fine, nobody
expects us to be perfect with the 1st shot.

Cheers,
--=20
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org