Skip to content

Python Software Foundation Code of Conduct Working Group Enforcement Procedures

This document summarizes the procedures the Python Software Foundation Code of Conduct work group uses to enforce the Code of Conduct.

Summary of processes

When the work group receives a report of a possible Code of Conduct violation, it will:

  1. Acknowledge the receipt of the report.
  2. Evaluate conflicts of interest.
  3. Call a meeting of work group members without a conflict of interest.
  4. Evaluate the reported incident.
  5. Propose a behavioral modification plan.
  6. Propose consequences for the reported behavior.
  7. Vote on behavioral modification plan and consequences for the reported person.
  8. Contact online community administrators/moderators to approve the behavioral modification plan and consequences.
  9. Follow up with the reported person.
  10. Decide further responses.
  11. Follow up with the reporter.

Acknowledge the report

Reporters should receive an emailed acknowledgment of the receipt of their report within 24 hours.

Conflict of interest policy

Examples of conflicts of interest include:

  • The reporter or reported person is your manager
  • You have a romantic or platonic relationship with either the reporter or the reported person. It's fine to participate if they are an acquaintance.
  • The reporter or reported person is your metamour. (This is a term used in the poly community; the short definition is here, and a longer description is here).
  • The reporter or reported person is your family member
  • The reporter or reported person is your direct client
  • The reporter or reported person is someone you work closely with. This could be someone on your team or someone who works on the same project as you.
  • The reporter or reported person is a maintainer who regularly reviews your contributions

Committee members do not need to state why they have a conflict of interest, only that one exists. Other work group members should not ask why the person has a conflict of interest.

Anyone who has a conflict of interest will remove themselves from the discussion of the incident, and recluse themselves from voting on a response to the report.

Evaluating a report

Jurisdiction

  • Is this a Code of Conduct violation? Is this behavior on our list of inappropriate behavior? Is it borderline inappropriate behavior? Does it violate our community norms?
  • Did this occur in a space that is within our Code of Conduct's scope? If the incident occurred outside the community, but a community member's mental health or physical safety may be negatively impacted if no action is taken, the incident may be in scope. Private conversations in community spaces are also in scope.

Impact

  • Did this incident occur in a private conversation or in a public space? Incidents that all community members can see will have more negative impact.
  • Does this behavior negatively impact a marginalized group in our community? Is the reporter a person from a marginalized group in our community? How is the reporter being negatively impacted by the reported person's behavior? Are members of the marginalized group likely to disengage with the community if no action was taken on this report?
  • Does this incident involve a community leader? Community members often look up to community leaders to set the standard of acceptable behavior.

Risk

  • Does this incident include sexual harassment?
  • Does this pose a safety risk? Does the behavior put a person's physical safety at risk? Will this incident severely negatively impact someone's mental health?
  • Is there a risk of this behavior being repeated? Does the reported person understand why their behavior was inappropriate? Is there an established pattern of behavior from past reports?

Reports which involve higher risk or higher impact may face more severe consequences than reports which involve lower risk or lower impact.

Propose a behavioral modification plan

The work group will determine a concrete behavioral modification plan that ensures the inappropriate behavior is not repeated. The work group will also discuss what actions may need to be taken if the reported person does not agree to the behavioral modification plan.

What follows are examples of possible behavioral modification plans for incidents that occur in online spaces under the scope of this Code of Conduct. This behavioral modification list is not inclusive, and the Python Software Foundation Code of Conduct work group reserves the right to take any action it deems necessary.

  • Requiring that the reported person not use specific language
  • Requiring that the reported person not join in on specific types of discussions
  • Requiring that the reported person not send private messages to a community member
  • Requiring that the reported person not join specific communication channels
  • Removing the reported person from administrator or moderator rights to community infrastructure
  • Removing a volunteer from their duties and responsibilities
  • Removing a person from leadership of relevant organizations
  • Removing a person from membership of relevant organizations

Propose consequences

What follows are examples of possible consequences to an incident report. This consequences list is not inclusive, and the Python Software Foundation Code of Conduct work group reserves the right to take any action it deems necessary.

