Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72537
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXaP-jyU4wZgheLdCUcEopgwXJRY+j=JnvMMBF4D_x1Mnw@mail.gmail.com>
References: <CAGa2bXaP-jyU4wZgheLdCUcEopgwXJRY+j=JnvMMBF4D_x1Mnw@mail.gmail.com>
Date: Wed, 12 Feb 2014 22:03:02 -0500
Message-ID: <CAL+t6cHiPNVsK_qetBqGM7vXBY4SEa+w50v46CnaDn3khDqcPg@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bfceb1a6e55b104f240ed58
Subject: Re: [PHP-DEV] [RFC DISCUSSION] Have voting options to show reason why
 dislike proposal.
From: theanomaly.is@gmail.com (Sherif Ramadan)

--047d7bfceb1a6e55b104f240ed58
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Feb 12, 2014 at 8:57 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi all,
>
> We have number of RFC that has been declined. It's good we agree not to
> introduce proposal. However, it's not good we don't see the reason why.
> Since RFC is technical discussion, there should be good reasons to oppose
> proposals and these opinions should be used to improve/create another RFC.
>
> I would like to propose RFC to have vote for the reason why user voted "no"
> for the RFC. Additionally, we may have comment plugin to explains the
> reason why.
>
> Users who would like to vote "no" for a RFC, they should explain during
> discussion period or when voting at least. This way, we would have more
> constructive RFC process.
>
> Any comments?
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>


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.

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.

--047d7bfceb1a6e55b104f240ed58--