Proposal : Conflict resolution, CoC violation reporting and CoC enforcement

[benjagm]

As part of the Charter Discussion: #286, we have been discussing non-technical decisions and conflict resolution and in that context, I'd like to make a distinction between decision-making and conflict resolution:

• Decision-making: The TSC will be responsible for the technical and strategic decisions related to JSON Schema following the process described in the Charter.
• Conflict-resolution: Conflict is not a bad thing; healthy debate and disagreement often yield positive results. However, it is never okay to be disrespectful or to engage in behavior that violates the project’s code of conduct. In this case, we should establish a clear process for CoC violation reporting and CoC enforcement.

With this proposal, I will love to start a discussion with the Community about the benefits of including a Reporting Guide and an Enforcement Manual. In my research I included:

• Other projects members of OpenJS Foundation.
• Projects with Enforcement manual.
• Projects describing how to proceed when the Code of Conduct report involves committee members.

The result of my research is a proposal to complement our Code of Conduct with an approach inspired on Jupyter project:

• Enforcement Manual: https://github.com/jupyter/governance/blob/main/conduct/enforcement.md
• Reporting Guide: https://github.com/jupyter/governance/blob/main/conduct/reporting_online.md

Modifications suggested for our Code of Conduct:
1- Enforcement Responsibilities (Add a new clause in this section)

If a Code of Conduct report involves a member of the Committee, that member will not participate in the investigation or any decisions related to that report. If the report involves multiple members of the Committee, it will be mandatory the mediation of the OpenJS Foundation Code of Conduct Panel (CoCP)

2- Conflicts of Interest (Add this new section)

Conflicts of Interest

In the event of any conflict of interest, a committee member must immediately notify the other members, and recuse themselves if necessary.

I do think these are easy changes adding a lot of clarity and transparency to the process but I'd love to get everyone's feedback.

[yaffol]

I think that clarity around the mechanics of how a CoC will be enforced (if necessary) in practice are always a good thing, as it turns the CoC from a 'fine ambition' into a real, tangible process which people can rely on.

Creating and publishing an Enforcement Manual and Reporting Guide create concrete representations of the ambitions - that's a good thing.

It's never fun dealing with enforcement of community rules, and a clear structure and process to follow helps both those enforcing and other parties to understand what is happening, and why.

From the perspective of considering whether to become involved in a project, I find that projects with clear CoCs, and clear processes for managing any violations give me confidence that the community has good governance, and that I find re-assuring.

The specific changes make sense to me. A clear route of escalation, should a report involve a committee member, with clear recusation of the member from the investigation and its consequences is good practice. Likewise the referral to the OpenJS Foundation, in the event of a report involving multiple members.

Likewise with the requirement to notify/recuse in the event of a conflict of interest. This probably happens already, but it's good to be clear and public about that.

I think these are good changes, thank you for the careful research!

[benjagm]

Checking this great thread at OpenJS Foundation: openjs-foundation/cross-project-council#786

Some other elements we have to consider as per OpenJS Foundation:

• Have an email reporting address.
• Publicly list who is on that email address.
• Publicly document the decision-response process.
• Confidentiality of reporter and victim.
• Basic rules around data retention to meet legal requirements (e.g. GDPR)

[Relequestual]

Have an email reporting address.

We have this, but we should modify it to be an official JSON Schema org one.
Currently we do not have mail servers for the json-schema.org domain name.
OpenJS Foundation will likely be able to provide these for us... ONCE the project graduates, not before.

Publicly list who is on that email address.

Agreed. Currently it is just me. I would like it to be not me.
I have previousley tried to find some others to create a Code of Conduct Review panel, but no luck.

Publicly document the decision-response process.

I'd be keen to see what other projects of different sizes document.

Confidentiality of reporter and victim.

We do have the following in our code of conduct:

All community leaders are obligated to respect the privacy and security of the reporter of any incident.

and...

As per Code of Conduct requirements set out by the OpenJS Foundation, we will maintain the confidentiality with regard to the reporter of an incident. For the purposes of tracking between Code of Conduct review members, incidents may be tracked in a private organizational GitHub Repository. In addition to any Code of Conduct review team, GitHub organizational owners will have access to view details of reports by way of having full GitHub organizational admin access.

What more specifics do you (or anyone) think we should have here?

Basic rules around data retention to meet legal requirements (e.g. GDPR)

I guess this would be a question for the OpenJS Foundation. Given the OpenJS Foundation take on "business" related responsibilities, I would guess this is one of them. I don't know who the "data controller" would be, or how other similar geographically specific regulations might apply. Thanks for catching this.
@benjagm Can you add this to our list of questions for the OpenJS Foundation? (Maybe we need a new issue to keep a list of them? Or a document of some kind?)

[benjagm]

Publicly document the decision-response process.

I'd be keen to see what other projects of different sizes document.

Some examples:

• DJANGO: https://github.com/django/code-of-conduct/blob/main/records.md
• Carpentries: https://github.com/carpentries/executive-council-info/tree/main/code-of-conduct-transparency-reports
• NodeJS: They uses a private moderation repository to ensure privacy. This is their moderation policy: https://github.com/nodejs/admin/blob/main/Moderation-Policy.md#consideration-of-intent

[gregsdennis]

For the NodeJS, who has access to the repo? Seems like it could only be the panel members. Allowing anyone else access to a repository like that would also give them access to other decisions which should be confidential.

[Relequestual]

https://github.com/nodejs/admin/blob/main/Moderation-Policy.md#privacy-of-the-nodejsmoderation-repository

The nodejs/moderation Repository is used to discuss the potentially sensitive details of any specific moderation issue. The repository is private but accessible to all Collaborators. The details of any issue discussed within the nodejs/moderation repository are expected to remain confidential and are not to be discussed in any public forum or social media service.

Any Collaborator found to be violating the privacy of the nodejs/moderation repository by repeatedly sharing or discussing the details of nodejs/moderation issues in any public forum or social media service risks being permanently removed from the Node.js GitHub organization.

I don't think it's unreasonable to make such a repo only accessible to a moderation team. Any org wide admins would still have access though.

The moderation team are also voted in by the TSC and must report monthly to the TSC.

They do link to additional expectations for TSC and Moderation team members, beyond the CoC.

[gregsdennis]

If the report involves multiple members of the Committee, it will be mandatory the mediation of the OpenJS Foundation Code of Conduct Panel (CoCP)

Maybe

If the report involves multiple members of the Committee, mediation will defer to the OpenJS Foundation Code of Conduct Panel (CoCP)

[benjagm]

Thanks. I like your proposal.

[Relequestual]

Figure it's worth sharing this as a resource: https://medium.com/mozilla-open-innovation/how-were-making-code-of-conduct-enforcement-real-and-scaling-it-3e382cf94415

The link to a repo with many more resources: https://github.com/mozilla/inclusion