django/code-of-conduct

Internal documentation of the DSF Code of Conduct committee

Django

Django is a high-level Python web framework that encourages rapid development and clean, pragmatic design. Thanks for checking it out.

All documentation is in the "docs" directory and online at https://docs.djangoproject.com/en/stable/. If you're just getting started, here's how we recommend you read the docs:

• First, read docs/intro/install.txt for instructions on installing Django.
• Next, work through the tutorials in order (docs/intro/tutorial01.txt, docs/intro/tutorial02.txt, etc.).
• If you want to set up an actual deployment server, read docs/howto/deployment/index.txt for instructions.
• You'll probably want to read through the topical guides (in docs/topics) next; from there you can jump to the HOWTOs (in docs/howto) for specific problems, and check out the reference (docs/ref) for gory details.
• See docs/README for instructions on building an HTML version of the docs.

Docs are updated rigorously. If you find any problems in the docs, or think they should be clarified in any way, please take 30 seconds to fill out a ticket here: https://code.djangoproject.com/newticket

To get more help:

• Join the #django channel on irc.libera.chat. Lots of helpful people hang out there. Webchat is available.
• Join the django-users mailing list, or read the archives, at https://groups.google.com/group/django-users.
• Join the Django Discord community.
• Join the community on the Django Forum.

To contribute to Django:

• Check out https://docs.djangoproject.com/en/dev/internals/contributing/ for information about getting involved.

To run Django's test suite:

• Follow the instructions in the "Unit tests" section of docs/internals/contributing/writing-code/unit-tests.txt, published online at https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/unit-tests/#running-the-unit-tests

Supporting the Development of Django

Django's development depends on your contributions.

If you depend on Django, remember to support the Django Software Foundation: https://www.djangoproject.com/fundraising/

code-of-conduct's Issues

Do we have an adoption list that contains which GitHub projects adhere to django CoC?

Like contributor covenant's adoption list, https://github.com/ContributorCovenant/contributor_covenant/blob/master/data/adopters.csv,
do we have any similar list for Django code of conduct?

License?

I'd like to base our new Write the Docs COC policies off the Django ones. Are they licensed in any particular way? I'll plan to definitely give credit and link back, and happy to abide by any other license terms.

Compliance with privacy laws when working with conferences

👋 I thought this might be more useful for me to raise this here rather than via email. On Conferences – Support for event organizers - Before the event:

We advise that you share the list of attendees with us such that we are able to check it against our list of Code of Conduct offenders. […]

Similarly, before you announce your accepted speakers, you can send us the speaker list to see if any appear on our lists.

We considered doing this as part of DjangoCon Europe 2023 but the DSF Code of conduct committee didn’t seem to us to be set up so this can be done lawfully according to the UK / EU GDPR. Based on my understanding of official UK GDPR guidance by the ICO, the committee (or the organisation the committee is part of) would be considered either a controller, processor, or both.

Specific issues (from my understanding) are:

• Knowing what legal entity the CoC committee is part of, so that entity can be declared by conference organisers as a processor on a privacy policy.
• Knowing how and by which organisations the lists of attendees and speakers are processed, so again this can be declared in a privacy policy
• Having details of any data retention policy / how the CoC committee complies with subject access requests.

After the event

Conferences in the Django community are strongly encouraged to keep reports on all Code of Conduct incidents they handle, and send these reports to the committee after the end of the conference. Reports should include names of people involved and, ideally, a description of the facts determined by the conference team, the review of the incident, actions taken, and responses to actions taken. We also appreciate any screenshots of original slack or twitter messages, or recordings of talks, that show the violation, and copies of message exchanges between the team and any reporters or bad actors.

This side of the committee’s data processing is much better documented and there already are privacy-protecting policies in place, however there are still a few sources of concern as a conference organizer:

• Again knowing what legal entity the CoC committee is part of (is it the DSF? something else?)
• And having a list of data processors for those reports
• Understanding how subject access requests are handled.

---

Again I want to restate the above is all based on my personal understanding of the UK GDPR, and this isn’t my field of expertise. So do take this with a grain of salt!

Define roles and responsibilities for stats gathering

The current (documented) arrangement is that "someone" (me, de facto) updates the statistics every 6 months. The reports google spreadsheet has a tab that automatically compiles stats for a given year, and they need to be copied from that tab into the published account, which is currently in statistics.md and on https://www.djangoproject.com/foundation/committees/#conduct.

IMO there isn't currently enough change in statistics to be worth doing more frequently than that, but there may well be in future.

Ola has stated a preference for doing this more regularly, ie every 2-3 months. I'm curious about the reasons for this - ie what use can be made of having the statistics updated more regularly.

There's also the question of what statistics we compile, which I think can be covered in #2.

Case numbers

Spun off from #2, we may easily lose track of cases when transforming them into summaries and statistics. One simple way of keeping track, without compromising anonymity, is to assign case numbers. I propose the following format:

yyyy.n

e.g. 2016.4 is the case of the 4th report we received in 2016. Ongoing communications with the reporter about one report count as the same case.

Multiple subjects of one report

A report usually relates to one person. Occasionally a report relates to more than one identified person, and the outcomes for each person can differ. We should append a letter for each person, e.g.:

