Table of Contents

PHP RFC: Prevent disruptions of conversations

Introduction

The internals email mailing list is the main tool that is used to coordinate work on the PHP project.

It is a vital tool that we need to be useful for us to be able to maintain PHP.

Although in the past there have been periods of contentious conversations, we have not previously needed to have rules in place to take action when conversations become non-productive. I believe we need to place some enforceable rules in place now, that define some disruptive behaviours that are not allowed on the mailing list.

To be clear this RFC covers only effects of behaviour, not motivations.

An example; imagine someone wanted to help PHP development but they didn't know C, and so were sending many emails asking for help on understanding how to do stuff. That person would obviously be attempting to help the PHP project, but the result of many 'beginner' questions on the list would be disruptive to other people. The person sending those messages only has good intentions, but the effect can still be negative.

This RFC does not propose a comprehensive Code of Conduct, which will take a significant amount of effort to draft carefully. This is a stop-gap measure to allow us to use the internals mailing list effectively.

Non-productive behaviours

Disrupting other peoples conversations.

Although everyone is free to have an opinion, they are not allowed to use their voice to try to prevent other people's conversation. This explicitly includes the following behaviours:

However other behaviours that people find disruptive, that someone refused to stop doing when asked to using the process listed below, would also be covered by this RFC.

Rejecting the results of RFC votes.

The RFC process is currently the way that the PHP internals team make decisions.

Although it would probably be a good idea to have a discussion about the project governance, for the time being the RFC process is what we have.

It is very disruptive to have people say that they reject the result of an RFC vote as being 'invalid'. This leads to disruption both in conversations here, and confusion in the wider PHP community.

To be clear, it is fine for people to say that certain RFCs need to be revisited very soon after an RFC vote has been taken. For example when problems are found with an implementation of an RFC, or hidden effects that weren't considered as part of the RFC are discovered. Those conversations should follow our normal RFC process.

Being abusive to other internals members in private channels.

If someone in internals is having a strong disagreement with other people, that conversation should remain on the internals newsgroup list. It is intolerable for anyone to send abusive messages off list.

This explicitly wouldn't apply to 'positive' conversations. e.g. if someone asks for help, and you want to contact them in private to offer them help, that would be fine. It's only when a conversation is adversarial that the conversation should remain on list.

Process for handling disruptive behaviour

Step 1

If someone who finds someone else's behaviour disruptive either they or someone more 'senior' in the project should gently ask them to not behave like that. That message should be sent on list.

This is not going to be possible in all circumstances, for example it's not appropriate when someone has been sending abusive messages through a private channel, in which case the process should skip to step 2.

Step 2

We will have a list of people who have been involved in the project long enough to be 'trusted' to be 'disruption points of contact'. These people are not required to actively moderate the internals mailing list, they are there to be contacted when someone thinks that someone else's behaviour is being disruptive.

When someone contacts them with a report of what they think is disruptive behaviour, the 'disruption points of contact' person should do one of the following things:

This RFC proposes that the initial 'disruption points of contact' will be the Release Managers since PHP 5.6 and also the author of this RFC (Dan Ackroyd) and Peter Cowburn (aka Salathe). Any of those people may opt out of being in that list. Anyone may step down from this position of responsibility at any time for any reason, even if that may result in no-one being left as a 'disruption point of contact'.

To be clear, the people who are 'disruption points of contact' will not have any power delegated to them that is not available to other people in the PHP project. They are just there to have a point of contact.

Step 3

If the person who other people are find being disruptive refuses to moderate their behaviour, even after being asked to in the previous steps, then a vote will be held to suspend them from PHP internals.

This suspension will include blocking them from emailing the mailing list, taking part in the conversation on Github, and revoking their git access, and any other places where PHP core development takes place, that is under the control of the PHP project.

As this vote should only take place when there has already been extreme disruption to PHP internals, then the length of the voting period will be 72 hours.

Guidance for 'disruption points of contact'

People who are 'disruption points of contact' should:

Time scope

This RFC would not cover messages in the past, it would only apply to disruptive messages sent from the date this RFC would be passed.

Future Scope

This section details areas where the feature might be improved in future, but that are not currently proposed in this RFC.

Proposed Voting Choices

Accept this RFC as the process used to prevent disruption on the PHP internals discussions. Yes or no.

Future scope

This solution is not ideal.

It is going to be hugely contentious and also a massive distraction from the things we should be discussing on this list. I hope that at some stage we can replace this RFC with a better solution. But this is a stop gap measure we urgently need.

As part of a separate full Code of Conduct RFC we should allow people to apply to have their suspension lifted after an appropriate amount of time. I think that something like the following would be appropriate:

But that lifting of the suspension is explicitly not part of this RFC.

Also not part of this RFC is a way to get new 'disruption points of contact'.