The RFC discussion process?

  107131
September 16, 2019 01:49 mikeschinkel@gmail.com (Mike Schinkel)
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?


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?

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.

----------

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
  107136
September 16, 2019 06:00 kontakt@beberlei.de (Benjamin Eberlei)
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
  107141
September 16, 2019 07:39 mike@newclarity.net (Mike Schinkel)
Benjamin,
 

 
Thank you for your comments.
 

 
One thing I want to clarify though; your reply seems to imply that I asked this questions solely because of the object initializer RFC.    That is not the case.    I had these exact same questions before the   object initializer RFC was submitted based on reading other people's comments on other RFCs.
 

   
-Mike
   
 

 
 

 
 
> > On Sep 16, 2019 at 2:00 AM, mailto:kontakt@beberlei.de)> wrote: > > > > 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 >
  107146
September 16, 2019 08:10 arnold.adaniels.nl@gmail.com (Arnold Daniels)
[Arnold Daniels - Chat @ Spike](https://www.spikenow.com/?ref=spike-organic-signature&_ts=5wb22)	[5wb22]

On September 16, 2019 at 7:40 GMT, Mike Schinkel <mike@newclarity.net> wrote:

> > > > 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.
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.
  107150
September 16, 2019 08:31 mike@newclarity.net (Mike Schinkel)
> On Sep 16, 2019, at 4:10 AM, Arnold Daniels nl@gmail.com> wrote: > > [Arnold Daniels - Chat @ Spike](https://www.spikenow.com/?ref=spike-organic-signature&_ts=5wb22) [5wb22] > > On September 16, 2019 at 7:40 GMT, Mike Schinkel <mike@newclarity.net> wrote: > >>> >>> 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. > > 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
  107153
September 16, 2019 08:54 kontakt@beberlei.de (Benjamin Eberlei)
On Mon, Sep 16, 2019 at 9:39 AM Mike Schinkel <mike@newclarity.net> wrote:

> Benjamin, > > Thank you for your comments. > > One thing I want to clarify though; your reply seems to imply that I asked > this questions solely because of the object initializer RFC. That is not > the case. I had these exact same questions before the object initializer > RFC was submitted based on reading other people's comments on other RFCs. >
You mentioned the object initializer RFC, so I assumed you asked because of it. Everything applies generally though. Also I reread my answer to 1 and it may have come a across a bit harsher than I wanted. I just meant to say that it takes some time to get internals development as a newcomer, for everyone to accustom to you. Remember PHP development often happens in circles of years, rather than months and years.
> > -Mike > > > > On Sep 16, 2019 at 2:00 AM, kontakt@beberlei.de>> > wrote: > > 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 > >