Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65306
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.46 as permitted sender)
MIME-Version: 1.0
Sender: patrick.allaert@gmail.com
In-Reply-To: <8443b1f0eaec6316a3e5791c097d5c49@mail.gmail.com>
References: <CAAyV7nEWFMqBhKE-Q=MquMANmWp+p27Dn-X7nA5ocWRDHshEKA@mail.gmail.com>
	<8443b1f0eaec6316a3e5791c097d5c49@mail.gmail.com>
Date: Mon, 28 Jan 2013 23:11:21 +0100
Message-ID: <CACwt+Jfa8xaJ+RYcvkpdG0OS+7mEFfPS1U04adTGj1NTf0jvSQ@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Anthony Ferrara <ircmaxell@gmail.com>, PHP Development <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Purpose of voting
From: patrickallaert@php.net (Patrick ALLAERT)

2013/1/28 Zeev Suraski <zeev@zend.com>:
>> What should we be voting on when voting on an RFC: on the RFC proposed
>> feature, or on the patch itself?
>
> I think it should be exclusively on the concept.  We never vote about code
> changes anywhere - including when we refactor existing parts.  Why would
> we vote about the implementation here?

Just to +1 Zeev's opinion here.
It's perfectly valid to accept an RFC and comment on the
implementation on what should be improved or what sucks in it.

If one is voting "no" mostly because of the implementation, then I
would say that there is a lack of information in the voting process
when saying "no". (No why... ?)

Side node: whatever the formal "process" we will use we will always
have to be flexible enough to listen to each other and not falling
into bureaucracy too much.

Patrick