Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65287
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain meetme.com designates 74.125.149.205 as permitted sender)
Sender: Will Fitch <wfitch@meetme.com>
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
In-Reply-To: <CAAyV7nEWFMqBhKE-Q=MquMANmWp+p27Dn-X7nA5ocWRDHshEKA@mail.gmail.com>
Date: Mon, 28 Jan 2013 14:27:27 -0500
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <B85E87D0-C8DF-48F4-B495-446C3B7AF871@php.net>
References: <CAAyV7nEWFMqBhKE-Q=MquMANmWp+p27Dn-X7nA5ocWRDHshEKA@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Subject: Re: [PHP-DEV] Purpose of voting
From: willfitch@php.net (Will Fitch)


On Jan 28, 2013, at 2:14 PM, Anthony Ferrara <ircmaxell@gmail.com> =
wrote:

> Hey all,
>=20
> After reading the Voting Periods email thread, I'm left wondering a =
simple
> question (which has a difficult answer):
>=20
> What should we be voting on when voting on an RFC: on the RFC proposed
> feature, or on the patch itself?

Personally, I'm discussing/voting on the feature.  We do tend to combine =
our discussions, but voting seems to be directly for the proposed =
feature.  I don't necessarily disagree with this approach, as we tend to =
hash out the implementation during the discussions.  It might save RFC =
authors a lot of time and keyboard taps if we discussed/voted on a =
feature prior to discussing implementation.  This could open the door =
for a flood of feature requests in the form of RFCs, but I don't believe =
that would happen.

One of the advantages of combining the patch(es) with an RFC is it shows =
the author has put forth an effort in thinking the idea through.  That =
said, a "rule of thumb" (or official rule) that RFC authors should =
provide a patch once the feature has been approved might work. =20

In the end, separating the two would end up saving the RFC's author and =
this list time as to whether a feature should be considered.  However, =
there are times where the implementation could change the outcome of the =
feature vote itself.

>=20
> I've always approached it as we're voting for the concept (and =
details)
> provided in the RFC. But it appears that other people have been voting =
on
> the specifics of the attached patch (so theoretically an RFC could be
> rejected entirely because some people don't like part of the =
implementation
> in C, but are fine with the PHP details).
>=20
> I'll leave out my opinion (and justification) for now, I'm curious =
what you
> all think...
>=20
> Thoughts?
>=20
> Anthony