Onboarding: Provide explicit feedback on what `escalation path` is and how to implement it + temporarily address in the Onboarding Checklist

[bnb]

Currently, this item is in the onboarding checklist:

Update project CoC reporting methods to include OpenJS Foundation escalation path

In investigating this for a currently incubating project, I've personally found it excessively difficult both to fully understand what the escalation path actually is since it seems to currently be not explicitly defined and have not found any official guidance on what implementing this for a project means - both in the sense of what kind of things a project can expect if the escalation path is used and what that path even looks like.

For context, one assertion that was made to me was that CoC violations in given projects can be escalated through this path and reviewed by the body they're escalated to - this is extremely concerning to me given the possibility of the escalation resulting in a turnover and a project being forced to allow someone to continue participating. This is an extremely concerning prospect, as it puts project membership in danger and it creates an extremely toxic power dynamic both between project members and the violator and between the OpenJS CPC group and projects.

Given the above concerns, I'd also like to recommend that we either temporarily address this for onboarding projects by either striking it from the onboarding checklist until the CoC WG can provide a more explicit checklist item that's well documented, defined, and positive for the projects or provide official temporary guidance to projects that are going through the onboarding process on how to address this point with absolute guarantees about how their community safety structures will not be overturned.

[mhdawson]

This is the doc https://github.com/openjs-foundation/cross-project-council/blob/master/CODE_OF_CONDUCT.md#escalation for escalation.

I do see the link was broken when files were moved to the CoC repo. This is the section which describes escalation in more detail: https://github.com/openjs-foundation/cross-project-council/blob/master/FOUNDATION_CODE_OF_CONDUCT_REQUIREMENTS.md#escalation

[mhdawson]

Given the documentation above I don't quite understand actually is since it seems to currently be not explicitly defined and have not found any official guidance on what implementing this for a project means - both in the sense of what kind of things a project can expect if the escalation path is used and what that path even looks like.

Can you list out what needs to be documented?

The concern about having an escalation path is a separate discussion. This came about because of the complaints in the past that there was no escalation path once a decision had been made by the project. In that case the argument was that it was needed to protect contributors.

If the Foundation has a stake in ensuring CoC's are enforced across the Foundation members then there needs to be a path for escalation to the Foundation. In this case (hopefully rare), there can be disagreement between the Foundation's opinion and a project, in which case the two would need to work through how to close that gap or in the worst case the project leaving the Foundation.

The alternate approach is to say that the Foundation's role is advisory/supporting only and that the Foundation will not get involved if there is a disagreement over how a CoC report was handled by a project. In that case any complaints directed to the Foundation should simply be re-directed to the project (if you are not going to do that, then you need an escalation path).

[mhdawson]

One more approach is that the Foundation would only get involved on "request" from a project. In that case it would still really be in the "advisory/support" role so there would be no escalation path from the reporter, instead there would be a process for a project asking for help.

[bnb]

Can you list out what needs to be documented?

In my own looking and talking with Foundation staff, I was not able to locate this documentation. What I was looking for does seem to exist, and is completely different than how it was described to me. Without and documentation I was unable to have a concrete foundation to understand that 😅

There does seem to be some knowledge that you have that does not come across in the document. Specifically,

This came about because of the complaints in the past that there was no escalation path once a decision had been made by the project. In that case the argument was that it was needed to protect contributors.

How is this meaningfully addressed in the current setup?

If the Foundation has a stake in ensuring CoC's are enforced across the Foundation members then there needs to be a path for escalation to the Foundation.

I’m not entirely sure what this means, but I think I get the idea. This idea is rather ominous and undefined - I understand the concept but the implications are uncertain. It also does not come across explicitly in the aforementioned documents to me.

In this case (hopefully rare), there can be disagreement between the Foundation's opinion and a project, in which case the two would need to work through how to close that gap or in the worst case the project leaving the Foundation.

This is an extremely strong power dynamic between the Foundation and projects that should be excessively defined in a way it is currently not at all... at least not in the aforementioned documentation. I would honestly argue that we should likely pause the onboarding checklist item as a requirement until this is well defined.

The alternate approach is to say that the Foundation's role is advisory/supporting only and that the Foundation will not get involved if there is a disagreement over how a CoC report was handled by a project. In that case any complaints directed to the Foundation should simply be re-directed to the project (if you are not going to do that, then you need an escalation path).

Is this an alternative currently available to projects or an alternate proposal for how this would be handled?

[mhdawson]

How is this meaningfully addressed in the current setup?
It's addressed by having an escalation path, and a defined makeup of the CoCP panel who were intended to be individuals who could be trusted to handle escalations.

Is this an alternative currently available to projects or an alternate proposal for how this would be handled?

I was trying to outline different ways that the the Foundation/CPC could choose to operate, particularly if an escalation path is not in place. As currently written there is an escalation path and it is not optional but the CPC can choose to change that.

[mhdawson]

@bnb I suggest you bring this up at the next CPC meeting. Despite the review/discussion of the documents during the proposal process it seems there is still a lot of confusion.

Fundamentally it comes down to whether the Foundation has any requirement on projects with respect to the CoC beyond having one. (for example, what happens if a project has one as required, but completely ignores or just rejects all reports).