Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106377 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 55497 invoked from network); 5 Aug 2019 16:07:41 -0000 Received: from unknown (HELO mail-pg1-f180.google.com) (209.85.215.180) by pb1.pair.com with SMTP; 5 Aug 2019 16:07:41 -0000 Received: by mail-pg1-f180.google.com with SMTP id r26so3801292pgl.10 for ; Mon, 05 Aug 2019 06:34:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=basereality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=x3GIzBOkXjCEbH38/LlflbJAsL/W2LGKfSb3QXfoEE8=; b=zC1TRTJsi4Lrl8AYBmw/UmdXtPayNxOul6ILH0PcLNQBylC8O0CQBZB77SUVcFo1KK YxC06oWOG/AcxlFSoJVKVbON6k81ncbE6LM5AP45CjL3CPgO5BciEn9ot3P2HHCQJaO7 /eoVs8f+X/e5cJSelIBP0IKl31IpLzJGaWojV6lqKS3oGWtdc5KjPaUVQaZiRbmzhYb6 iyETIy3SCHEuJCNleW56j0rrL16vXjYy90HmN1ZGwKJaVR69pE+e6GsP1ezIxyOkue4k CBux44HYITIw2UuxPZK7PHU/CTpvc2/AaDnpAWhaODyiPOzdcMUTx15sJDgx9XF+oaSD VTDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=x3GIzBOkXjCEbH38/LlflbJAsL/W2LGKfSb3QXfoEE8=; b=Hn8o0aluqaMtIChdMovd49CnGiPII4WBchAvMq7gopIuB2x7iatqWvj8KgX5xIFAeE +LadkXFeER2V4j4ScDk3aDTPgI2xlVhU55leo+MYDO23gyR4NB/x4HmBuzYJzfTGYOVN 3meAIHshHxjMEUdszXP0LcAnYQ0Mc1mKZt5vEM05PPHRMLDLJ0odjOKHeaT54gNKO1ty +0HUJmDCLxvlEgUTuGuexd5PilV0OERj5zviZmBWfDR1+zbkGZbkJdZb46OObpTUEHYR YQ6zvN6qUum2gO1dU6HfjbLoFI60Mlt38B7z/khs8uL2UCKs0ltSSUsXBgBWB5U2tYNj GKaw== X-Gm-Message-State: APjAAAU3OMIviXRcWUNGnMu0rXtGy4aXlz+O4nvjpjZBZrKSsk1jzhrL zDq+RxsN6k++Xg1ERBuiNutDfB6SqZZBJglpWYby2513Uno= X-Google-Smtp-Source: APXvYqw7e1DslsuEqB+XiyXAbqQT5PeRJFdJxG1al5bE6haXL7TBzvBdjFcII1RQc3yQJNaRy7OBa8lEQugTo4nok5Y= X-Received: by 2002:a17:90a:17ab:: with SMTP id q40mr18492063pja.106.1565012044402; Mon, 05 Aug 2019 06:34:04 -0700 (PDT) MIME-Version: 1.0 Date: Mon, 5 Aug 2019 14:33:53 +0100 Message-ID: To: PHP internals Content-Type: text/plain; charset="UTF-8" Subject: Improve visibility of RFC negative feedback From: Danack@basereality.com (Dan Ackroyd) 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. That sounds like an uneven balance of power which tips the balance towards RFCs passing. I think we could balance this by doing something similar to the following: # 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. In the (hopefully) rare cases where the people providing negative feedback can't agree on how that page should be formatted, they may create a new negative feedback page and also put a link to it on the actual RFC page, next to the other 'negative feedback' link. To indicate agreement with any negative feedback, people are free to put their own name (not other peoples names) as a signature after the relevant 'negative feedback' link. 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. # 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." ## 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. ## 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. ## 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. 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. Any thoughts before I spend the time to write this as an RFC? cheers Dan Ack