Possible private responses to an incident include:

  • Nothing, if the behavior was determined to not be a Code of Conduct violation
  • A verbal or emailed warning
  • A final warning
  • Temporarily removing the reported person from the online community
  • Permanently removing the reported person from the online community
  • Publishing an account of the incident

Work group vote

Some work group members may have a conflict of interest and may be excluded from discussions of a particular incident report. Excluding those members, decisions on the behavioral modification plans and consequences will be determined by a two-thirds majority vote of the Python Software Foundation Code of Conduct work group.

Administrators/moderators approval

Once the work group has approved the behavioral modification plans and consequences, they will communicate the recommended response to the administrators/moderators of the online community. The work group should not state who reported this incident. They should attempt to anonymize any identifying information from the report.

Administrators/moderators are required to respond back with whether they accept the recommended response to the report. If they disagree with the recommended response, they should provide a detailed response or additional context as to why they disagree. Administrators/moderators are encouraged to respond within a week.

In cases where the administrators/moderators disagree on the suggested resolution for a report, the Python Software Foundation Code of Conduct work group may choose to notify the Python Software Foundation board.

Follow up with the reported person

The Python Software Foundation Code of Conduct work group will work with online community administrators/moderators to draft a response to the reported person. The email should contain:

  • A description of the person's behavior in neutral language
  • The negative impact of that behavior
  • A concrete behavioral modification plan
  • Any consequences of their behavior

The work group should not state who reported this incident. They should attempt to anonymize any identifying information from the report. The reported person should be discouraged from contacting the reporter to discuss the report. If they wish to apologize to the reporter, the work group can accept the apology on behalf of the reporter.

Decide further responses

If the reported person provides additional context, the Python Software Foundation Code of Conduct work group may need to re-evaluate the behavioral modification plan and consequences.

Follow up with the reporter

A person who makes a report should receive a follow-up email stating what action was taken in response to the report. If the work group decided no response was needed, they should provide an email explaining why it was not a Code of Conduct violation. Reports that are not made in good faith (such as "reverse sexism" or "reverse racism") may receive no response.

The follow-up email should be sent no later than one week after the receipt of the report. If deliberation or follow-up with the reported person takes longer than one week, the work group should send a status email to the reporter.

Documentation and Privacy Policies

Depending on how the Code of Conduct committee is set up, there may be different places where information about the Code of Conduct reports may be accessible:

  • Personal email of Code of Conduct committee members
  • Archives of committee mailing lists
  • Logs from committee online chats
  • Shared online documents, such as Google Docs or Next Cloud documents

In all cases, documents and notes should only be available to committee members who do not have a conflict of interest for the report. This requires communities to choose documentation tools that will meet their privacy needs.

Committee shared email address

Code of Conduct committees need to be able to be reached by one email address. It is recommended that the committee use an alias that forwards email to individual members.

Using a mailing list is not recommended. This is because mailing lists typically archive all emails. This means new committee members gain access to all past archives. They can deliberately or accidentally see past reports where they have a conflict of interest. In order to prevent potential conflicts of interest, it is recommended to not have a mailing list archive.

Committee online discussion

A Code of Conduct committee may have an online, real-time discussion forum, such as Slack, Zulip, or IRC. If the online chat platform allows, it is recommended to set the committee channel to have past history not be available to new committee members who join the channel.

When a report comes in and a discussion needs to happen in an online space, care needs to be taken to avoid conflicts of interest. In the committee chat channel, state 'We have a report that involves [REPORTED PERSON]'. Do not say who was the reporter or who were witnesses if the report was sent to an individual committee member. Ask which committee members do not have a conflict of interest. Add those committee members to a group discussion, separate from the committee channel. If a committee member does not respond, do not add them to the new group discussion. If a committee member finds they have a conflict of interest because of who reported the incident or who witnessed it, they should recluse themselves from the discussion.

Committee members should not use bots or IRC bouncers to log the group discussions. All documentation of discussions and decisions should be put in online, shared documentation.

If no online real-time discussion forum is used, committee members without a conflict of interest will discuss the case on a separate email thread. If no committee member has a conflict of interest, and the committee email is an alias, the committee may reply to the alias to discuss the issues.

