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

ENH code of conduct sub-team #1745

Closed
wants to merge 18 commits into from
Closed

ENH code of conduct sub-team #1745

wants to merge 18 commits into from

Conversation

beckermr
Copy link
Member

@conda-forge/core I have finished the CoC sub-team charter. Comments are welcome. I will call a vote once it appears we have a consensus.

@beckermr beckermr requested a review from a team as a code owner April 28, 2022 13:17
Comment on lines 50 to 55
- Matthew R. Becker <[email protected]>
- Chris Burr <[email protected]>
- Matt Craig <[email protected]>
- Jannis Leidel <[email protected]>
- Jaime Rodríguez-Guerra <[email protected]>
- Marcelo Duarte Trevisani <[email protected]>
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If anyone here does not want to be on this list, LMK. I grabbed the folks in the CoC channel.

@beckermr beckermr changed the title ENH code of conduct subteam ENH code of conduct sub-team Apr 28, 2022
@beckermr beckermr marked this pull request as draft April 28, 2022 13:19
I handled 2 out of 3 incidents we had so I guess I have some experience with CoC in conda-forge ;-p
src/orga/subteams.rst Outdated Show resolved Hide resolved
src/orga/subteams.rst Outdated Show resolved Hide resolved
@mwcraig
Copy link
Contributor

mwcraig commented Apr 28, 2022

Looks good to me -- thanks for putting this together

src/orga/subteams.rst Outdated Show resolved Hide resolved
src/orga/subteams.rst Outdated Show resolved Hide resolved

- It can only be comprised of ``core`` members.
- Any ``core`` member is welcome to participate.
- ``core`` members involved in CoC reports will use their best judgment to recuse
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this clause could be a bit more prescriptive. If a core member is implicated in a CoC violation, they shouldn't be part of the body that votes on it.

will report them as appropriate to the wider core group promptly.
- The CoC team will maintain secured reporting channels for potential CoC violations.
- The CoC team may temporarily remove maintainers for a period of up to one month
from feedstocks through the "yes" vote of at least three CoC team members and no "no" votes.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this dependent on the number of CoC team members? (eg if the group member ship drops below three, is this no longer actionable?)

will report them as appropriate to the wider core group promptly.
- The CoC team will maintain secured reporting channels for potential CoC violations.
- The CoC team may temporarily remove maintainers for a period of up to one month
from feedstocks through the "yes" vote of at least three CoC team members and no "no" votes.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The use of feedstocks here may be too specific, we have folks that maintain other pieces of the conda-forge infrastructure.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also I'm not certain how we want to cover violations in other media (eg gitter). Also this only covers maintainers, but there are certainly other members of the community that could violate the CoC. For instance, a GH user who isn't a maintainer harasses a maintainer for not accepting their changes. Or a gitter user (also not a maintainer) violates the CoC.

Do we provide a blanket ban from all standard communication channels? In it's current draft (9406dab) this is a feedstock by feedstock ban. This formally would allow the perpetrator to continue their behavior in other forums.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we do the best we can on any forum where a core dev has the power to block people. Idk exactly what those powers are at the moment but I don't see what else we can do.

- Any member of the CoC team may call a vote by the wider ``core`` team to ban a user from
``conda-forge``. This vote falls under the rules of votes to ban users in the ``conda-forge``
governance charter.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We may need some specialty rules for governing this sub-team. For instance removal of members from the team. To the best of my knowledge we don't have rules for removal from sub-teams (mostly because those teams are self-governing). That might not fit well here. My understanding of the current governance document is the only way to remove a person is to dissolve the team and reform it, which might be a bunch of fancy footwork.

We might also consider that any CoC member found violating the CoC will be removed from the sub-team, or something to that effect.

conda-forge CoC. The ``conda-forge`` CoC is subject to change by the wider ``core`` group.
- The team may seek guidance from NumFocus and the wider ``core`` group as needed.
- Due to the potentially sensitive nature of CoC violations, the CoC team will
strive to preserve the confidentiality of involved persons as much as possible.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We may need to be more prescriptive here as well. For instance, how much information is held back from core more generally? In which situations could information be released and to whom?

Co-authored-by: Christopher J. 'CJ' Wright <[email protected]>
- Any member of the CoC team may call a vote by the wider ``core`` team to ban a user from
``conda-forge``. This vote falls under the rules of votes to ban users in the ``conda-forge``
governance charter.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we have a secondary document on CoC procedures? (ie. a report concerning a potential violation comes in, what happens next?)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like what conda-incubator did with the NF CoC. They adapted it and provided community-specific details that might work for us too.

@beckermr
Copy link
Member Author

Thanks for the comments @CJ-Wright! Can you take a pass at editing this?