2016.4.B - the subcase of person B in the 4th report we received in 2016.

Each subject already gets a separate row of the summary table.

Combining cases

It's conceivable that we receive several reports about one event, or one community, or one person, which we decide to treat as one case. In that situation, we should make a "combined" case number, noting that the other reports indicate a pattern, e.g.:

2016.3.Combined: Turns out 2014.2, 2015.3.B and 2016.2 are the same person.
2016.9.Combined: Reports 2016.5-8 about the same community. Handling them together here.

Comments?

Membership chapter needs information about who joined when, and when is the end of their term

I think we could transform the list of members into a table to present that information. However, we first need to figure out who joined when and how long is everyone planning to stay around for :)

Update Code of Conduct team

We need to update our Code of Conduct membership since everything is out of date.

• Update Google Group's membership
• Update Google Drive access
• Update GitHub Team access
• Update membership in our Code of Conduct Working Group charter
• Update our Slack Group

For GitHub, we need to add:

• @mclarknc (our chair)
• @ckirby (DSF President and board liaison)
• @kjaymiller
• @dryan
• @thibaudcolas
• Add Elena Williams
• Remove @mclarknc (our past chair)

Reports.md: describe how we make decisions

Person who is shepherding the issue makes a decision -- hopefully usually this is going to be the primary person on duty. To make a decision, we require one +1 at the moment.

Reports.md: add checklist on what should happen when decision is made

• Inform the person who reported about actions being taken.
• Take the necessary actions. If it requires writing an email to someone, get a +1 on the contents of the email.
• Add the summary of the report to the spreadsheet.
• Update statistics in these docs.
• Anything else?

Include anonymised summaries of reports and actions taken in Statistics chapter

Any opinions why we shouldn't do that?

Communications guidelines

I wanted to capture some of the guidelines we've used for communicating fairly and handling confidentiality/reputations in the past. I've pulled together the things on my mind into communications.md, which is hopefully a better-than-nothing start.

Add content to data-retention.md

Describe:

• how we store data about incidents
• how long we store it for
• who have access to it
• find out whether anyone have access to past emails, or if newly joined members only see new emails? My impression is that only Frank from DSF has access to archive of the emails, or maybe even he doesn't?

Membership list and terms are out of date

We have many new committee members and our membership list is out of date: https://github.com/django/code-of-conduct/blob/master/membership.md

Hard line wraps

In most of the documentation, each paragraph takes one whole line. This means that a change somewhere in the paragraph affects the whole paragraph, making comparisons difficult.

Once the repo is settled after the current flurry of activity, I think we should pause and someone should change soft line wraps into hard wraps (any prefs for 40 or 80 characters?) so that changes can be compared over a small number of characters.

Improve guidelines on undermining the CoC process

TODO that I moved into issue from communications.md docs, originally written by @cogat:

We need to beef up our CoC guidelines to make it clear that retaliatory actions will be penalised at 10x the impact of the original infractions. For example, if we censured someone privately, and then we found out that they had worked out the source of the complaint and was spreading rumours, we could come out publicly and hard. At that point, the public announcement is that the person has shown utter contempt for the CoC process, and as such, the DSF doesn't believe they can be trusted at events. The fact that there was an original CoC complaint is almost secondary at that point - the person is being publicly censured for undermining the CoC process.

Conferences.md -- add information how can we help conferences be more safe

Here we wanna describe how we can provide support to conference organizers (being on-call during the event, offering advice, flagging people from their list of attendees and speakers).

:pencil: Document onboarding member to the team

• Request they be added to the https://github.com/django org if they aren't already (email [email protected] to get added)
• Add member to https://github.com/orgs/django/teams/coc-committee/members
• Add email account to: https://groups.google.com/g/django-coc-committee
• Add email account to Google Docs (TODO)

Revise docs and remove mentioned of shifts/duties

tl;dr the goals and what the WG has changed since we first started it. We should revise our docs and remove mentions of duties and shifts since we haven't done this in ~5 or 6 years.

See #31

Reports.md: describe "flagging" and "blacklisting"

From @cogat:

In my mind "flagged" means we will share the summary outcome of the report with event organisers; "blacklisted" means that the information will include that we have asked the person not to attend events covered by the django CoC. Blacklisted is a subclass of flagged.

Describe contributing process to this repository, and role of issues

I think that once we make this live and public, it'd be good to let other people contribute ideas and give us feedback in form of issues.

Seems like a good idea to explain what people can expect in some kind of CONTRIBUTING.md file?

Reports.md: describe how we handle received reports

• Information about rotation duty and how it is implemented
• What kind of reports we receive
  • From local reps
  • From people asking for help
• If response requires decision, we aim to respond with a quick acknolwedgment of received report in a couple of hours
  • Add example response here -- we may use the last one I sent last weekend
• If response doesn't require decision, we still aim to respond within couple of hours, but acknowledge the report, thank the reporter, say we're gonna keep it on file.

Add content to transparency.md

Describe how we want to keep the committee transparent to the Django community. My ideas:

• Publishing this docs, describing our processes, etc
• Updating statistics in this docs
• Publishing a quarterly transparency report with anonymized summaries of received reports? + Storing those transparency reports here.