The RFC discussion process?

5 years ago by Mike Schinkel — view source

unread

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.

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:

Alternatives to the RFC?
Enhancements to the RFC?
Modifications to the RFC?
Other features that are a pre-requisite for the RFC's feature?
Other features that would add value to the RFC's feature?

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?

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.

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

5 years ago by Benjamin Eberlei — view source

unread

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.

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:

Alternatives to the RFC?

Enhancements to the RFC?

Modifications to the RFC?

Other features that are a pre-requisite for the RFC's feature?

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.

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.

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

5 years ago by Arnold Daniels — view source

unread

Arnold Daniels - Chat @ Spike [5wb22]

Alternatives to the RFC?

Enhancements to the RFC?

Modifications to the RFC?

Other features that are a pre-requisite for the RFC's feature?

Other features that would add value to the RFC's feature?

Everything you list is appropriate to talk about as feedback to an RFC.

IMHO what you see with the object initializer discussion, has gone beyond "I think named arguments is a good alternative, because ...". A big part of the thread is about how to best implement named arguments and other (possibly alternative) features. This overshadows the topic of the original RFC.

Additionally, even if the general consensus is that named arguments are indeed a better alternative, it doesn't help to advance PHP forward, since no progress is being made to implement that feature.

As such, it would be preferable if the RFC about named arguments (https://wiki.php.net/rfc/simplified_named_params) was revived and discussed out of context of the object initializer RFC.

5 years ago by Mike Schinkel — view source

unread

Arnold Daniels - Chat @ Spike [5wb22]

Alternatives to the RFC?

Enhancements to the RFC?

Modifications to the RFC?

Other features that are a pre-requisite for the RFC's feature?

Other features that would add value to the RFC's feature?

Everything you list is appropriate to talk about as feedback to an RFC.

IMHO what you see with the object initializer discussion, has gone beyond "I think named arguments is a good alternative, because ...". A big part of the thread is about how to best implement named arguments and other (possibly alternative) features. This overshadows the topic of the original RFC.

Additionally, even if the general consensus is that named arguments are indeed a better alternative, it doesn't help to advance PHP forward, since no progress is being made to implement that feature.

As such, it would be preferable if the RFC about named arguments (https://wiki.php.net/rfc/simplified_named_params) was revived and discussed out of context of the object initializer RFC.

To clarify again, I had these questions before the Object Initializer RFC was proposed.

Please do not assume I asked these questions because of any form of "sour grapes" about the Object Initializer RFC discussions. Yes I want object initializers but my questions were not a passive-agreesive way to try and get that to pass. They are honest questions unrelated to the Object Initializer RFC that I have wondered about based upon my reading of all the discussion on the recent contentious RFCs.

I created a new thread so that my questions could be discussed in the general context and not in the context of Object Initializer RFC. The only reason I referenced the Object Initializer RFC because it was a recent example and thus a convenient one to reference. I now wish I had not included any examples in my list of questions because it has caused the answers to be focused on that RFC and not RFCs in general.

-Mike