Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106378
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=turbo-smtp; d=php.net;
	h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type;
	b=EKvoQVx/0V70/muvSoD1oF5aZzWNOzQkGBCunlVomox7PirBx5xaaU3Vx2n00T
	xwbuxQnuaqVQg0fANJWJcvcTB1L1FDe37xmdgy4AeralaGG1l12BD9Neij2yo7U/
	/jwJPFvvWDcwTtzpuTKG7gjYA0WgYMb/nOjofpBDJ5K0M=;
MIME-Version: 1.0
References: <CA+kxMuSOL38aEmru5_YpnQpfVcZTAAZ-D9wQvgeb42fojDcZ=w@mail.gmail.com>
In-Reply-To: <CA+kxMuSOL38aEmru5_YpnQpfVcZTAAZ-D9wQvgeb42fojDcZ=w@mail.gmail.com>
Date: Mon, 5 Aug 2019 21:40:40 +0300
Message-ID: <CAJHtznzKCQ4mPe6G09ddQX-9KJ1WWRAvZZMe1ro=b=JSj3uEQg@mail.gmail.com>
To: Dan Ackroyd <Danack@basereality.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000026b10b058f630cd3"
Subject: Re: [PHP-DEV] Improve visibility of RFC negative feedback
From: zeev@php.net (Zeev Suraski)

--00000000000026b10b058f630cd3
Content-Type: text/plain; charset="UTF-8"

>
>
> On Mon, Aug 5, 2019 at 4:34 PM Dan Ackroyd <Danack@basereality.com> wrote:

> So, recently there was some discussion about RFCs that have passed
> despite there being some strong objections to them.
>
> I think there is a fundamental problem that could be addressed here,
> in that the arguments 'for' an RFC have much higher visibility than
> the arguments 'against' an RFC. The RFC page, which presents the
> arguments for an RFC, is a link that is emailed round and can be
> linked to from other sites. The arguments against an RFC are contained
> only within an internals email thread. Not only is it much more
> difficult for people to discover these, as there are part of an email
> thread they might not be written as concisely and as clearly as they
> could be.
>

Dan - thanks a lot for your work on this.  I think you articulated the
problem very well and came up with good solutions.


> # Proposal - improve visibility of negative feedback
>
> When someone creates an RFC, near the top of that page they should
> create a link to a separate page that will contain negative feedback.
> People other that the RFC author are free to put whatever negative
> feedback think is appropriate on that 'negative feedback' page.
>

Do we need it for every RFC?  Many (if not most) RFCs don't have inherent
'opposers', so it might be a bit too much to always require the existence
of a negative feedback page.  Some may go as much as saying it encourages
negative feedback...  That said - it's a huge improvement over the current
situation.

Perhaps instead we can say that we allow the creation of such a negative
feedback page - whether by the author (preemptively / later on) or by
anyone else.  That means that if the need arises - there'll be a standard,
guaranteed way of doing it.

Another thing to think about is where in the RFC this should be
positioned.  In a lengthy RFC, people may notice it if it's somewhere in
the middle.  This in itself may become a point of contention.  I think that
if there's a negative feedback page - there should be a pointer at the RFC
header, that will in turn point to a section in the RFC - which will
include negative feedback link(s) and signatories.  The section itself
should probably be at a standard place as well, probably at the end of the
RFC above the voting options.

Changing the process to add more visibility to negative feedback with
>
something like the above wouldn't add much burden to the RFC process,
> and could improve the outcomes in some cases.
>

Agreed.


> # Proposal - set a standard text to used when announcing voting
>
> When the vote is opened, and the announcement is made we should have
> some standard text to be used to remind people to read the dissenting
> feedback. i.e. something like:
>
>  "Voters are reminded to please read all feedback given. If some
> feedback hasn't been addressed by the RFC, and has to be added by
> someone other than the RFC author, voters should read that dissenting
> feedback, and weigh that in whether to vote in favour of the RFC or
> not."
>

If we do that - I would consider adding the negative feedback URL to the
message.   People will quickly learn to ignore any boilerplate...

## Reasons for not putting the negative feedback on the same page as the RFC
>
> Putting the negative feedback on the same page as the RFC would have
> problems with multiple people editing one document and possibly not
> agreeing on the formatting.
>
> It could also have problems in making the RFC harder to read, if for
> example someone decides to write 20,000 words on why an RFC is bad,
> that would make it more difficult to read the RFC.
>

I agree.  I think it should be allowed to include the feedback within the
RFC text itself if at least one of the RFC authors explicitly allows it,
but not otherwise.  It probably makes sense to allow said author with
withdraw the agreement, and move to the link approach.
It's not quite the same but https://wiki.php.net/rfc/php6 included two
opposing views, and was still managed reasonably.  This requires good faith
and agreement from both sides.


> ## Reasons for signing negative feedback
>
> If people similar to the people who were kicked off the internals list
> for being too negative want to write some negative feedback, they're
> free to do that, and then other people free to not put much value on
> that.
>
> If people who have more weight in the community are giving feedback,
> and they all object strongly enough to sign their name, then it
> behooves everyone to read that feedback.
>
> As a side benefit, I think this would also help the 'discussion only
> starting when the voting is opened' problem, as it would allow people
> to indicate how they are going to vote.
>

In general, I think the negative feedback should be predominantly a summary
of points raised and discussed on internals@.  The discussion should
continue to happen on internals - with the negative feedback page (if one
is needed) being the summary of the points brought up on the list.  That's
in the same way that positive feedback, ideas for improvement or
constructive criticism aren't conveyed by edits to the RFC, but first on
internals - and (as needed) are later merged into the RFC by the author
(or, from time to time, the author would let others improve it directly
instead).  If that happens - the folks behind the feedback will be known
anyway.  That said - I think it's fine to require a signature to make the
information easier to access.


> ## Why not just enforce the current RFC rule.
>
> So we apparently already have a rule that says:
>
> https://wiki.php.net/rfc/howto
>
> > Listen to the feedback, and try to answer/resolve all questions. Update
> > your RFC to document all the issues and discussions. Cover both the
> > positive and negative arguments. Put the RFC URL into all your replies.
>
> I think one of the reasons no-one is doing that is that it's just too much
> work


I think the fact that few people like arguing against their own ideas
probably also plays a role.  Combined - it's - as you say - a lot of work,
but also a lot of not-so-pleasant work, which means it does not get done.

>
>
It's also just not possible to summarise some of the arguments in a
> neutral way, and instead if the RFC author attempts to summarise the
> negative arguments, it would provoke heated arguments.
>
> Changing the responsibility of documenting the negative feedback from
> the RFC author to people saying that negative feedback, would mean:
>
> * it's more likely to be done.
> * it doesn't add to the work needed to be done by an RFC author.
> * it avoids heated debate about whether some feedback is relevant or not.
>
> In addition, this proposal make it clear and straight-forward for
> people who wish to leave negative feedback what to do if the RFC
> author forgets to create the page for negative feedback (create it
> themselves), rather than trying to force the RFC author to do more
> work.
>

Agreed.


> Any thoughts before I spend the time to write this as an RFC?
>

I think one part which may be missing here (emphasis on 'may') is
encouraging  the RFC author to address the negative feedback - both on the
list, and later on in the RFC itself.  I.e. - what are their thoughts on
it, why they still think it's a good idea, or how they will address the
flaws.  I don't think we can require it, but I think we should encourage it.

Thanks again for your work on this!

Zeev

--00000000000026b10b058f630cd3--