The RFC discussion process?

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