I'm not sure I'll be able to capture what you are looking for efficiently.

src/orga/subteams.rst Outdated Show resolved Hide resolved
Co-authored-by: Christopher J. 'CJ' Wright <[email protected]>
@beckermr
Copy link
Member Author

beckermr commented Jun 9, 2022

@CJ-Wright Did you get a chance to put in your edits here?

@jaimergp
Copy link
Member

It's long due we have this explicitly written somewhere, so I'd be inclined to bring this up in the next core call.

Also related to #1640

The code-of-conduct (CoC) sub-team is responsible for accepting, handling
and resolving code-of-conduct related items (including but not limited to
CoC violations, enforcement, communications, warnings, etc.) on conda-forge's
communication channels (including but not limited to Gitter, GitHub, Keybase, the various
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably mention Element here too.

Copy link
Member Author

@beckermr beckermr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is ready for a vote IMHO.

@jaimergp
Copy link
Member

As per our governance, this should be a standard vote (public), with 50% majority pass and normal quorum (or time out) rules. If that's correct, that means we can just call it here via PR votes, right?

@beckermr
Copy link
Member Author

Yep!

@jaimergp
Copy link
Member

@conda-forge/core:

  • This vote falls under the "Sub-team Formation" policy, please vote and/or comment on this issue.
  • This vote needs 50% of core to vote yea to pass.
  • To vote please review this PR with: "Approve" (yes) or "Request changes" (no).
  • If you would like changes to the current language please leave a comment.
  • This vote will end on July 27th 2023 at 23:59 AoE.

@beckermr
Copy link
Member Author

I cannot approve my own PR but put me down for "yes!"

@jaimergp jaimergp marked this pull request as ready for review July 11, 2023 14:26
@jaimergp jaimergp requested a review from a team July 11, 2023 14:27
jaimergp
jaimergp previously approved these changes Jul 11, 2023
Copy link
Member

@jaimergp jaimergp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We just need to note down the email address where we will be attending reports.

mwcraig
mwcraig previously approved these changes Jul 11, 2023
ocefpaf
ocefpaf previously approved these changes Jul 11, 2023
ericdill
ericdill previously approved these changes Jul 11, 2023
chrisburr
chrisburr previously approved these changes Jul 11, 2023
- Requiring that the person avoid any interaction with, and physical proximity to, the person they are harassing for the remainder of the event
- Ending a talk that violates the policy early
- Not publishing the video or slides of a talk that violated the policy
- Not allowing a speaker who violated the policy to give (further) talks at the event now or in the future
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tiny nitpick, but the "or in the future" clause here seems to conflict with the statement above that "[the] scope of any rapid decision is limited to the current event / situation"

pkgw
pkgw previously approved these changes Jul 11, 2023
wolfv
wolfv previously approved these changes Jul 12, 2023
h-vetinari
h-vetinari previously approved these changes Jul 12, 2023
Copy link
Member

@h-vetinari h-vetinari left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about the various "To be defined" here? Is there a timeline for those? Isn't the incident form & email necessary for the CoC to actually go into effect?

I was also wondering about how the "responsibility to remove commits" squares with our other stewardship responsibilities, and whether we should clarify the circumstances/severity around that (see below).

In any case, none of these are hard blockers, so I'm happy to approve nevertheless.

- Publishing an account of the harassment and calling for the resignation of the alleged harasser from their responsibilities (usually pursued by people without formal authority: may be called for if the person is the event leader, or refuses to stand aside from the conflict of interest, or similar)
- Any other response that the CoC Committee deems necessary and appropriate to the situation

No one espousing views or values contrary to the standards of our code of conduct will be permitted to hold any position representing the conda-forge Organization, including volunteer positions. The CoC Committee has the right and responsibility to remove, edit, or reject comments, commits, code, website edits, issues, and other contributions that are not aligned with this code of conduct.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if people consider this worth specifying, but removing merged commits is highly disruptive, especially as this affects the traceability of packages have been built on these. I'm not saying we should rule this out, but following the CoC to the letter here says "Committee has the responsibility to remove commits that are not aligned with CoC".

I think such removals should have to meet a higher bar than "in scope under the strictest interpretation of the CoC". For example, if someone finds a swearword in an old commit message somewhere, that would IMO not be sufficient to justify force-rewriting the history of that feedstock.

@jaimergp jaimergp marked this pull request as draft July 12, 2023 17:53
@jaimergp
Copy link
Member

Hey folks, we are going to cancel this vote temporarily (we will issue a new one soon), after receiving very important feedback in today's core call. We'll include some changes and then ask for comments; hopefully after that we can start a new vote. Thank you for understanding and sorry for the noise!

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

Successfully merging this pull request may close these issues.