PHP: rfc:prevent_disruptions_of_conversations

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== PHP RFC: Prevent disruptions of conversations ======
  * Version: 1.0
  * Date: 2019-09-19 
  * Author: Dan Ackroyd, danack@php.net
  * Status: Under Discussion
  * First Published at: https://wiki.php.net/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:

  * Sending many more emails than other contributors.
  * Repeatedly telling other contributors that they are not allowed to discuss otherwise on-topic issues.
  * Repeatedly asking people to hold off on proposing an RFC.

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:

  * tell the person who contacted them that although the persons behaviour might not be good, it doesn't meet a level of disruption required to take action.
  * contact the person who's behaviour might be seen as disruptive, clearly describe how some behaviour is perceived as a problem by other people, and try to suggest how they could communicate in a way that still gets the persons message across but doesn't disrupt other people's conversations, as well as asking the person to try to moderate their behaviour. 
  * step down as a list moderator, if they feel they are unable to do one of the other two actions.

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:

  * focus on helping people understand how they are communicating could be disrupting conversations and/or making it hard for other people to have their voices heard. They shouldn't focus on suspending people.

  * avoid trying to address disruptions for discussions they are taking part in. It's really hard for someone to objectively think about someone's behaviour when you're also taking part in a discussion with them. 

  * avoid acting rashly or unilaterally. Where possible the 'disruption points of contact' should talk through the situation and how best to handle it with at least one other 'disruption point of contact', before addressing it.


===== 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:

  * People who have previously contributed to PHP (i.e. have committed code) should be able to apply to have their suspension lifted after 6 months.
  * People who have not previously contributed to PHP (i.e. have not committed code) should be able to apply to have their suspension lifted after 12 months.

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'.
Page Tools
