Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72541
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.48 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAL+t6cHiPNVsK_qetBqGM7vXBY4SEa+w50v46CnaDn3khDqcPg@mail.gmail.com>
References: <CAGa2bXaP-jyU4wZgheLdCUcEopgwXJRY+j=JnvMMBF4D_x1Mnw@mail.gmail.com>
 <CAL+t6cHiPNVsK_qetBqGM7vXBY4SEa+w50v46CnaDn3khDqcPg@mail.gmail.com>
Date: Thu, 13 Feb 2014 13:02:45 +0900
Message-ID: <CAGa2bXZPOiz+y1h8CPxpeFg7OmN+OhfxZsKm+s66kBY0nj-GPQ@mail.gmail.com>
To: Sherif Ramadan <theanomaly.is@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1133604471703104f241c5a9
Subject: Re: [PHP-DEV] [RFC DISCUSSION] Have voting options to show reason why
 dislike proposal.
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a1133604471703104f241c5a9
Content-Type: text/plain; charset=UTF-8

Hi Sherif,

On Thu, Feb 13, 2014 at 12:03 PM, Sherif Ramadan <theanomaly.is@gmail.com>wrote:

> While I agree with the premise that some people do not voice their
> opinions during the discussion phase of the RFC process, I also disagree
> with the notion that this would somehow prove anymore useful. Those who
> don't care to elaborate on their disapproval from the beginning may not
> chose to do so during the vote anyway, unless we make it a requirement, in
> which case it seems a bit of a kludge.
>
> I think the authors of the individual RFCs should take it upon themselves
> to gather as much feedback as possible during the discussion phase of the
> RFC process in order to collect some constructive set of feedback that
> would help the RFC, should it be declined. I doubt that a short comment
> during the vote will be very meaningful. I find that the more diligent the
> authors of the RFC are, they more likely they are to be motivated by
> gathering, and going over feedback during their discussion phase.
>
>
I agree. I had several RFC for 5.6 and tried that, but people tends to read
RFC on voting.
For example, I closed vote due to more discussions on voting phase. I don't
blame
to discuss during voting phase, I would rather like to discuss for
improvements. In fact,
I'm one of them that read RFCs on voting phase also.

What I would like to know is the reason why people vote "no" for RFC, such
as mbstring-ng.
It's great for mbstring users who would like to provide self contained
internal web application for development/test using CLI server with custom
module, for example. It can be work round, but PHP should remove LGPLed
code IF it is possible :)

My guess is, if we introduce this feature, people who chose to vote no and
> can't come up with a reason may very well just copy and paste other reasons
> they found where someone else voted no. That's perhaps slightly pessimistic
> of a view, but it's my gut feeling.
>
> I do think that adding a suggestions/improvements section to the RFC, in
> the event it is declined, might prove useful should that RFC be taken up
> for consideration at a later version or inherited by another author. That
> might allow the next author to address key points of the RFC that were
> previously not addressed.
>

Thank you for the input!

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a1133604471703104f241c5a9--