Case numbers

[cogat]

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?

[olasitarska]

Ok, so this seems a little bit more complicated than I thought. What I had in mind is something that conferences do, see example 1, 2. Specifically thinking of things listed in anonymised list of incidents in that blogposts.

Hypothetical (not real reports) examples:

## 2016  

- Received report about a person making repeated offensive comments on django-users mailing list. Person has been informed that their abusive behaviour is not tolerated, and has been removed from the django-users mailing list. 
- Received report about a person making a racist joke on a Django conference. Person has been warned to make sure they are more mindful about their language in the future. 

I think that would be completely enough... The idea of this is to show what kind of issues we're dealing with, and how, not to created a very detailed and structured data table?

[cogat]

Right, but if we're keeping logs of our cases in different forms in multiple places, it won't always be clear e.g. which private records of our cases corresponds to which public records. This opens us to extra book-keeping overhead and the risk of duplicating or missing reports as we translate them from one place to another.

This will be exacerbated as our committee changes over, and our memory of which case is which is lost.

To take your example, if there are several complaints in a year about offensive comments on django-users, but we are not sharing identities publicly, it will be difficult to tell, without counting them all up each time, which report/offensive person is which. Assigning a reference number would make it trivial to crossreference.

Relatedly, I've struggled before to refer unambiguously to specific cases without compromising anonymity of individuals concerned. Having reference numbers would make this unambiguous.

[olasitarska]

I think for bookkeeping sake, having another column in a spreadsheet stating whether this is published here or not would be enough.

But your idea is fine too, I'm happy to add case numbers or whatever makes it easy for us to tell which case is which. Just trying to make sure we don't overthink this and make this too complicated for ourselves to maintain or stopping us from publishing it at all. I'm always on the side of simple MVP, and then improving later as we see problems coming up.

[cogat]

Agree simple is best! I've added a column called "Stats published to github". For now this says "summary" so we can change to "yes" once #2 is implemented.