Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mismatch between responsibility and ability #13

Open
DanHeidinga opened this issue Oct 7, 2021 · 5 comments
Open

Mismatch between responsibility and ability #13

DanHeidinga opened this issue Oct 7, 2021 · 5 comments

Comments

@DanHeidinga
Copy link

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
Copy link
Author

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

@waynebeaton
Copy link
Member

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
Copy link
Member

chrisguindon commented Jan 7, 2022

I would not expect a project to ban a community member without getting us involved via an email to codeofconduct@eclipse.org.

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
Copy link
Author

I would not expect a project to ban a community member without getting us involved via an email to codeofconduct@eclipse.org.

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
Copy link
Member

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

Send an email to codeofconduct@eclipse.org 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants