Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107136
MIME-Version: 1.0
References: <572E7B74-9D56-483F-94A6-F2955C63AA56@gmail.com>
In-Reply-To: <572E7B74-9D56-483F-94A6-F2955C63AA56@gmail.com>
Date: Mon, 16 Sep 2019 08:00:00 +0200
Message-ID: <CAEPJdukdKUTWyMcJSqJCKq2UOSVz6_aNdC7_C5_Bysr0JQfpHA@mail.gmail.com>
To: Mike Schinkel <mikeschinkel@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a1d7d80592a5542a"
Subject: Re: [PHP-DEV] The RFC discussion process?
From: kontakt@beberlei.de (Benjamin Eberlei)

--000000000000a1d7d80592a5542a
Content-Type: text/plain; charset="UTF-8"

Hello Mike,

On Mon, Sep 16, 2019 at 3:50 AM Mike Schinkel <mikeschinkel@gmail.com>
wrote:

> Hi all,
>
> I am relatively new to discussions on the list, and so I have tried to
> understand the ethos of the community to stay within bounds that the
> community generally considers acceptable.
>
> However I am realizing those the bound of acceptability may be fluid at
> times so I am asking explicitly for clarification.
>
> 1. What is acceptable to discuss in an RFC discussion thread?
>
> Recently while discussing object initializers I was told "I think that's
> only true because you've actually proposed a number of related but
> different features," "This is an interesting additional proposal," and
> "This again is an interesting proposal, but completely unrelated to object
> initializer syntax."
>
> But I was replying to a message where a frequent and I believe a respected
> contributor wrote the following, also unrelated to the RFC: "My strong
> preference over this feature would be named parameters, which can provide
> the same abbreviated initializations, but works more consistently with the
> language, e.g. for all of the use-cases I cited above."
>
> I am not naming names because I am not trying to make this about those
> people but instead to understand what is appropriate to discuss during an
> RFC.  So Is it is appropriate to discuss:
>
> 1. Alternatives to the RFC?
> 2. Enhancements to the RFC?
> 3. Modifications to the RFC?
> 4. Other features that are a pre-requisite for the RFC's feature?
> 5. Other features that would add value to the RFC's feature?
>
>
Everything you list is appropriate to talk about as feedback to an RFC. But
the way I see it from participating in this list for a few years, you
should do your research and try to offer feedback in a systematic and
organized way. The discussion phase is at least 2 weeks, for RFCs
discussing a feature for the first time often many months. So you have
plenty of time to formulate your feedback. Also in general feedback from
core contributors often carries more weight for RFC authors than feedback
from non core contributors, because they might rate the implementation more
closely with potential conflicts or problems and have the low level
implications in mind.

I haven't followed the discussion on object initializer fully, but I see
that you messaged 10 times out of all 36 mails, so that is a bit much.
Consider that the RFC author is also just a person doing this in their free
time and wants to make effective use of that.

In general, the RFC author usually has more say in the implementation
details and syntax, because they are bringing forward the proposal and
implementation, meaning the burden of work is on them. Especially syntax is
often very subjective, so convincing the RFC author of a different approach
requires compelling arguments, often technical from an engine perspective.


>
> 2. Are "amendments" acceptable for RFC discussions?
>
> I am thinking of Congress in the USA, Parliament in the UK, and other
> political governing bodies. My understanding is that bills are introduced
> and they have the possibility of being amended by other members of the
> political body.
>
> Comparing that to the RFC process it seems RFCs are like bills; is there
> an amendment process, and if so how does it work?  From what I can to amend
> an RFC requires getting the original submitter to modify it, which if that
> is the process that is understandable.
>
> However, what seems strange is that I also understand there is a 6 month
> moratorium on revisiting a topic that did not pass by RFC, but an RFC could
> potentially not pass because of details in the RFC and not because the
> overall idea is bad.
>
> If I understand correctly, this means others cannot restart a topic for 6
> months because the person who first drafted the failed RFC did not or would
> not incorporate aspects that might have allowed it to pass?
>

Amendments are up to the discretion of the the RFC author to include based
on feedback. It happens that several people team up, or merge efforts.
There also have been a lot of competing RFCs that were voted or discussed
on at the same time. So if you feel strongly about a different approach,
then you might want to turn it into an RFC. See named params vs skip params
or scalar type hints v5 vs coercive type hints.

You can offer a competing RFC in a shorter time frame. The 6 month are just
for the original RFC + author.

>
> 3. Why is there not more transparency for why RFCs pass or do not pass?
>
> Looking in from the outside I see is almost no transparency related to
> reasons why RFCs pass vs. don't pass. When I visit the RFCs of past I see
> lots of votes but almost no rationale why those votes passed or failed.
>
> There are a few active members on the list, but many more people who have
> a vote who I think rarely if ever comment on the list.  So it seems
> impossible to determine what the objections are from the people who vote
> against an RFC.  Which means it will be hard to address their concerns as
> time goes on and other languages evolve because of userland demand to add
> the features that PHP voted down.
>
> Unlike the US Supreme Court and I assume many other nation's supreme
> courts, the people with an RFC vote are not required to write or join an
> opinion as to the reason for or against an RFC.
>
> This unfortunate state means the rationale for the PHP group voting for or
> against an RFC is lost to the mists of time, except for the history left by
> the few vocal people who have the free time to participate on the list in
> discussions. Most of the people with a vote rarely opine on the list, or
> that is the impression I am getting.
>

This is a regular discussion point on the list, with the general idea is
that -1 voters should provide some rational on the list, but that is not
happening often. You'll find that this repository from Dan is an excellent
resource on failed RFCs: https://github.com/Danack/RfcCodex

You can also do research on the mailing list for the voting and discussion
threads, for example using news.php.net or externals.io as readers you can
search for previous discussions.

>
> ----------
>
> Thanks in advance for reading and responding to these questions. And based
> on the replies, I may have a few more follow up questions.
>
> -Mike

--000000000000a1d7d80592a5542a--