Following up from #101 and the council FAD.

Code of Conduct

The Fedora Code of Conduct (https://getfedora.org/code-of-conduct) is fairly well written. While I am sure we could all wordsmith it here and there, I am not sure it needs many changes. I would like to see statements reminding people to:

• assume the best
• remember that not everyone uses English at the same level of proficiency so consider all of the meanings, not just the ones that are connotive for you. Help people realize when words are "loaded"
• React to what people do, not who they "are". See: https://www.youtube.com/watch?v=b0Ti-gkJiXc

I'd also give consideration to having the language made a bit more precise. I know of at least one software license that creates problems because it requires users of the code to only do good things. Telling people they need to be "excellent" may be creating a similar grey area.

Enforcement

At the FAD we had hoped to survey a small set of communities. Specifically we wanted to ask these people for insight (or other contacts) into how their communities handle CoC enforcement.

• Langdon - Gentoo
• Christoph Wickert - SUSE
• Charles Proffitt - Ubuntu

We also briefly discussed making sure that we as much transparency as possible to prevent one-sided conversations. i.e. transparency of the reporter and the reported, the enforcer and the enforced. Stack Exchange has talked about their lack of public reporting here and it is a good read: https://meta.stackexchange.com/questions/293213/why-dont-we-keep-public-records-of-suspensions?cb=1 (sent to me by @mattdm)

We also talked about having both an escalation path and democratization of the process so that hopefully most incidents would never reach full enforcement.

In my, albeit limited, research, very few communities that are similar to us provide a lot of insight into their enforcement process. One example I did find was Gentoo's policy. https://wiki.gentoo.org/wiki/Project:ComRel#Disciplinary_action_and_resolution

They divide the enforcement into direct violations and escalated conflicts. Their direct violations policy provides for immediate removal for cooling off periods. Multiple violations result in longer periods and can result in further actions. The cooling off periods are scaled, based on, as far as I can tell, the bandwidth of the communications medium. I like this idea and it mirrors what others have proposed.

The escalated conflicts are handled on a more ad-hoc basis using a deliberative and mediated methodology. I am not aware of our community having had many of this type of issue, directly.

Next Steps

1. We should read several other code of conducts and see if there is anything missing from our that we feel is urgent to add. My list is above. I think council should have two weeks to prepare their suggestions and we should have one week to review them. I believe we should then open a conversation in community with a draft with changes for conversation.

2. I believe we should ask Red Hat Legal for their initial opinions on the Gentoo policy as known and having reporting go to the Council. This initial read can help us guide our final submission. I will volunteer to do this.

3. I believe we should contact the other communities and gather as much data as we can, but with a hard deadline so this doesn't drag on. I believe we should target Mid-May. I will volunteer to do this.

4. I believe we should make sure we want reports coming to the full council. As a point of comparison, internally for similar issues, Red Hat has a single person who triages all reports and sends them out to a larger group if it is appropriate. Reports about that person or their peers are sent to a single other delegated person. I propose we adopt:

   • Reports are to be submitted by email to council-private@lists.fedoraproject.org. This way tickets are not accidentally or purposefully left public.

   • Reports about the Fedora Council should be sent to a Red Hat designate. I suggest we start by asking the OSAS unit leader, Deborah Bryant to take on these reports. Red Hat Legal may also be willing to do this.

5. We establish a location to log the reports and their outcomes. I don't believe we should rely on traditional Fedora infrastructure to do this because of the perception (but not belief) that admins may have access to data they shouldn't. Instead, I suggest we ask the Community Cage group in OSAS to provide us with a git repository that we can restrict access too. I can coordinate with this group if we like this idea.

6. Once we adopt this we message out our thoughts and the policy. We also get the IRC, Bugzilla, and Mailing List admins on board and ask for reports on all non-trivial cases. I believe our final policy needs to leave them with some ability to do trivial bans (especially in IRC) as long as they can demonstrate that they have a system for realizing when someone is a continuous trivial violator and needs a greater response.