On Mon, Sep 16, 2019 at 9:39 AM Mike Schinkel <m...@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, <Benjamin Eberlei <kont...@beberlei.de>> > wrote: > > Hello Mike, > > On Mon, Sep 16, 2019 at 3:50 AM Mike Schinkel <mikeschin...@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 > >
