We should adopt a Code of Conduct. Let's start with Contributor Covenant

[Relequestual]

To the best of my knowledge, JSON Schema has never formally had a Code of Conduct (CoC).

I personally only recall one instance where a CoC may have been useful.

We want to make people feel welcome, and so should have a formal CoC.

Contributor Covenant is an easy to read and understand CoC. We would be in good company!

Should we join the OpenJS Foundation, we are required to adopot their extended version of the same CoC.

I see no reason not to adopt this CoC. It would not be set in stone, and we can append additional rules or write our own as we see fit.

Please voice your comments and thoughts.

[matthewtrask]

huge +1 to adding this. Even though I've never contributed, a code of conduct goes a long way, and I want people to feel welcome and safe every time I talk about using the project.

[jdesrosiers]

The Contributor Covenant CoC sounds great. Here are a few additional things we will need to consider.

• How do people report violations?
• How do we communicate our CoC and how to report violations?
• Will violation reports and resolutions be public record?
• Who receives and decides on violation reports?
• What happens when the person/people deciding on resolutions are the ones being accused of violations?

[Relequestual]

How do people report violations?

Using a single email address which will forward to each of those on the CoC review comittee

How do we communicate our CoC and how to report violations?

Using a .github repoditory means this and other community related documents will automagically appear in all repos in the org.

Will violation reports and resolutions be public record?

From the proposed CoC...

Community leaders ... will communicate reasons for moderation decisions when appropriate.

Even for teir 1, "Correction" response, a public apology may be required. This is at the discression of the review comittee.
The identity of the reporter must always remain confidential, even if they out themselves.
We should keep a log of reports, comittee meetings, and resulting decisions. I feel it's reasonable to provide a public log with names redacted.

Who receives and decides on violation reports?

The CoC review comittee. This is yet to be formed, but we will aim to fill it with representative membership. I'll be part of the comittee initially, and until such point as I believe it can function without me.

Doesn’t a code of conduct give too much power to project maintainers?

Project maintainers are the arbiters of code of conduct violations and are the unquestioned leaders of the projects they own. Without a code of conduct, a project maintainer has the power to eject any contributor from a project for any (or no) reason at all. A properly enforced code of conduct creates a social contract between and among contributors and maintainers that make such abuses of power less acceptable and common. If you don’t trust a project maintainer to act in a just and fair way, you probably should consider not participating in their community.

• https://www.contributor-covenant.org/faq/

I sort of agree with this, but also note JSON Schema is not owned by any individual, but we think in a similar way here. The "ownership" is a limited set of people that we have to ultimatly collectivly (the maintainers) trust or hope will do the right thing.

What happens when the person/people deciding on resolutions are the ones being accused of violations?

Report emails will go out automatically to each review comittee member. If they are accused, they will need to recuse themselves until the issue is resolved. They may need to temporarily be removed from the email list.

[jdesrosiers]

My questions were intended to be mostly rhetorical to make it clear that simply adopting a CoC is only the beginning. There's a lot more work to be done if we want this to be more than just CoC theater. The answers you gave scratch the surface, but there are a lot more details to dig into.

How do people report violations?

Using a single email address which will forward to each of those on the CoC review comittee

Sure, but what will that email contain? Should there be an official report template? What is the minimal information we need to collect?

Using a .github repoditory means this and other community related documents will automagically appear in all repos in the org.

I was thinking beyond things like a CODE_OF_CONDUCT file in the repo. For example, putting basic information in issue and PR templates can help remind people to behave themselves and remind people they have options if they feel mistreated.

We should keep a log of reports, comittee meetings, and resulting decisions. I feel it's reasonable to provide a public log with names redacted.

This process will need to be publicly documented. I think it's really important to be as transparent as possible with these things, while still protecting the privacy of victims when necessary.

Who receives and decides on violation reports?

The CoC review comittee. This is yet to be formed, but we will aim to fill it with representative membership.

I figured as much. I was thinking more along the lines of, how to do we choose who is on the committee? Is it the core team? Is there an election? How frequently are people rotated on/off the committee? How many members will be on the committee?

If you don’t trust a project maintainer to act in a just and fair way, you probably should consider not participating in their community.

That's terrible advice! Speaking as someone who has left this community in the past for exactly those reasons, I can tell you that it's not as easy as just deciding not to participate. If the company you work for or a vendor you depend on uses JSON Schema, you don't have a choice to use something else. Not participating just means you don't have a voice in something that effects your daily work. There needs to be some way to ensure that project leaders are held accountable.

