Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104924
MIME-Version: 1.0
References: <CA+kxMuQnOre3NTb2A2Hcgs1UakiD2g3ZCzXUO4sNBYjiQh75GA@mail.gmail.com>
In-Reply-To: <CA+kxMuQnOre3NTb2A2Hcgs1UakiD2g3ZCzXUO4sNBYjiQh75GA@mail.gmail.com>
Date: Mon, 25 Mar 2019 13:30:25 +0000
Message-ID: <CALKiJKoq26MFetzZr27caW61nMvywdRSG1Gn3U=so4+8CuvvVw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b4369c0584eb3561"
Subject: Re: [PHP-DEV] RFC Process: more productive conversations
From: rowan.collins@gmail.com (Rowan Collins)

--000000000000b4369c0584eb3561
Content-Type: text/plain; charset="UTF-8"

On Mon, 25 Mar 2019 at 13:04, Dan Ackroyd <Danack@basereality.com> wrote:

> I've written some suggestions on people could have more productive
> conversations which I'm going to maintain here
> (https://github.com/Danack/RfcCodex/blob/master/rfc_etiquette.md), and
> have attached to the end of this email.
>

Hi Dan,

Thanks for putting this together, I think it's a great addition to the
current RFC guidance.

The only part I can see being controversial is this:

> It isn't the responsibility of voters to explain why they're voting no.

It has actually been suggested multiple times that voters *should* justify
their votes, so that it's clear whether a future RFC could address the
perceived problems, or if similar RFCs are likely to receive the same votes
against. I'm on the fence whether making it a hard requirement is
reasonable, but I don't think we should enshrine the opposite.


One suggestion for an additional section: update the RFC with feedback,
particularly if it is withdrawn or rejected.

If someone comes along with a suggestion that's been discussed before, it's
really helpful if we can say "see this page for why it didn't happen last
time, and see if you can fix those issues", rather than just "it didn't get
very far before, but we can't remember why". This is something I intend to
do with my own "locked classes" RFC: I'm probably going to withdraw it
because I don't have time to rework it, but will try to summarise where a
new RFC could pick things up.

Regards,
-- 
Rowan Collins
[IMSoP]

--000000000000b4369c0584eb3561--