Add Eclipse suggested CODE_OF_CONDUCT.md

[pshipton]

Eclipse recommends to have this file as per the yearly release review. https://gitlab.eclipse.org/eclipsefdn/emo-team/emo/-/issues/106

Copied the file from https://github.com/eclipse/.github/blob/master/CODE_OF_CONDUCT.md

[DanHeidinga]

Looks reasonable to me and I would expect that we're already operating in this fashion.

I'm unclear on the responsibilities in:

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 this is straightforward but as we've never had to go down the ban temporarily or permanently any contributor path, I have no idea if we have the capabilities to actually do that. I'm hesitant to sign up to responsibility until we're clear we can actually take the required action.

Does anyone know if there is a way to ban a contributor from github? (...goes off to search....)

[DanHeidinga]

Does anyone know if there is a way to ban a contributor from github? (...goes off to search....)

Only Organization owners can block a user [1] on github so we can't actually enforce the responsibility we're taking on here. This might need some slight rewording to state that the Foundation will..... or they'll need to grant us further permissions on the org.

[1] https://docs.github.com/en/communities/maintaining-your-safety-on-github/blocking-a-user-from-your-organization

[mstoodle]

We can, as project leads (actually I think even committers might be able to do it), make a case to have a committer "de-committer"ed and we, as a project, can refuse to accept further contributions from them. I suspect that's as far as we can go.

By the way, since this affects every committer we should probably have everyone explicitly agree to it (and have any subsequent new committers also agree to it).

[DanHeidinga]

I hate promising actions I can't take ie: "to ban temporarily or permanently any contributor for....". I'm less worried about committers and more concerned about with if we ever have to deal with a trolls =)

I'm pushing on this a bit because I think the Foundation - who provided this doc - should either grant the rights necessary to meet the obligation they are asking us to take on, or reword it so it's clear they are responsible for bans.

[keithc-ca]

It says 'with the support of the Eclipse Foundation staff': does that ease concerns about the ability to act?

[DanHeidinga]

It says 'with the support of the Eclipse Foundation staff': does that ease concerns about the ability to act?

That's the first paragraph. The second paragraph further specifies just "Project committers and leaders have the right and responsibility" so I think my concern remains.

[mstoodle]

Note we already mention the code of conduct in our README, and although we don't explicitly state that the project follows it, it is implied. Under the "How do I contribute?" section: Since we are an Eclipse Foundation project, each contributor needs to sign an Eclipse Contributor Agreement. The Eclipse Foundation operates under the Eclipse Code of Conduct to promote fairness, openness, and inclusion.

How about we take a committer vote, and in that issue, Dan can propose some words to scope the ban requirement to something we can more comfortably commit to? As in, we commit to follow this code with the following understanding...

[mstoodle]

I think that readme quote has been there from very early on. OMR has a similar kind of statement though more explicit: "We operate under the Eclipse Code of Conduct to promote fairness, openness, and inclusion."

[pshipton]

Note adding this file is not required. It was recommended. We've since passed the (yearly) review, so it could be put off for another year. Although I have no objection to Mark's proposal, or Dan's suggestion to modify the wording. I've pushed a change to modify the wording.

[DanHeidinga]

Thanks for pushing the updating wording @pshipton. That clarifies the responsibility. It's probably worth raising this concern in the release review so the Foundation has an opportunity to address this.

How about we take a committer vote, ...

@mstoodle my understanding is this is akin to repatriating the code of conduct directly into our repo rather than a new requirement. I'm not 100% clear on what we'd be voting on.

[mstoodle]

Well, either it's not a change (in which case you shouldn't be concerned with the implications of its wording and we shouldn't be changing the words :) ) or it is a change (which your concern suggests and Peter's explicit modification makes pretty clear). We're having this discussion in a pull request that adds an explicit code of conduct into the project that was not held in the project before...

To my mind, if there's a change in this space, we shouldn't just unilaterally assume all the committers are in agreement with and therefore committed to executing that code of conduct. It shouldn't be forced upon them by the subset who have taken the time to review and comment on this particular pull request. Everyone is supposed to be bound by the code of conduct, so everyone should explicitly agree to be bound.

We don't really need a vote, per se, but it would be one way for us to verify that all the committers agree with this code of conduct. Maybe a better way to do it would be to require every committer on the project to mark their approval of this pull request before anyone merges it (or to raise any concerns as comments for us to discuss). Does that sound reasonable?

[keithc-ca]

require every committer on the project to mark their approval of this pull request

I think that's a good plan.

[pshipton]

It's probably worth raising this concern in the release review so the Foundation has an opportunity to address this.

This is done.

[DanHeidinga]

We don't really need a vote, per se, but it would be one way for us to verify that all the committers agree with this code of conduct. Maybe a better way to do it would be to require every committer on the project to mark their approval of this pull request before anyone merges it (or to raise any concerns as comments for us to discuss). Does that sound reasonable?

That works for me.

[waynebeaton]

I'm grateful that you're thinking this through, but you may be overthinking a bit.

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.

This doesn't state that anybody in particular has to click the buttons. In exercising this responsibility, your course of action might be to contact the [email protected] or EMO for assistance.

My preference is that we not start creating minor variations of the code of conduct unless absolutely necessary. If you feel that this addition is required, please open an issue.

You can assume that we've got your back.

[pshipton]

I've restored the original version.

[DanHeidinga]

My preference is that we not start creating minor variations of the code of conduct unless absolutely necessary. If you feel that this addition is required, please open an issue.

Done https://github.com/eclipse/.github/issues/13

[pshipton]

@DanHeidinga given https://github.com/eclipse-openj9/openj9/pull/13637#issuecomment-937857381 and the lack of response to https://github.com/eclipse/.github/issues/13, are you willing to accept the code of conduct as-is? If so we can start making sure all the other committers are aware of this and see about merging it.

[DanHeidinga]

I've pinged Wayne on eclipse/.github#13 and expect we'll get an answer in the next week or two

[waynebeaton]

Sorry, I don't monitor that repository's inbox.

As I stated previously, my preference is that we not start creating minor variations of the code of conduct unless absolutely necessary. I don't see why a change would be necessary in this case.

[pshipton]

@DanHeidinga are you still going to block this due to the wording, which Eclipse doesn't see the need to change, or can we proceed trying to get all committers to approve? It's time for our yearly release review and it's recommended to have the code of conduct file.

[DanHeidinga]

I continue to be unimpressed by the Foundation's response to the issue of responsibility without authority (and no their proposed "mother may I" model doesn't cut it). Unfortunately, they don't seem to be in any rush to resolve the issue.

That said, I don't see anything in the code of conduct that we aren't already trying to live out in the project and I don't want to have this wait around.

Let's proceed.

[keithc-ca]

I suppose if this file doesn't need a copyright header, we should add it to the .copyrightignore file.

We could, but I would hope this file doesn't change much; it may be easier for committers to just ignore the copyright checker for those few times it does change.

[pshipton]

@fjeremic @jduimovich @charliegracie @pmhayward if you want to sign off on this, if you ever plan to participate as an OpenJ9 committer again.

[doveye]

Pretty sure pmhayward has no plans to contribute in the future

[pshipton]

@DanHeidinga all the regular committers have approved. There are some inactive committers who haven't responded (yet). Can this be merged now?

[DanHeidinga]

@DanHeidinga all the regular committers have approved. There are some inactive committers who haven't responded (yet). Can this be merged now?

I'm good with merging at this point.