Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109523
MIME-Version: 1.0
References: <CA+kxMuSQ0FcRvi1_4h8qSJmrEBZ1gezju1BKLmAV2iLv6xjnZA@mail.gmail.com>
In-Reply-To: <CA+kxMuSQ0FcRvi1_4h8qSJmrEBZ1gezju1BKLmAV2iLv6xjnZA@mail.gmail.com>
Date: Fri, 3 Apr 2020 12:46:08 -0400
Message-ID: <CAPKYkKx_2kx1x6gMiUmX0f-QK_GWGD3B9F7byeqL3vudmDKcYg@mail.gmail.com>
To: Dan Ackroyd <Danack@basereality.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000024ec2505a265a8be"
Subject: Re: [PHP-DEV] Understanding RFC attitudes
From: chasepeeler@gmail.com (Chase Peeler)

--00000000000024ec2505a265a8be
Content-Type: text/plain; charset="UTF-8"

On Fri, Apr 3, 2020 at 12:38 PM Dan Ackroyd <Danack@basereality.com> wrote:

> Hello Internals,
>
> The trade-offs that are good for a project like core PHP are quite
> different from the trade-offs from other projects.
>
> People are sometimes quite surprised by the attitude other people have
> on how best to maintain and improve PHP.
>
> I'm hoping that documenting my understanding of the attitudes that
> have been taken during RFC discussions, might avoid some of the
> surprise factor in discussions and so make the conversations be less
> confrontational.
>
> https://github.com/Danack/RfcCodex/blob/master/rfc_attitudes.md
>
> To be clear, this is only meant to help people understand other
> people's view-points. It is not a fixed set of attitudes that I think
> either are or should be followed.
>
> It's also not aimed at making everyone agree on all topics, but just
> to help set people's expectations on how any particular RFC might be
> received.
>
> cheers
> Dan
> Ack
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I think this is a good idea. It appears to be a fair overview of various
topics. Personally, instead of organizing it into the two main areas that
you did, I think it would be better to maybe just list the various types of
arguments used for/against RFCs, and what the pro/con positions are. As it
is currently written, anything in the "less likely to pass" section might
be taken as something that should be avoided - even in cases where such
things do make sense. If, instead, we lay it out as "If you propose this,
these are the arguments you're going to get as objections, and here are
some of the justifications that have been used so far" someone might better
be able to determine if their RFC for such a topic is justifiable, and if
so, preempt some of the objections.

-- 
Chase Peeler
chasepeeler@gmail.com

--00000000000024ec2505a265a8be--