Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104929
MIME-Version: 1.0
References: <CA+kxMuQnOre3NTb2A2Hcgs1UakiD2g3ZCzXUO4sNBYjiQh75GA@mail.gmail.com>
 <CALKiJKoq26MFetzZr27caW61nMvywdRSG1Gn3U=so4+8CuvvVw@mail.gmail.com> <CA+kxMuQ9HuNcvgvgiyFG_qDJuyfZxmuqdDuWezstPK=eyR0xxw@mail.gmail.com>
In-Reply-To: <CA+kxMuQ9HuNcvgvgiyFG_qDJuyfZxmuqdDuWezstPK=eyR0xxw@mail.gmail.com>
Date: Mon, 25 Mar 2019 14:38:17 +0000
Message-ID: <CALKiJKpfen21mrqZKf7J17fuAtpHLrjCS+pPOQezOc0oB-5mKw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000063730a0584ec28cb"
Subject: Re: [PHP-DEV] RFC Process: more productive conversations
From: rowan.collins@gmail.com (Rowan Collins)

--00000000000063730a0584ec28cb
Content-Type: text/plain; charset="UTF-8"

On Mon, 25 Mar 2019 at 14:02, Dan Ackroyd <Danack@basereality.com> wrote:

> 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.
>


That feels pessimistic to me: is assumes that the author feels unhappy with
the RFC failing, rather than taking on board the feedback. You already have
a section headed "Don't be too put out if people don't like your RFC", and
I think taking on board why people disagreed is a big part of that.



> * 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.
>


That's certainly an issue, which I've suggested before in the form of an
"Internals FAQ".  However, it somewhat contradicts your previous point:
you're now asking someone to do *even more work* after an RFC is rejected,
to summarise it in a new format, in a new location. Either that's the RFC
author, or it's someone interested enough that they could offer to write it
in the RFC itself.

As RFCs re-raising previous ideas, they can and should link to and explain
their relationship to related RFCs, and this should probably be in the
guidelines if it's not already.




> > 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.
>


That's because it's an unhelpful comment. What does "terrible" mean? Other
than "I assume you raised this in bad faith", there is *always* a more
productive explanation than that - "I don't think this fits the
style/purpose/scope of the language", "I think this would encourage/only be
useful for bad practices", etc.



> > 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.
>


Right, which is why I said I'm on the fence about *forcing* it, but that we
should at least *encourage* it.



> 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.
>


I don't think that follows. If the answer to "what would make you change
your mind?" is "nothing", that's still useful feedback - it tells future
RFC authors not to approach the suggestion at all.



> 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.
>


Yes, the important thing is that the different reasons for no votes are
captured, not that the exact counts for each are tallied. It's also a
reason to add a text field to the voting widget: it doesn't invite
responses in the same way a post to the mailing list thread does.

I think a reasonable compromise is to say that voters should mention the
reasons they're voting no if they have not already been mentioned; but that
proposers should assume that votes without a reason are agreeing with
previously stated reasons. That discourages voters assuming proposers can
read their mind ("well, obviously it's bad") but also discourages proposer
pestering and cross-examining voters.

Regards,
-- 
Rowan Collins
[IMSoP]

--00000000000063730a0584ec28cb--