ENH code of conduct sub-team #1745
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2,6 +2,62 @@ A list of current sub-teams | |
| *************************** | ||
|
|
||
|
|
||
| Code of Conduct Sub-Team | ||
| ============================= | ||
|
|
||
| Role | ||
| ---- | ||
| 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 | ||
| mailing lists, etc). | ||
beckermr marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| Charter | ||
| ------- | ||
| Static | ||
|
|
||
| Responsibility | ||
| -------------- | ||
| The CoC sub-team will operate via the following rules: | ||
|
|
||
| - It can only be comprised of ``core`` members. | ||
|
There was a problem hiding this comment. The conda-incubator CoC team does not have an equivalent clause and, more specifically, they explicitly mention an external consultant when difficult situations arise. See https://github.com/conda-incubator/governance/blob/main/CODE_OF_CONDUCT.md#ombudsperson. It might be useful for us too. |
||
| - Any ``core`` member is welcome to participate. | ||
beckermr marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - ``core`` members involved in CoC reports will use their best judgment to recuse | ||
|
There was a problem hiding this comment. 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. |
||
| themselves in cases where there may be or even appear to be a conflict of interest. | ||
| - The CoC team will judge CoC-related issues according to the current official | ||
| 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. 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? |
||
| - The CoC team may issue warnings through e-mail, gitter, github etc. in order to | ||
| prevent situations from escalating. | ||
| - The CoC team will maintain records of CoC reports, the CoCs findings in each case, and | ||
| 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. Is this dependent on the number of CoC team members? (eg if the group member ship drops below three, is this no longer actionable?) There was a problem hiding this comment. 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. 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. 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. |
||
| Documentation of the CoC violations, the specific user in question, and the specific feedstocks | ||
| must be given at the vote and maintained. After one month, the user may petition the CoC team | ||
| to restore their access to the feedstock. The CoC team will vote on this petition under the same | ||
| rules. If the the petition is accepted, the user's access is restored. If the petition is rejected, | ||
| the user is permanently removed from the feedstock. Excessive, repeated petitions are not acceptable | ||
beckermr marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| and will be handled as a potential CoC violation. | ||
| - 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. 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. There was a problem hiding this comment. 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. I like what conda-incubator did with the NF CoC. They adapted it and provided community-specific details that might work for us too. |
||
| Members | ||
| ------- | ||
| - 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. If anyone here does not want to be on this list, LMK. I grabbed the folks in the CoC channel. |
||
| - Filipe Fernandes <[email protected]> | ||
|
|
||
beckermr marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| Security and Systems Sub-Team | ||
| ============================= | ||
|
|
||
|
|
||
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.