Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104927
MIME-Version: 1.0
References: <CA+kxMuQnOre3NTb2A2Hcgs1UakiD2g3ZCzXUO4sNBYjiQh75GA@mail.gmail.com>
 <CALKiJKoq26MFetzZr27caW61nMvywdRSG1Gn3U=so4+8CuvvVw@mail.gmail.com>
In-Reply-To: <CALKiJKoq26MFetzZr27caW61nMvywdRSG1Gn3U=so4+8CuvvVw@mail.gmail.com>
Date: Mon, 25 Mar 2019 14:01:47 +0000
Message-ID: <CA+kxMuQ9HuNcvgvgiyFG_qDJuyfZxmuqdDuWezstPK=eyR0xxw@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] RFC Process: more productive conversations
From: Danack@basereality.com (Dan Ackroyd)

On Mon, 25 Mar 2019 at 13:30, Rowan Collins <rowan.collins@gmail.com> wrote:
>
> One suggestion for an additional section: update the RFC with feedback,
> particularly if it is withdrawn or rejected.

I think that knowledge could live separately from the RFCs, which is
why I'm maintaining https://github.com/Danack/RfcCodex

The reasons for doing it separately are:

* the last thing someone wants to do after having their RFC voted down
is spending more time documenting it.

* some ideas have had multiple RFCs, while other ideas are proposed on
the list without having a formal RFC. For both scenarios documenting
why it failed in a single place needs to be elsewhere than an RFC
page.


> It has actually been suggested multiple times that
> voters *should* justify their votes,

Yes. However that is unlikely to provide a useful conversation.
Thinking that the RFC is just a terrible idea is always a valid reason
to vote no. Having people say that "this RFC is terrible" doesn't lead
to a productive conversation.

> so that it's clear whether a future RFC could address the
> perceived problems,

I don't believe forcing people to explain their votes actually does that.

It does something quite similar, of forcing people to try to
articulate how the RFC needs to change for them to change their vote
from a no to a yes. At least that is how I have perceived the
intentions of people who have asked for 'no' voters to explain their
vote.

The problem with that is that some RFCs are just fundamentally not
good and so there isn't any changes that could be made that would make
the RFC acceptable.

In those scenarios, putting pressure on 'no' voters to say what needs
to be fixed, is just putting pressure on people to not vote no.

Additionally in some of the RFC discussions we've had, where the
author has asked for people to explain the 'no' votes, the reasons
have already been said clearly in the discussion phase. But the RFC
author has dismissed those reasons as 'invalid'. Again, trying to
force people to justify their reasons, to the satisfaction of the RFC
author isn't going to lead to a productive conversation.

cheers
Dan