Conversation
| Our community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful. | ||
| Our community 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 these Guidelines, and will communicate reasons for moderation decisions when appropriate. |
There was a problem hiding this comment.
It should be clarified who these community leaders are --> Is it the BDFL + steering council?
There was a problem hiding this comment.
Not necessarily, e.g. if a problem happens in the mne-icalabel or mne-realtime repos?
There was a problem hiding this comment.
good point. and maybe we should clarify in mne-bids who is a "community leader" there ...
then perhaps we will need a more broad description, or require all mne-tools repos to explicitly list community leaders, and then link to those documents from the COC (that's my preferred solution)
There was a problem hiding this comment.
good point. and maybe we should clarify in mne-bids who is a "community leader" there ...
The above paragraph doesn't exclude the possibility of additional parties enforcing the community guidelines.
I would like us to avoid starting with micro-management for each sub-project / repository. I would say BDFL + steering council should be the ones ultimately responsible for enforcing the guidelines if any violations are brought to their attention. Sub-project / repository maintainers should be assumed to act in good faith, adhering to the community guidelines. But if they fail to do so, the BDFL and steering council always have the power to nix their (sub-project / repository maintainers') access rights, and seize control over the sub-project / repository. (I suppose I imagine something that's akin to a situation in the US where federal law is decided to override state law, and if a state doesn't obide, the National Guard is being sent in to enforce that federal law.)
That said … why don't we simply say that Community Leaders are sub-project / repository maintainers on the lowest level, and on the highest level there is BDFL + steering council, who can always override sub-project / repository maintainers' decisions? 🤔
There was a problem hiding this comment.
I would like us to avoid starting with micro-management for each sub-project / repository. I would say BDFL + steering council should be the ones ultimately responsible for enforcing the guidelines if any violations are brought to their attention. Sub-project / repository maintainers should be assumed to act in good faith, adhering to the community guidelines. But if they fail to do so, the BDFL and steering council always have the power to nix their (sub-project / repository maintainers') access rights, and seize control over the sub-project / repository.
I agree with this, also because in each of those sub-projects at least one steering council member is a "community leader"
There was a problem hiding this comment.
I think this is resolved by changes I just pushed. Both the CPG Response Leads and the "community leaders" are now defined
sappelhoff
left a comment
There was a problem hiding this comment.
great work overall, I really like it!
Apart from my inline comments I suggest to insert line breaks after each sentence and potentially after commas when there's a list. This is in order to make a future "diff" easier to read when these guidelines are amended.
britta-wstnr
left a comment
There was a problem hiding this comment.
Great work, @drammock ! Really glad to see this update.
Regarding your Enforcement Guidelines question:
I wonder if there is any instances where we would not want to take the actions outlined in the Contributor Covenant - what would be a reason to not follow the action outlined there?
I hear your worry about being inflexible, but I personally see the following benefits on having clear consequences spelled out:
- We make clear that we "mean it" - we are not just saying "these guidelines are great, if you violate them, we might take some action some time."
- Making consequences of violations clear can have positive effects on how safe people feel stepping into our community.
- It relieves the Leads from "coming up" with appropriate action and does not make them a possible target if action is taken, since they just follow agreed-upon rules.
Co-authored-by: Britta Westner <britta.wstnr@gmail.com> Co-authored-by: Mathieu Scheltienne <mathieu.scheltienne@gmail.com>
7d9eea6 to
65064f5
Compare
|
Note that I have not yet addressed @britta-wstnr's point, but intend to do so next week:
|
|
OK I've now added the enforcement guidelines section, I think this is ready for merge. I'll go ahead and push the green button, and if there are other things y'all want to see addressed here, we can always do another PR. Thanks everyone for the feedback! |
This PR does two things:
updates our code-of-conduct to frame it as Contributor Guidelines. The text borrows heavily from the Mozilla Contributor Guidelines (linked in the attribution section), while still incorporating much of the previous content drawn from the Contributor Covenant. Text that directly reflected the contributor covenant has been updated to match the most recent version (1.4 -> 2.1), except as mentioned below.
adds a
profile/README.mddocument that will display at the top of https://github.com/mne-tools/ (and will link to the guidelines). For an example of how this README will look, see https://github.com/microsoft/One major outstanding question I have is whether we should update the
Enforcement Responsibilitiessection to align with the current (v2.1) contributor covenant (in v2.1 of the covenant the section is now calledEnforcement Guidelines). That section has changed considerably since v1.4, and now includes four spelled-out levels of actions/consequences for violation of guidelines. I am as yet unsure whether we want to commit to those specific definitions of violation and the specific consequences that are paired to them. On one hand, it might simplify the "what should we do in response" question... on the other hand, maybe the right response wasn't foreseen and the document now requires us to respond in a suboptimal way. Keen to hear others' opinions on this, and also on any other aspect of the proposed changes.cc @mne-tools/mne-python-steering-committee
cc @mne-tools/mne-bids
cc @mne-tools/mne-icalabel-admins
cc @mne-tools/mne-realtime