This RFC proposes that the PHP project should adopt a formal code of conduct for its members.
The goal of this code of conduct is to give a clear signal what is expected of contributors and project maintainers, regarding their conduct in discussions on mailing lists, and other related communication channels. More specifically, the expected conduct in discussing language improvements and changes through the RFC process.
This proposal consists of several parts:
This RFC proposes for the PHP project to adopt version 1.3.0 of the Contributor Covenant as a Code of Conduct.
Contributor Code of Conduct
As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.
We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, or nationality.
Examples of unacceptable behaviour by participants include:
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviours that they deem inappropriate, threatening, offensive, or harmful.
By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect of managing this project. Project maintainers who do not follow or enforce the Code of Conduct may be permanently removed from the project team.
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community.
Instances of abusive, harassing, or otherwise unacceptable behaviour may be reported by contacting a project maintainer at firstname.lastname@example.org. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. Maintainers are obligated to maintain confidentiality with regard to the reporter of an incident.
A page will be created on php.net at php.net/codeofconduct that will display the actual language of the code of conduct used above: Code Of Conduct
This section presents a loose collection of guidelines that focus on encouraging constructive feedback on language proposals (RFCs). RFCs are used to introduce new features into the language. Currently, too little time is focussed on improving RFCs; instead a lot of effort exists to torpedo RFCs, attack suggestions and opinions. The point of the RFC process to to improve PHP — and the RFCs themselves.
Below are several suggestions:
A page will be created on php.net at php.net/collaboration-guidelines that will display the collaboration guidelines as described above.
A new mailing list will be created at email@example.com for use in reporting incidents and discussing them internally. This mailing list will be private.
In the event that an incident is reported the following process should be followed:
If all reasonable efforts to reach a mediated agreement fail and other action is deemed absolutely necessary as a last resort:
At all steps the reporter(s) should be kept up to date on the process and recommendations that are made.
All incidents are to be kept in the strictest form of confidentiality. The Community Mediation Team shall be the only group to know about the reporter and the precise details of any incident. Any communication outside of the team (including fact-finding, investigation, documentation, etc.) shall not include identifying information as to the reporter unless agreed by the reporter or is otherwise public.
Additionally, reasonable attempts shall be made as to the confidentiality to the accused person. This includes transparency reports where no significant action is taken (due to lack of evidence or that the Community Mediation Team determines it wasn't significant enough to warrant punitive action).
To determine if the incident is a violation or not, the Conflict Resolution Team shall use the Reasonable Person Test.
The following four points shall be taken into account for any incident:
Additionally, it shall be assumed that both parties (the accuser and the accused) are acting as reasonable people until proven otherwise. This means that best intentions shall be assumed unless significant evidence to the contrary is found.
Note: reporting an incident does not absolve a person of the requirement to abide by the CoC. This means that the victim of harassment is not entitled to “harass back”.
A team of 5 volunteers shall be assembled who will make up the Community Mediation Team.
The team shall consist of:
As long as the preceding three seats are filled, there is no karma requirement (wiki or otherwise) for the remaining three seats.
All team members will be elected by RFC vote (requiring 2/3 majority).
There is no specified term limit, but if either the PHP project or the other members of the Community Mediation Team feel that a specific member is not doing their job, they can be removed by an RFC vote (requiring 50% + 1 to support removal).
Any punitive action taken by the Conflict Resolution Team shall be reported to firstname.lastname@example.org, including a summary of the incident and the action taken. The summary of the incident should include supporting evidence and justification for the decision.
Reasonable efforts should be taken to ensure the privacy of the reporting party. The only two exceptions would be if the incident was public or if the reporting party agrees to be identified.
Additionally, once per quarter (every 3 months), the Community Mediation Team shall produce an aggregated report as to the number of times incidents were reported, and the outcomes of the incidents, even if no punitive measures were taken.
The intention that nothing in this section is ever going to be needed. In extreme cases, when the Community Mediation Team finds that a certain project member continues to violate either the Code of Conduct or Constructive Contributing Guidelines, more punitive action might be required.
The Community Mediation Team should make every reasonable attempt to defuse the situation without having to resort to punitive action. This includes establishing a meaningful discussion around the incident, giving the accused offender the chance to apologize (privately or publicly, depending on the incident) or determining that no action is necessary even if the CoC was violated.
In the event that additional action is required, it may include:
If the Community Mediation Team (with 4/5th majority as described above) determines that punitive action is required, an RFC to the general project is created. Once the RFC is issued, the temporary ban's lifetime will be tied to the RFC's lifetime (will expire when the vote is finished). All corrective action RFCs will require 2/3 majority to affect the ban. However, this temporary ban shall not include the email@example.com mailing list, provided that the accused party remains civil and reasonably within the CoC to ensure that they receive a fair representation during the ban discussion.
Punitive action may include removal of commit karma, mailing list write access as well as disabling of the associated PHP.net account. Depending on the particular infraction, one, many or all access may be suspended.
A new address/account which is believed to be used by an already banned individual does not require a RFC to effect provided there is reasonable evidence to support the correlation.
Bans (temporary or permanent) should only be used in egregious cases where a pattern of disregard for the CoC is demonstrated.
Either party may appeal an action by raising the concern to firstname.lastname@example.org. PHP project members may then vote to overturn or strengthen the action as necessary (votes require 50%+1 to overturn, and 2/3 majority to strengthen the action).
It is worth noting that this may be used as a technique to attempt to disclose the reporter to make them the subject of public scrutiny. Therefore reasonable attempts at confidentiality should be maintained, and the teams (Community Mediation Team and PHP project members) should keep this in mind.
In the event that a CoC violation is reported against a Conflict Resolution Team member, the remaining members shall investigate and raise the concern to email@example.com, even if they determine no action is to be taken.
The PHP project voting body has the right to overturn any action taken the Conflict Resolution Team by vote (50% + 1 required to overturn).
Any changes to the text of the Code of Conduct, or updating the version of it shall require an RFC with 2/3 majority voting. Any changes to the text of the Contributor Guidelines shall require an RFC with 2/3 majority voting.
Activities on a php.net property shall always be considered “representing the project” and hence fall under the jurisdiction of the CoC and Community Mediation Team. This includes any php.net mailing list.
While at a technology conference, the CoC is only considered to apply if and only if the person is demonstrably representing the project.
For example, merely speaking at a conference about PHP is not enough to be “representing the project”. However, when speaking about the project itself (meaning internals functions, etc), while the talk is occurring the CoC shall apply.
This does not intend to limit the CoC applicability to only during a talk, however any violation that happens at a conference shall be assumed to not be representing the project unless there is significant and obvious evidence to the contrary.
On social networks, the CoC is only considered to apply if the context of the conversation makes it clear that the person represents the PHP project.
For example, merely having “PHP contributor” in an about or bio is not enough to be “representing the project”. However, a conversation about the PHP project itself (including RFCs, etc) is enough to justify “representation”.
In all cases, if an issue seems reasonably connected to a project matter, the CoC may apply depending on how strongly the connection is.
For example, if one person is involved in a heated discussion on internals@, and then immediately after starts harassing another participant on another channel with similar tone, the harassment may be considered a violation.
In no case should a casual connection be considered a violation (just because two people are both members of the project is not enough to form a connection).
This RFC will include a vote for the initial Community Mediation Team. A separate thread will be opened asking for volunteers.
This RFC requires 2/3 majority to pass, as it has a significant impact on the community and project operations.