Django Code of Conduct - Enforcement Manual
This is the enforcement manual followed by Django's Code of
Conduct Working Group. It's used when we respond to an issue to make sure we're
consistent and fair. It should be considered an internal document, but we're
publishing it publicly in the interests of transparency.
The Conduct Working Group
The Conduct Working Group
All responses to reports of conduct violations will be managed by a Code of Conduct Working Group ("the working group").
The Django Software Foundation's Board of Directors ("the board") will establish this working group, compromised of at least three members. One member will be designated chair of the group and will be responsible for all reports back to the board. The board will review membership on a regular basis.
How the working group will respond to reports
When a report is sent to the working group they will immediately reply to the report to confirm receipt. This reply must be sent within 24 hours, and the group should strive to respond much quicker than that.
See the reporting guidelines for details of what reports should contain. If a report doesn't contain enough information, the working group will obtain all relevant data before acting. The working group is empowered to act on the DSF's behalf in contacting any individuals involved to get a more complete account of events.
The working group will then review the incident and determine, to the best of their ability:
- what happened
- whether this event constitutes a code of conduct violation
- who, if anyone, was the bad actor
- whether this is an ongoing situation, and there is a threat to anyone's physical safety
This information will be collected in writing, and whenever possible the group's deliberations will be recorded and retained (i.e. IRC transcripts, email discussions, recorded voice conversations, etc).
The working group should aim to have a resolution agreed upon within one week. In the event that a resolution can't be determined in that time, the group will respond to the reporter(s) with an update and projected timeline for resolution.
If the act is ongoing (such as someone engaging in harrassment in #django), or involves a threat to anyone's safety (e.g. threats of violence), any working group member may act immediately (before reaching consensus) to end the situation. In ongoing situations, any member may at their discretion employ any of the tools available to the working group, including bans and blocks.
If the incident involves physical danger, any member of the working group may -- and should -- act unilaterally to protect safety. This can include contacting law enforcement (or other local personnel) and speaking on behalf of the DSF.
In situations where an individual group member acts unilaterally, they must report their actions to the working group for review within 24 hours.
The working group must agree on a resolution by consensus. If the group cannot reach consensus and deadlocks for over a week, the group will turn the matter over to the board for resolution.
Possible responses may include:
- Taking no further action (if we determine no violation occurred).
- A private reprimand from the working group to the individual(s) involved. In this case, the group chair will deliver that reprimand to the individual(s) over email, cc'ing the group.
- A public reprimand. In this case, the group chair will deliver that reprimand in the same venue that the violation occurred (i.e. in IRC for an IRC violation; email for an email violation, etc.). The group may choose to publish this message elsewhere for posterity.
- An imposed vacation (i.e. asking someone to "take a week off" from a mailing list or IRC). The group chair will communicate this "vacation" to the individual(s). They'll be asked to take this vacation voluntarily, but if they don't agree then a temporary ban may be imposed to enforce this vacation.
- A permanent or temporary ban from some or all Django spaces (mailing lists, IRC, etc.). The group will maintain records of all such bans so that they may be reviewed in the future, extended to new Django fora, or otherwise maintained.
- A request for a public or private apology. The chair will deliver this request. The group may, if it chooses, attach "strings" to this request: for example, the group may ask a violator to apologize in order to retain his or her membership on a mailing list.
Once a resolution is agreed upon, but before it is enacted, the working group will contact the original reporter and any other affected parties and explain the proposed resolution. The working group will ask if this resolution is acceptable, and must note feedback for the record. However, the working group is not required to act on this feedback.
Finally the working group will make a report for the DSF board (as well as the Django core team in the event of an ongoing resolution, such as a ban).
The working group will never publicly discuss the issue; all public statements will be made by the DSF board.
Conflicts of Interest
In the event of any conflict of interest a working group member must immediately notify the other members, and recuse themselves if necessary.
Editor's note: Writing this document posed a unique challenge. Most similar guides are written on the assumption of an in-person event. However, the Django community doesn't exist in one place, and most of the time we're spread out across the world and interact online. This makes trying to define and enforce community standards a different type of challenge. This document is adapted from the Ada Initiative template and the PyCon 2013 Procedure for Handling Harassment Incidents, but changed to reflect the nature of our community. It is our expectation that this will be a living document and change as we grow to understand how to meet this challenge and best serve our community and ideals.