This is the internal manual for Django's Code of Conduct Working Group. It documents our procedures, processes, and guidelines for handling Code of Conduct reports and enforcing the Code of Conduct consistently and fairly.
While this is an internal working document, we publish it publicly in the interests of transparency and to help other communities develop their own enforcement processes.
NOTE: Within the scope of this document, any reference to the “working group” shall mean the "Code of Conduct Working Group", unless explicitly specified otherwise.
- The Code of Conduct Working Group
- Coordination with Online Community Working Group
- Scope
- Report Handling Procedures
- Evaluating Reports
- Communications Guidelines
- Resolutions and Enforcement
- Record Keeping
- Confidentiality
- Conflicts of Interest
- Acting Unilaterally
- Transparency
All responses to reports of conduct violations will be managed by the Code of Conduct Working Group.
The Django Software Foundation's Board of Directors ("the board") will establish this working group, comprised of at least three members. One member will be designated chair of the working group and will be responsible for all reports back to the board. The board will review membership on a regular basis.
For information about current and past members of the Code of Conduct Working Group, see membership.md.
The Online Community Working Group handles day-to-day moderation of Django's online spaces and has flexibility to address minor infractions within those spaces using their own moderation processes.
The Code of Conduct Working Group becomes involved when:
- A formal report is submitted directly to the Code of Conduct Working Group
- A violation occurs across multiple Django spaces, which include but are not limited to: Django organization on GitHub, Django Discord, DSF Slack, Django Forum.
- The Online Community Working Group escalates an issue that requires formal Code of Conduct enforcement
- An issue at a Django event or sponsored event is escalated to the working group
Each working group designates a liaison from its own members to facilitate coordination and communication between the groups.
In situations where the Code of Conduct Working Group and the Online Community Working Group cannot reach consensus in a timely manner on an issue that requires coordination between both groups, one or both working group chairs will escalate the matter to the Django Software Foundation's Board of Directors for resolution.
This Code of Conduct applies to all spaces managed by the Django project or Django Software Foundation. The Code of Conduct also applies when an individual is officially representing the Django community in public spaces.
This Code of Conduct applies to the following people at events hosted or sponsored by the Django Software Foundation:
- DSF staff and board members
- Speakers and panelists
- Tutorial or workshop leaders
- Sprint leaders and mentors
- Organizers and volunteers
- Sponsors and exhibitors
- All attendees
The Code of Conduct applies in official event spaces, including:
-
Conference and presentation rooms
-
Tutorial and workshop spaces
-
Sprint and hackathon areas
-
Sponsor and exhibitor halls
-
Social events and meal areas
-
Hallways, walkways, and common areas that connect event spaces Any physical spaces within the venue premises where attendees, speakers, sponsors, or staff may interact The Code of Conduct also applies to interactions with official event accounts and spaces on social media and digital platforms, including:
-
Comments on official event hashtags
-
Posts on event social media accounts
-
Event video hosting platforms and live streams
-
Official event communication channels (Slack, Discord, etc.)
Django-sponsored events (such as DjangoCon conferences) are required to have their own Code of Conduct and Code of Conduct team, and must designate at least one named Code of Conduct point of contact as outlined in events.md. Event organizers will enforce the code throughout the event. Issues at sponsored events can be escalated to the Django Code of Conduct Working Group by:
- The event's Code of Conduct team
- The reporter: The person/group who submits the complaint
- The reported party: The person/group who is alleged to have violated the Code of Conduct
The Code of Conduct Working Group will coordinate with event organizers to determine appropriate responses that respect both the event's autonomy and Django's community standards. For detailed guidance on supporting event organizers, see events.md.
This Code of Conduct applies to the following online spaces managed by the Django project or Django Software Foundation:
- The Django Forum
- Django Discord server
- Mailing lists hosted on djangoproject.com
- GitHub repositories, issue trackers, and pull requests under Django organizations
- Official Django social media accounts
- Any other online space administered by the Django project or Django Software Foundation
- Any other space where their Code of Conduct specifically states that the Django Code of Conduct applies (e.g., Djangonaut Space)
This Code of Conduct applies to the following people in Django online spaces:
- DSF board members and staff
- Django core developers and contributors
- Space administrators and moderators
- All community members and participants
Each online space is encouraged to provide:
- A welcome message with a link to the Code of Conduct
- Clear contact information for reporting violations (conduct@djangoproject.com)
- Identification of space moderators or administrators
Django-related projects and spaces may ask to designate the Django Code of Conduct Working Group as an escalation point in their own Code of Conduct process. To become an affiliated program, projects must adopt their own complementary Code of Conduct, designate a named Code of Conduct point of contact and provide their individual email address to the working group to keep on file, request inclusion via conduct@djangoproject.com, outline escalation procedures in their reporting process, and publish regular transparency reports.
For complete requirements, escalation criteria, and transparency reporting guidelines, see affiliated-programs.md.
The Code of Conduct applies when an individual is officially representing the Django community in public spaces. Examples of official representation include:
- Using an official Django email address <@djangoproject.com>
- Posting via an official Django social media account
- Acting as an appointed representative at an online or offline event
- Speaking or presenting as a Django representative
In general, almost all reports we receive can be categorized into two groups:
- Reported by local representatives - Issues that were usually already handled by organizers or curators of communities like Django conferences, meetups, or online spaces. In those situations, we either acknowledge the report if it was already resolved and keep it in our central log, or provide support and advice, or enforce Code of Conduct if needed.
- Reported by people who need our help - Those reports usually require our decision and enforcement of the Code of Conduct.
All reports received by us are usually sent to conduct@djangoproject.com, which is automatically forwarded to each member of the working group.
We aim to provide the initial response and acknowledgement of the received report ideally within a day. When a report is sent to the working group, they will immediately reply to the report to confirm receipt. The working group strives to respond promptly, recognizing that as volunteers, coordination may take time. The working group will keep the reporter informed of progress and any delays.
If the response requires a decision, we should send an acknowledgement of the report to make sure the reporter is informed we're working on it, and not ignoring it:
Hi X,
Thank you so much for reporting this issue to the Django Code of Conduct Working Group. I appreciate you taking the time to get in touch - reports like this help us to make Django a better community.
We'll discuss and get back to you with the outcome, and will keep this report on file. Meanwhile, if there is anything else we can do to help or support you, please do let us know.
Regards,
[First Last name]
DSF Code of Conduct Working Group
If the received report clearly states that the action has been taken already, and the issue is only reported to be kept on file in our central log, the working group can close the issue by sending a simple acknowledgement:
Hi [X],
Thank you so much for reporting this issue to the Django Code of Conduct Working Group. I appreciate you taking the time to get in touch - reports like this help us to make Django a better community. The action you've taken so far seems appropriate, and I'd like to thank you for handling the issue with care.
We're going to keep this report on file to look for patterns in the future across the community. If there is anything else we can do to help or support you, please do let us know.
Thank you again!
Regards,
[First Last name]
DSF Code of Conduct Working Group
The first responder should also add a record of the report in our files (see Record Keeping below).
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 responsible for the behavior
- Whether this is an ongoing situation, and there is a threat to anyone's physical safety
This information will be collected in writing. The working group documents its deliberations through email discussions, notes and takeaways from meetings, and by recording decisions from DSF Slack conversations into their notes.
The process with which decisions are made differs slightly between issues, due to the fact that each issue is slightly different. However, there is a loosely defined set of stages that are present in each issue:
-
Contacting the reporter - The working group chair should contact the reporter letting them know they are the point of contact between the reporter and the working group, and will be available for the reporter if they have any questions. Based on the initial report, the chair may choose to ask for more information about the report at this time.
-
Initial discussion - The working group conducts a discussion about the report in order to understand the issue. During this time, the working group should aim to decide the severity of the issue and the appropriate next steps. This could be:
- Contacting the reporter for additional information.
- Researching the issue if there is additional evidence online or in written form.
- Contacting additional persons involved in the report.
- Contacting any official bodies (such as the Django Software Foundation or Python Software Foundation) if the working group feels they can provide extra information.
- Seeking legal advice.
Regardless of the actual steps taken at this stage, the aim is to gather a clear understanding of the issue, what occurred, who is involved, and what is the severity of the issue.
-
Deciding actions - Based on the evidence, the chair should propose to the working group the actions that should be taken to resolve the issue. The chair requires at least two members of the working group to agree on these actions. If the issue is very severe or requires legal action, it is advised that a majority of the working group agree to the actions before they're taken. The Enforcement Ladder provides details on the various actions that issues can result in. This is not a complete set of options, as each issue is different and different actions are likely.
The working group should aim to have a resolution agreed upon within a reasonable timeframe. If a resolution requires more time, the working group will respond to the reporter(s) with an update and projected timeline for resolution.
Once the working group has made its decision, the following takes place:
-
Carrying out actions - The chair performs or delegates the actions agreed upon by the working group, the first of which should be to inform the reporter of the decision made by the working group. The actions can sometimes involve contacting individuals involved in the issue. For these actions, we recommend the chair write a draft and share it with the working group before it is sent to the individual in order to check that necessary information is conveyed clearly and objectively.
- Ongoing actions - As a result of conducting the actions, the issue may not resolve straight away. Based on further developments, the chair should continue to share the developments and work with the working group to decide on the actions that need to be taken in response.
-
Resolving - Once the actions are implemented and the issue feels resolved, it is the responsibility of the chair to:
- Contact the reporter about the final resolution, and that the working group considers the case closed until new information comes to light.
- Inform the working group that the issue is considered resolved.
- Update the records with a summary of:
- Actions taken
- Outcome
- Review date
The records are kept for reference, are reviewed from time to time, and are consulted regularly to compile statistics. See Record Keeping below for more details.
If the issue was already resolved by local representatives handling a Code of Conduct issue, our working group doesn't carry the responsibility of informing the subject of the report that the record will be kept by us unless there is a clear reason why we would like to follow up to find out their side of the story.
When reviewing an incident, the working group will evaluate three key aspects:
- Is this behavior explicitly listed in our Code of Conduct as inappropriate?
- Did this occur within a space covered by our Code of Conduct's scope?
- If the incident occurred outside Django spaces but may negatively impact a community member's safety or wellbeing, should it be considered in scope?
- Did this incident occur publicly or privately? Public incidents may affect the broader community. Private incidents, though less visible, may cause substantial harm and are evaluated with equal seriousness.
- Does this behavior negatively impact people from marginalized groups in our community?
- How is the harmed party being negatively impacted?
- Are community members likely to disengage if no action is taken?
- Does this incident involve a community leader whose behavior sets standards for others?
- Does this incident involve sexual harassment or threats to physical safety?
- Will this incident severely impact someone's mental health or physical safety?
- Is there a risk of repeated behavior? Does the reported person understand why their behavior was inappropriate?
- Is there an established pattern from past reports?
Reports involving higher risk or impact may warrant more serious consequences than those with lower risk or impact.
When communicating with reporters and subjects of the report, it's important to keep the following in mind:
-
Protecting reporters is our first priority. Never forward communication or disclose identities of reporters outside of the code of conduct working group, without the express written permission of the person concerned.
-
If adding or removing people from the recipients list of an email thread, note the change at the top of the email, like this:
[+ Maya]
[- Alex]This helps guard against someone accidentally sharing protected information without being aware of the recipients.
When communicating with administrators, moderators, or the reported party, carefully anonymize all identifying information about the reporter and witnesses:
- Remove or redact names, usernames, and email addresses
- Generalize specific timestamps that could identify participants
- Describe observable behaviors without quoting unique phrasing that could identify sources
- Use gender-neutral language unless gender is relevant to the incident
When drafting communications, have a second working group member review for potentially identifying information before sending.
- Different people will experience the same situation in different ways. Use specific, factual language that describes observable behaviors and their impact rather than making assumptions about intent or internal states. This trauma-informed approach helps all parties understand what occurred while minimizing further harm.
- Always cc conduct@djangoproject.com on communication, or forward replies that had the address removed.
-
All parties involved deserve to be heard. People who are the subject of reports should have an opportunity to respond before we finalize our decision. This doesn't mean disclosing reporter identities or minimizing the harm caused, but rather engaging them in a fair process. A transparent process that respects everyone's dignity leads to better outcomes and fewer disputes.
-
Keep the primary goal centered: creating a safer, more welcoming community for everyone. This means focusing on accountability, understanding impact, and supporting behavior change rather than simply punishing individuals. This restorative approach shapes more effective interventions.
-
In many cases, directly requesting that someone not attend Django events or refrain from certain behaviors can be effective. When approached with clarity about expectations and consequences, many individuals will voluntarily comply.
When contacting someone about a Code of Conduct violation, the communication should include four components:
- Description of behavior in neutral language: State what occurred using factual, observable terms without assumptions about intent
- Impact of that behavior: Explain the negative effects on individuals and/or the community
- Behavioral modifications expected: Provide concrete, specific expectations for changed behavior going forward (if applicable)
- Consequences: Clearly state what consequences are being applied and what may happen if the behavior continues
Do not disclose who reported the incident. If the person wishes to apologize to someone harmed, the working group can facilitate this or accept the apology on their behalf, but direct contact should be discouraged unless all parties consent.
Sharing information with other community leaders or making information public may be necessary when the community remains at risk despite private interventions.
When deciding to share information about individuals who have violated the Code of Conduct, there is potential for claims of slander, libel, defamation of character, and reputational damage. In serious cases we should seek legal advice. The following approaches mitigate this risk:
-
Whenever possible, work to corroborate reports with multiple sources or identify patterns of behavior. This enables us to:
- Describe patterns of behavior rather than isolated incidents, which provides important context for protective actions.
- Protect individual reporters by not centering any single report.
-
There's an important distinction between providing information and directing action. If we instruct event organizers "Don't invite this person," we become directly responsible for any reputational consequences. However, if we inform organizers that a person has been the subject of Code of Conduct reports relating to specific types of incidents, while leaving the final decision to them, the DSF is providing information to help them make informed decisions about their events.
-
All information sharing must be documented in writing rather than through video calls or voice conversations. When informing community organizers about individuals who have violated the Code of Conduct, communicate via email using precise, factual language that makes clear they are empowered to make their own decisions based on the information provided.
-
Strict adherence to our established processes is essential. Any claims of improper handling will examine whether we followed our documented procedures consistently and fairly.
Aligned with Contributor Covenant 3.0's focus on repairing harm, our communications should emphasize accountability, growth, and community healing.
-
Focus on impact, not intent. When discussing violations with reported parties, center the conversation on the harm caused rather than debating their intentions. Acknowledge that harm can occur even when unintended.
-
Be clear about expectations. Communicate specific, actionable expectations for behavior change. Vague requests like "be better" are less effective than concrete guidance such as "Do not contact Jin directly; communicate only through the working group."
-
Support accountability. When appropriate enforcement actions include opportunities for repair (such as apologies or acknowledgment of responsibility), provide guidance on what meaningful accountability looks like. This might include acknowledging the specific harm caused, demonstrating understanding of the impact, and committing to behavior change.
-
Use trauma-informed language. Avoid language that minimizes harm ("just a misunderstanding") or blames those who were harmed ("they were too sensitive"). Use person-first language that separates the behavior from the individual's identity. Refer to “the individual whose conduct was reported” rather than labeling someone by the behavior, and to “the individual who experienced harm” rather than defining someone by the harm.
-
Respect everyone's dignity. Even when addressing serious violations, communicate in ways that preserve the humanity of all involved. This doesn't mean avoiding consequences, but rather implementing them with respect and clarity.
-
Provide appropriate context for repair actions. When communicating repair actions to reporters or the broader community, explain how they address the harm and support community safety without unnecessarily disclosing private details.
The working group must agree on a resolution by consensus. Where consensus cannot be reached, decisions may be made by a two-thirds majority vote of working group members without a conflict of interest. If the working group cannot reach consensus or a sufficient majority within a reasonable timeframe, the working group will turn the matter over to the board for resolution.
Our Enforcement Ladder may be used to determine how best to address a Code of Conduct violation with the goal of repairing harm. The working group will consider the incident's impact on individuals involved and the community as a whole. Depending on the severity of a violation, lower levels may be skipped.
The enforcement ladder includes:
- Warning - Private written warning with clarification and expectations
- Temporary Suspension (Short-term) - 30-90 days with readmission request required
- Temporary Suspension (Extended) - 90+ days with conditions for return
- Permanent Ban - Permanent removal from all Django spaces
Additional resolution options include:
- Taking no further action if no violation occurred
- Facilitated communication between parties (with consent)
- Referral to the Online Community Working Group for ongoing monitoring
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. The final decision rests with the working group, using their best judgment to balance the needs of the affected parties with the safety and health of the broader community.
Finally, the working group will make a report for the DSF board via the board liaison. In case the incident or report involves a current member of the board, the working group will provide the report only to the other board members.
Regardless of the outcome, we note each report and outcome in our records. The spreadsheet with status of open and closed cases has the following format:
- Date of Report - When the report was received
- Case Code Name - A randomly generated code name (e.g., "home shelf", "stunned bulb") assigned to the case for privacy purposes. To generate one, select the cell in the spreadsheet and click Django CoC > Generate Code Name in the menu.
- Person Code Name - A persistent code name assigned to the reported person (e.g., "Person A", "Blue Jay") to track repeat reports without using real names in the spreadsheet.
- Status - Ongoing/Resolved - Current status of the case
- Resolution Source - Who handled the resolution (e.g., "CoC WG", "DSF Board", "Local Event Reps", "None")
- Resolution Date - When the status was set to Resolved
- Safety Risk - Yes/No - Does this incident pose a safety risk or include threats to physical safety?
- Ongoing Harassment - Yes/No/Maybe - Is there a risk of repeated behavior?
- Consequences - Enforcement actions taken (e.g., "Not a violation", "Out of scope", "No action taken", "Warning", "First Suspension", "Second Suspension", "Ban", "Other")
- Documents - Link to detailed documentation of the case (see below)
Keep resolutions and notes vague enough that working group 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.
In the case that more than one person is reported in the same case, add a new row for each additional person, with the same Case Code Name but a different Person Code Name. This allows us to track multiple reports about the same individual across different cases while keeping the spreadsheet organized.
Each report should be assigned a case code name (generated via the spreadsheet menu). The case code name should be used in the document's title. Only working group 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 working group 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, event organizers, or the Online Community Working Group 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.
The working group maintains records of all information and communications related to incident reports, including:
- Initial reports and all communications with reporters
- Investigation materials and evidence
- Email discussions and documented deliberations
- Notes and key takeaways from meetings
- Decisions made in DSF Slack (recorded into meeting notes)
- Communications with all involved parties
- Final resolutions and any follow-up actions
Records are retained in accordance with the Django Software Foundation's data retention policies and applicable privacy laws.
Records are currently stored in four locations:
- Status Tracking Spreadsheet: Contains anonymized case data (Case Code Names, Person Code Names, Status).
- Person Identity Key: A separate, highly restricted spreadsheet mapping "Real Names" to "Person Code Names" and tracking report counts and highest recorded consequence.
- Report Documentation: Individual Google Docs for each case.
- Affiliated Programs Register: A spreadsheet in the shared Google Drive listing all affiliated programs and communities along with the name and individual email address of each program's designated Code of Conduct point of contact. This register must be kept up to date as programs join, update their contact, or lose affiliated status.
All documents are shared only between members of the working group. The working group insists on not sharing the records outside the members due to confidentiality of information. Violating this will result in removal of the member from the working group.
Privacy Considerations:
- Always share documents with specific working group members rather than turning link sharing on
- Use code names in document titles instead of real names or identifiers - even if a person doesn't have edit or view access to an individual report, they can still see document titles in shared folders
- Code names prevent inadvertent identification and make it easier to discuss cases in public spaces (such as events)
- Identity Key Access: Access to the Person Identity Key may be restricted to a smaller subset of the working group if necessary to manage conflicts of interest.
Member Access:
- Once a member steps down from the working group, their access to the records is removed
- When onboarding new working group members, they should be provided with a list of code names for all existing reports
- The new member should state whether they have any conflicts of interest with reviewing documentation for those cases. Refer Conflicts of Interest.
- If no conflict exists, they will be given access to those report documents
- All members of the working group involved in handling a specific incident report have access to all records related to that report, ensuring informed decision-making
The board may request access to records for oversight purposes.
The working group records all reported incidents, regardless of who reported them, who handled them, or whether they were found to be a violation. Records can be grouped in one of five types:
- The working group assessed no violation occurred.
- The working group determined a violation occurred, but it is not possible to identify who was responsible.
- A violation occurred and was resolved as far as the working group is concerned.
- A violation occurred and the person/record is flagged, due to concern about their behaviour in the future.
- A violation occurred, and the person is banned temporarily or permanently.
Flagging is a specific scenario, where the violation was dealt with, but the working group feels there is a risk that this person may commit further violations in the future. However, the concern is not great enough to ban the person. This may be the case if someone responded very poorly to a message from the working group, and did not seem to acknowledge that their behaviour needs to change. Another example could be a person who drank very excessively at a conference party and caused unpleasant situations for other attendees.
The working group may provide further suggestions on how to best manage this person's attendance. In the example of excessive alcohol, the conference team might then decide to allow the person to attend the conference, but not the party, or to allow them to attend the party but forbid any alcohol consumption. For people who responded poorly to the Code of Conduct process in the past, it may be appropriate to have a conversation with them about this, and then decide whether and how they can be part of a conference.
This is in contrast to people who are not flagged, but did violate the CoC: in this case the working group feels there is no particular risk of further violations, and it would be excessive to notify conferences of their history.
In summary, to flag a person/record means: "if this person attends a conference, or otherwise participates in the community, it would be irresponsible if the working group did not inform the conference of their past behaviour, and allowed the organisers to consider extra precautions".
The working group is committed to protecting the privacy and personal information of all parties involved in Code of Conduct matters. Personal data is:
- Stored securely with access limited to working group members
- Used only for the purpose of investigating and resolving reports
- Retained only as long as necessary
- Protected in accordance with applicable data protection regulations
The identity of the reporter and any harmed individual(s) must be kept strictly confidential. This information will not be shared beyond the working group members handling the case, except:
- When necessary to conduct the investigation
- When required for immediate safety interventions
- When required by law
Reports and the identity of reporters will be kept confidential to the extent possible. The working group will not share reporter identities with the reported party. However, in some situations, context may allow individuals to infer who made a report.
The identity of the reported party should be kept confidential during the investigation and resolution process. However, implementing certain decisions may require sharing limited information beyond the working group, such as:
- Communicating a ban to community moderators
- Taking immediate action to prevent ongoing harm
- Responding to public statements by the reported party
When the reported party chooses to discuss the matter publicly, the obligation of confidentiality toward them is reduced. However, the working group will still:
- Maintain confidentiality about the reporter and harmed individuals
- Not make any public statements (any public statements are made by the DSF Board)
- Avoid retaliatory or excessive disclosures
In all cases, information sharing should be limited to what is strictly necessary to address the situation and implement the resolution. The working group does not comment publicly on incidents; if public statements are necessary, they are made by the DSF Board.
Any member of the working group must immediately notify the other members in writing (by disclosure on the report email thread) and recuse themselves from handling a report if they:
- Are involved in the incident itself
- Have a personal relationship with any involved party
- Work for the same employer as an involved party
- Have access to private information that could bias their judgment
- Have any other conflict of interest that could affect their impartiality
If a report concerns a possible violation by a current working group member, that member must be excluded from the response process. For these cases, anyone can make a report directly to any of the other working group members, as documented in the reporting guidelines.
If a report concerns all current chairs of the working group, reports should be sent directly to the DSF board at foundation@djangoproject.com instead.
If the act is ongoing (such as someone engaging in harassment in an online space), 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 must 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 working group member acts unilaterally, they must report their actions to the working group for review within 24 hours.
The Code of Conduct working group is committed to transparency about our processes, decisions, and activities. For complete information about our transparency practices, including what we disclose and what we protect, see Transparency.
Key transparency practices include:
- Publishing this manual and other documentation about our procedures
- Publishing statistics every 6 months (see statistics.md)
- Annual transparency reports with anonymized data and trends
- Never publicly discussing specific incidents - all public statements are made by the DSF Board if necessary
We balance transparency with our commitment to protecting the confidentiality of reporters, harmed individuals, and reported parties.
Our documents and policies are adapted from and inspired by a number of sources.