Shared Documentation

The Code of Conduct committee should keep two types of shared documents:

  • A spreadsheet with the status of open and closed cases
  • A separate document for each report

Status Spreadsheet

The spreadsheet with status of open and closed cases should have the following format:

Safety risk? Risk of repeating? Status Code Name Date & Time Actions needed Resolution
Yes Yes Ongoing home shelf 07/07 8:30am and 07/08 12:30pm Team on the lookout for reported person Temporary ban for the remainder of the event, reevaluate attendance for next year
No Maybe Resolved stunned bulb 07/07 8:00pm - Verbal warning

Keep resolutions and notes vague enough that enforcement team members with a conflict of interest don't know the details of the incident. Use gender-neutral language when describing the reported person in the spreadsheet.

Report Documentation

Each report should be assigned a code name, using an online random phrase generator. The code name should be used in the document's title. Only committee members without a conflict of interest should have access to the report documentation.

Report documents should include:

  • A summary of a verbal report, or the text of an emailed report. Use neutral, non-judgmental words to describe the behavior. Where possible, separate out the behavior of the reported person and the impact on the reporter.
  • A summary of committee discussions, including whether the report is in scope
  • Proposed behavioral modification plan
  • Proposed consequences for the reported behavior
  • A summary of verbal discussions, or the text of email discussions with community moderators, administrators, registration, or other event organizers about the proposed consequences and behavioral modification plan
  • A summary of verbal discussions, or the text of email discussions with the reported person
  • The text that was sent to follow up with the reporter

All discussion summaries should include dates that they took place.

Ongoing Documentation of Event and Community Bans

The Board Secretary and/or other persons or roles designated by a resolution of the Board ("maintainers") shall maintain a list of people who have been banned from Python Software Foundation-organized events including:

  • The effective date of their ban
  • The duration of their bans, or whether the ban is permanent.

This list shall only be viewable by the maintainers.

Privacy Concerns

There are some common privacy pitfalls to online tools like Google Docs. Make sure to always share the document with committee members who don't have a conflict of interest, rather than turning link sharing on. This prevents people outside of the committee from accessing the documents.

Another common issue is that when a folder is shared with the whole committee, even if a person doesn't have edit or view access to an individual report, they can still see the document's title. This can give information away, such as the person who made the report. Some communities use initials in the report title instead. That can still reveal information, and it makes it hard to talk about report status in public spaces (such as an event). The committee may want to assign a code name to each report, and reference that name in the report title and status spreadsheet. You can use an online random phrase generator to create the code name.

When on-boarding new committee members, they should be provided with a list of names of people who have been reported in a Code of Conduct incident. The new committee member should state whether they have any conflicts of interest with reviewing documentation for those cases. If not, they will be given edit access to the report documents.

Changes to Code of Conduct

When discussing a change to the Python community Code of Conduct or enforcement policies, the Python Software Foundation Code of Conduct work group will follow this decision-making process:

  • Brainstorm options. Work group members should discuss any relevant context and brainstorm a set of possible options. It is important to provide constructive feedback without getting side-tracked from the main question. Brainstorming should be limited to 3-7 days maximum.
  • Vote. Proposed changes to the Code of Conduct will be decided by a two-thirds majority of all voting members of the Code of Conduct work group. Work group members are listed in the work group charter. Currently active voting members are listed below.
  • Board Vote. Once a working draft is in place for the Code of Conduct and procedures, the Code of Conduct work group shall provide the PSF board with a draft of the changes. The PSF board will vote on the changes at a board meeting.

Current list of voting members

Tania Allard Brett Cannon Rami Chowdhury Jessica Greene Cheuk Ting Ho Tereza Iofciu Łukasz Langa Deb Nicholson Mojdeh Rastgoo Jeff Triplett Drew Winstel

Advisers

Advisers to the PSF Code of Conduct work group have access to the work group mailing list, but are not voting members.

Anwesha Das Maricela Sanchez Miranda Naomi Ceder Thomas Wouters

Attribution