Hi Internals,
A little while ago Zeev suggested that it was time to update the RFC process to make it more fit for purpose. As part of that conversation I would like to suggest some 'etiquette' around RFC discussions.
PHP internals has a reputation for being 'toxic'. While I don't think it's as bad as some people try to suggest it is, we could make RFC discussions be more productive and less emotionally draining by people being more careful how they interact with each other on this list.
I've written some suggestions on how people could have more productive conversations, which I'm going to maintain here (https://github.com/Danack/RfcCodex/blob/master/rfc_etiquette.md), and have attached to the end of this email.
These would be mostly suggestions of how to have productive conversations rather than hard rules, as most of them involve gray areas, which couldn't and shouldn't be enforced with hard rules.
I'm sending this list now, but the full conversation might be better to have as a part of a full review of the RFC process. However there are a few that I think we should discuss sooner rather than later.
# Better process for handling suggestions that are never likely to pass
Recently, someone suggested adding capability for PHP to print strings that automatically have a new line at the end of the string. Putting it mildly, that conversation didn't go well, and by the end of it people were swearing at each other on the list.
PHP internals could do with a better process for giving negative feedback an idea without someone having to go through the whole RFC process.
I don't have a good suggestion for how to do this. Does anyone else?
# People other than the author announcing RFCs on internals
Through possibly a series of errors, someone who was not the author started a thread on internals for an RFC right after it had been created, while it was still in draft status.
The site wiki.php.net/rfc is a tool that is meant to allow people to draft RFCs and share the idea with other people who want to work on the RFC before it is a polished idea, and before it is ready to be presented to the world.
Having someone other than the RFC author announce the RFC on internals before the author thinks the RFC is ready for comment, is "not okay". If you discuss an RFC on internals before the author thinks the RFC is ready to be discussed, the only thing that could achieve is to make the conversation less productive.
If you want to influence how the RFC is drafted, it can appropriate to reach out to the RFC author, and offer to help them.
# Contacting RFC authors should go through PHP internals list
Drafting RFCs and pushing them through internals is an exhausting process. Several PHP contributors have suddenly stopped contributing to the project after successfully getting an RFC passed, due to them being entirely fed up.
One of the things that is tiresome is people contacting the RFC author through communication channels (other than the PHP internals list), particularly when what they are going to say is either negative or even just based on not understanding part of the RFC.
There is a difference between giving positive feedback and negative feedback. And there is a difference between giving feedback to someone you have communicated with many times before, and contacting someone for the first time.
It's hard to draw an exact line of where communication is fine to go off-list, and where it should stay on list. But here are some examples:
"You are awesome for writing such an amazing RFC" - fine to send off-list.
"I found some typos in the RFC" - probably fine to send off-list, particularly if you communicate with the RFC author already.
"Please can you answer this question about the RFC" - possibly fine to send off-list, but only if you know the RFC author already.
"The RFC is a terrible idea for these reasons" - should only be sent via the list.
As I said, I'm posting this now to start the conversation, but any formal approval
cheers
Dan
*insert full rfc etiqutte text here*
Danack
commented
1 year ago
https://gist.github.com/Danack/4fcdece65e551acb2467caaf939d629e