Report emails will go out automatically to each review comittee member. If they are accused, they will need to recuse themselves until the issue is resolved.

That's a start, but any committee that needs to decide on a report against another project leader should not be majority project leaders. That conflict of interest should be addressed. There's a lot to consider here and I don't have answers.

[Relequestual]

Thanks Jason, these are all really good considerations which we need to address!
I do not want CoC theater. That would be horiffic and wrong.

I'll just touch on one thing here...

That's terrible advice! Speaking as someone who has left this community in the past for exactly those reasons...

Yes, I agree, it's not good advice here and I'd say it's actually unhelpful. Maybe I shouldn't have included it.

I think the point I was trying to make is, I hope you all can trust me to set this up in a transparant way, making clear I don't have any ultimate authority once it's established.

---

As an aside, if we join the OpenJS Foundation (likely), they provide an escalation mechanisum should anyone feel the CoC review committee have not carried out their duty, which they (the foundation) then handle. I hope that aspect aleviates some potential concerns.

[jdesrosiers]

I hope you all can trust me to set this up in a transparant way

I do trust you, but I don't think that's the point. I'm glad you are leading this effort, but I would expect that this would all be discussed, agreed upon, and adopted by the whole core team. It's not just you setting this up, right?

if we join the OpenJS Foundation (likely), they provide an escalation mechanisum should anyone feel the CoC review committee have not carried out their duty

That's perfect.

[Relequestual]

I do trust you, but I don't think that's the point. I'm glad you are leading this effort, but I would expect that this would all be discussed, agreed upon, and adopted by the whole core team. It's not just you setting this up, right?

Yes. This is one of the reasons for this form of discussion. The impact is project wide.
Truthfully, we haven't even officially declared a core team or its members (and responsibilities).
That's probably another discussion though 😅.

[awwright]

I like the IETF process. Since it requires consensus, it implicitly requires mutual respect & understanding among its participants, and it is self-reinforcing in this way. By contrast, in other systems you can just steamroll over others, and a CoC is more easily manipulated, if not ignored. The Code of Conduct at the IETF is BCP 54.

I want to pick out a few key parts, but I'd up including the whole document. It's a good document.

[Relequestual]

I'm by no means suggesting we replace any part of our processes.
I very much like the IETF process of trying to attain general consensus, and I find once you run into potential problems, it does help keep moving forward.
A code of conduct is different to the contribution process, and they reside in different files (on github).

I believe we need to make a new discussion on creating a Contributing guide, which I supose will be at least partly filled in from wiki content.

I felt a CoC would be a good place to start.

[Relequestual]

Because of copyright, I'm not sure we are allowed to copy the whole document.
I'm going to highlight a few elements, and you can let me know if it seems enough to you.

[Relequestual]

Issue created: #26

[Relequestual]

There has been a discussion around keeping a log of activity related to the Code of Conduct (sorry, I forget where that discussion is, but I'll summarise).

We want to be as transparant as makes sense.
It was suggested that we could have a public log of CoC violation reports, and remedies.

I asked about how other projects handle similar things on the OpenJS Slack.

The node.js project have a private repo for "moderations" which includes CoC related issues.
The appropriate teams have access to this repo but must not share any deatils outside of it.
The moderation team reports on moderation activity which is logged in TSC meeting minutes, but this only extends as far as "reviewed item" or "warned user" with a link to the moderation repo issue.

It may make sense to do similar.
@jdesrosiers was it you who suggested we should have a public log?
I'm not opposed to having a public log of activities, but I'm not sure if you wanted parts of the report and remedies to be public also?

[jdesrosiers]

I just asked a facilitating question about what will be public record because the Contributor Covenant CoC was pretty light on details about that. I think it was you, @Relequestual, that suggested a public log. I only suggested that whatever policy we have is publicly documented. For example, if someone submits a report, they should know if it's going to become public record and what may or may not be redacted for privacy. I have no experience with this sort of thing and I don't even know what policy to suggest. Asking other projects what works for them (as you did with node.js) is probably the best way to figure that out.

[Relequestual]

OK, I missremembered then.
I agree.

node.js don't have a public log, and I think that makes the most sense.
I think we should keep a log in a moderation repo, but only for actual reports, as opposed to all moderation (node.js have a process of adding details to the repo for all moderation actions).

The log shouldn't be public, and only be accessible to the moderation and admin team. (This is likely to include people from OpenJS Foundation later, because they will need oversight for purposes of escalation.)

I'll add this to the issue.