Mismatch between responsibility and ability

[DanHeidinga]

While updating the OpenJ9 project to include the Code of Conduct [1], it was noted that there are several responsibilities that project committers and leaders are committing to undertake:

Project committers and leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.

Most of these are straightforward and easy to do given the existing permission model on github. There are two responsibilities that are at a mismatch to the abilities that committers and leaders have due to github permissions. As far as I can tell, we don't have the ability to ban temporarily or permanently any contributor .

Ideally, bans would never be required but in a situation where they are needed, being able to take action quickly (ie: due to a pile on from outside parties) is important. Waiting for a response from the Foundation - who may be offline at that time - may allow an issue to grow.

And personally, I hate signing on for responsibilities that I can't actually take action on.

Would it be possible to extend the github permissions granted to the committers / leads to allow a project to directly take action in cases where bans are required?

Alternatively, there was a proposal to change the wording to show that action is depending on Foundation staff:

Project committers and leaders have the right and responsibility, with the support of the Eclipse Foundation staff, to remove, edit, or

[1] eclipse-openj9/openj9#13637

[DanHeidinga]

@waynebeaton Any response to this request? It's delaying OpenJ9 from updating the code of conduct

[waynebeaton]

Support of the Eclipse Foundation staff is implied. The wording of the policy itself is independent of the specific actions required to implement the policy. Specifically, we can reasonably interpret the responsibilities to be that the project committers and leaders contact the Eclipse Foundation to request assistance without changing the policy itself.

Having said that, @chrisguindon is the expert regarding permissions that we have the ability to grant on specific platforms.

[chrisguindon]

I would not expect a project to ban a community member without getting us involved via an email to [email protected].

We can grant the necessary permissions if needed.

Alternatively, there was a proposal to change the wording to show that action is depending on Foundation staff:

Project committers and leaders have the right and responsibility, with the support of the Eclipse Foundation staff, to remove, edit, or

I've been involved in updating our code of conduct in the past. It usually starts with someone making a proposal via a PR to this repo: https://github.com/eclipse/.github

Once that's created, I can get the necessary people involved to discuss the change.

With this said, I agree with everything that Wayne wrote.

[DanHeidinga]

I would not expect a project to ban a community member without getting us involved via an email to [email protected].

Do you have more detail on what this process would look like? Having never gone through one of these processes for our project (and hopefully won't ever need to) I'm a little confused about how this would look in practice as I'd expect the committers / leads to have to make time sensitive decisions in these situations based on seeing the brigading that's happened in other communities.

As some background, I spend a lot of time reviewing technology specifications that I'll need to implement so I have a lot of hesitation to signing on to a policy where the intended practice is different than what the policy says. If there's a corresponding "in practice, this is what's expected" process document (workflow?), that might clarify this.

And for the record, I have no issue with policy, just the practicality of taking action under it in a timely fashion.

[waynebeaton]

Do you have more detail on what this process would look like?

Send an email to [email protected] with a description of the problem.

... I have a lot of hesitation to signing on to a policy where the intended practice is different than what the policy says.

The policy states nothing about specific practices on specific platforms or technologies. In cases where you do not have the necessary privileges to effect necessary changes directly yourself, you can initiate mitigation indirectly by contacting the EF at the listed email address.