-
-
Notifications
You must be signed in to change notification settings - Fork 274
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
Conversation
src/orga/subteams.rst
Outdated
- 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]> |
There was a problem hiding this comment.
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.
I handled 2 out of 3 incidents we had so I guess I have some experience with CoC in conda-forge ;-p
Looks good to me -- thanks for putting this together |
src/orga/subteams.rst
Outdated
|
||
- 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 |
There was a problem hiding this comment.
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.
src/orga/subteams.rst
Outdated
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. |
There was a problem hiding this comment.
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?)
src/orga/subteams.rst
Outdated
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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. | ||
|
There was a problem hiding this comment.
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.
src/orga/subteams.rst
Outdated
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. |
There was a problem hiding this comment.
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. | ||
|
There was a problem hiding this comment.
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?)
There was a problem hiding this comment.
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.
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. |
Co-authored-by: Christopher J. 'CJ' Wright <[email protected]>
@CJ-Wright Did you get a chance to put in your edits here? |
src/orga/subteams.rst
Outdated
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
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? |
Yep! |
@conda-forge/core:
|
I cannot approve my own PR but put me down for "yes!" |
There was a problem hiding this 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.
- 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 |
There was a problem hiding this comment.
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"
There was a problem hiding this 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. |
There was a problem hiding this comment.
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.
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! |
@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.