Add process for handling reports #271
Conversation
Reports made to report@openjsf.org will follow this process once ratified.
There was a problem hiding this comment.
I like the direction this is taking. Added some concerns, with some overlap with the "Further questions" section. Given that this isn't a clear-cut thing, should it go through the staging process? I mean, it's at least Stage 1, but I'm not sure it's really more than that yet.
HANDLING-REPORTS.md
Outdated
| 2. The right people are alerted: See Roles. | ||
| 3. Contact person assigned: See Roles. | ||
| 4. Report is acknowledged: The contact person responds to let the reportee know that the report is being discussed. | ||
| 5. Facts are gathered: Time is allocated to collect information in one place to make sure everyone involved has access. |
There was a problem hiding this comment.
Are dissenting views and opinions "facts"? In other words, is there a possibility here to get opinionated input from other parties involved in the subject of the report? Or is purely factual input the only sort allowed at this step?
There was a problem hiding this comment.
I'm of the opinion that facts are the cornerstone of rendering sound decisions. But as humans are involved and CoCs can involve subjective experiences, I'd be +1 to adding explicit mention of opinions.
HANDLING-REPORTS.md
Outdated
| 6. Facts are discussed: The facts are discussed in context. Also see What to look forward to for guidelines on appropriate response. | ||
| 7. An action to be taken is arrived at: The action to be taken is decided by consensus. | ||
| 8. Resolution offered: The resolution is offered to the reportee by the contact person. The reportee needs to accept the resolution for the matter to be resolved. If they don’t accept, go back to step 5. If there isn't a clear way to resolve the report, the report can be reviewed by the moderation team representatives from OpenJS projects to ensure that the the action and resolution are appropriate. | ||
| The report is resolved: The report is resolved when the reportee accepts the action. |
There was a problem hiding this comment.
Could a report also be closed due to non-communication on behalf of the original reporter? Or if the review of step 8 indicates that all that can be done has been done? Always requiring final approval from a reporter opens up the process to some level of theoretical abuse by spamming us with reports that can't be closed.
There was a problem hiding this comment.
Well spotted. Language added to address this.
HANDLING-REPORTS.md
Outdated
| 4. Report is acknowledged: The contact person responds to let the reportee know that the report is being discussed. | ||
| 5. Facts are gathered: Time is allocated to collect information in one place to make sure everyone involved has access. | ||
| 6. Facts are discussed: The facts are discussed in context. Also see What to look forward to for guidelines on appropriate response. | ||
| 7. An action to be taken is arrived at: The action to be taken is decided by consensus. |
There was a problem hiding this comment.
Who can/should participate in this consensus? Everyone in the CPC, along with e.g. observers who are "free to attend meetings and participate in the work of the CPC as well as the consensus seeking process"? Or is this a decision of some smaller committee? And how about CPC members that may be closely affected by the report, are they expected to participate, or to recuse themselves?
There was a problem hiding this comment.
Punting handling of the consensus process to other sections.
There was a problem hiding this comment.
@keywordnew I think the discussion in the CPC meeting last week was to move all of this into https://github.com/openjs-foundation/cross-project-council/tree/master/proposals/stage-1/CODE_OF_CONDUCT. I'm just asking since there is still discussion here.
There was a problem hiding this comment.
@mhdawson After that discussion, this PR was modified to add this HANDLING-REPORTS.md document to https://github.com/openjs-foundation/cross-project-council/tree/master/proposals/stage-1/CODE_OF_CONDUCT.
Sorry if I misunderstood. How can I correct it?
| * the reportee accepts the action. | ||
| * there is no communication for 21 days on behalf of the original reporter. | ||
| * the Ombudsperson decides that the resolution as it stands is the best possible outcome within the constraints of all involved. | ||
| ## Roles |
There was a problem hiding this comment.
Would this section be an appropriate place to also define "reporter" and "reportee". I realise now that I'd missed earlier the rather significant difference between them.
There was a problem hiding this comment.
This is an excellent opportunity to clarify language.
I had used the word "reportee" to refer to the person/s against whom a violation was committed.
I used the word "reporter" when the person who made the report is not the same as the person against whom the violation was committed.
When we clarify, I can go in and change to make the language consistent, it may not be.
We also need a word to refer to the person/s who committed the violation.
HANDLING-REPORTS.md
Outdated
| * We can use groups.io | ||
| * Form: It would be easier on the reportee to have a form template to help them structure their report. The form submission could trigger an email | ||
| * Repo: openjs/moderation (not provisioned) | ||
| * A form submission could open an issue in the repo, to allow folks to discuss in context |
There was a problem hiding this comment.
I think opening an issue in the public is the worst possible way to report, could we remove the repo as a channel for reporting?
There was a problem hiding this comment.
The comment made me think of the downside of discussing a report in the repo. There is an ask to look into any legal issues of having personal details on a Github repo.
To clarify, the moderation repo would be private. Likely with only the CPC having access. Much like the nodejs/moderation repo. Is there concern with having a reporting form create an issue in this private repo?
HANDLING-REPORTS.md
Outdated
| 8. Resolution offered: The resolution is offered to the reportee by the contact person. The reportee needs to accept the resolution for the matter to be resolved. If they don’t accept, go back to step 5. If there isn't a clear way to resolve the report, the report can be reviewed by the moderation team representatives from OpenJS projects to ensure that the the action and resolution are appropriate. | ||
| The report is resolved: The report is resolved when the reportee accepts the action. | ||
| ## Roles | ||
| * Moderation team representatives: Each project in the CPC which has a moderation team should have representation here. https://github.com/openjs-foundation can ask these folks if any are willing to also moderate this org. |
There was a problem hiding this comment.
I think this should be a responsibility delegated by the CPC. Especially in the case of project escalation, the CPC should/must get involved. In the most sensitive case, this might even be limited to voting members only.
There was a problem hiding this comment.
+1 to this. I'm adding a line explicitly adding the CPC.
| 4. Report is acknowledged: The contact person responds to let the reportee know that the report is being discussed. | ||
| 5. Facts and opinions are gathered: Time is allocated to collect information in one place to make sure everyone involved has access. | ||
| 6. Facts are discussed: The facts are discussed in context of opinions. Also see **What to look forward to** for guidelines on appropriate response. | ||
| 7. An action to be taken is arrived at: The action to be taken is decided by consensus (see section on Consensus process) involving the roles listed in the next section. |
There was a problem hiding this comment.
section on Consensus process
Can we link to the section?
| ## Roles | ||
| * CPC: The Cross Project Council must get involved in cases where a report has been escalated by a project or its team reponsible for enforcing their Code of Conduct. (TBD: role of regular and voting members) | ||
| * Moderation team representatives: Each project in the CPC which has a moderation team should have representation here. https://github.com/openjs-foundation can ask these folks if any are willing to also moderate this org. | ||
| * Ombudsperson: This person acts as an impartial intermediary between a reporter and the Foundation. They also serve to mediate between the moderation team representatives. |
There was a problem hiding this comment.
Will there be any particular rule to decide on who will be this person? Like they cannot be from the same project, just to avoid any conflict of interest.
There was a problem hiding this comment.
That's a good issue to raise. We should clarify. For example, my own opinion is that this person should currently not be directly involved with a specific project (OpenJS Foundation is fine), but past history is ok.
|
This fills in the process, but it still seems a bit disjoint from the text in https://github.com/openjs-foundation/cross-project-council/blob/master/proposals/stage-1/CODE_OF_CONDUCT/FOUNDATION_CODE_OF_CONDUCT_REQUIREMENTS.md In particular it does not reference the Code of Conduct Panel (CoCp): I think it should either incorporate references to the CoCP or include commits that change the wording in FOUNDATION_CODE_OF_CONDUCT_REQUIREMENTS.md so that the 2 are consistent. |
There was a problem hiding this comment.
It would be good to see a README included in this proposal. It seems like there are a handful of bits included in the proposed document that better live in the read. Please refer to https://github.com/openjs-foundation/cross-project-council/blob/master/proposals/TEMPLATE.md as a template to fill out
I've left a number of comments inline. I'm not 100% sure I support the proposed process, would like to talk through some of the decisions, especially about how things are settled.
| ## Channels | ||
| * Email: report@openjsf.org. | ||
| * Form: It would be easier on the reportee to have a form template to help them structure their report. The form submission could trigger an email. | ||
| * Repo: openjs/moderation (not provisioned). As commented in PR review, hosting sensitive personal information on GitHub needs due consideration, review, and possibly legal consultation. |
There was a problem hiding this comment.
similar to above. This document should outline the actual process rather than questions about process.
Also, is this document for project maintainers or external individuals? That would likely change the process a bit.
There was a problem hiding this comment.
This document was written initially for project maintainers.
Removing content to README.md. Thanks for calling out.
| * Repo: openjs/moderation (not provisioned). As commented in PR review, hosting sensitive personal information on GitHub needs due consideration, review, and possibly legal consultation. | ||
| * A form submission could open an issue in the repo, to allow folks to discuss in context. | ||
| ## Confidentiality and record-keeping | ||
| Everything reported and discussed is confidential unless explicitly stated. For any facts to be made public, the reportee’s explicit permission is needed. All reports should be recorded, together with the discussion of it. A private moderation repo would satisfy the need for recordkeeping. |
There was a problem hiding this comment.
For any facts to be made public, the reportee’s explicit permission is needed.
Are we sure we want to commit to this? If we want to make even anonymized summaries of reports / actions taken that will not be possible with the current reading.
| ## Confidentiality and record-keeping | ||
| Everything reported and discussed is confidential unless explicitly stated. For any facts to be made public, the reportee’s explicit permission is needed. All reports should be recorded, together with the discussion of it. A private moderation repo would satisfy the need for recordkeeping. | ||
| ## Steps/Escalation | ||
| 1. A report is filed: This is the first step, mostly defined in Channels above. |
There was a problem hiding this comment.
Link to channels here?
| Everything reported and discussed is confidential unless explicitly stated. For any facts to be made public, the reportee’s explicit permission is needed. All reports should be recorded, together with the discussion of it. A private moderation repo would satisfy the need for recordkeeping. | ||
| ## Steps/Escalation | ||
| 1. A report is filed: This is the first step, mostly defined in Channels above. | ||
| 2. The right people are alerted: See Roles. |
There was a problem hiding this comment.
Link to roles?
Also right seems like an odd way to frame it. perhaps "On call staff is alerted"
| 2. The right people are alerted: See Roles. | ||
| 3. Contact person assigned: See Roles. | ||
| 4. Report is acknowledged: The contact person responds to let the reportee know that the report is being discussed. | ||
| 5. Facts and opinions are gathered: Time is allocated to collect information in one place to make sure everyone involved has access. |
There was a problem hiding this comment.
s/Facts and opinions are gathered/Information gathering
We won't know what are facts or opinions... seems odd to frame it this way
| 3. Contact person assigned: See Roles. | ||
| 4. Report is acknowledged: The contact person responds to let the reportee know that the report is being discussed. | ||
| 5. Facts and opinions are gathered: Time is allocated to collect information in one place to make sure everyone involved has access. | ||
| 6. Facts are discussed: The facts are discussed in context of opinions. Also see **What to look forward to** for guidelines on appropriate response. |
There was a problem hiding this comment.
s/Facts are discussed/Information is discussed
We don't know what are "facts"
| 5. Facts and opinions are gathered: Time is allocated to collect information in one place to make sure everyone involved has access. | ||
| 6. Facts are discussed: The facts are discussed in context of opinions. Also see **What to look forward to** for guidelines on appropriate response. | ||
| 7. An action to be taken is arrived at: The action to be taken is decided by consensus (see section on Consensus process) involving the roles listed in the next section. | ||
| 8. Resolution offered: The resolution is offered to the reportee by the contact person. The reportee needs to accept the resolution for the matter to be resolved. If they don’t accept, go back to step 5. If there isn't a clear way to resolve the report, the report can be reviewed by the moderation team representatives from OpenJS projects to ensure that the the action and resolution are appropriate. |
There was a problem hiding this comment.
I'm not sure I'm 100% in support of this. While the reportee should be consulted in deciding the resolution they should not necessarily be in the position to make this decision.
| * Contact person: This is a sensitive matter. Each reportee should only have to become comfortable talking with 1 person who represents them to the representatives. | ||
| ## Concensus process | ||
| _To be added after deliberation in CPC._ | ||
| ## Further questions |
There was a problem hiding this comment.
These questions should be moved to the readme
|
@keywordnew do you have time to update this? If not lmk and I can push an update based on my notes |
|
I'm also happy to do a pass of edits to make it consistent between the existing description of the reporting process and this new content on how we'll handle reports once they come in. |
| 5. Facts and opinions are gathered: Time is allocated to collect information in one place to make sure everyone involved has access. | ||
| 6. Facts are discussed: The facts are discussed in context of opinions. Also see **What to look forward to** for guidelines on appropriate response. | ||
| 7. An action to be taken is arrived at: The action to be taken is decided by consensus (see section on Consensus process) involving the roles listed in the next section. | ||
| 8. Resolution offered: The resolution is offered to the reportee by the contact person. The reportee needs to accept the resolution for the matter to be resolved. If they don’t accept, go back to step 5. If there isn't a clear way to resolve the report, the report can be reviewed by the moderation team representatives from OpenJS projects to ensure that the the action and resolution are appropriate. |
There was a problem hiding this comment.
Suggested revision:
| 8. Resolution offered: The resolution is offered to the reportee by the contact person. The reportee needs to accept the resolution for the matter to be resolved. If they don’t accept, go back to step 5. If there isn't a clear way to resolve the report, the report can be reviewed by the moderation team representatives from OpenJS projects to ensure that the the action and resolution are appropriate. | |
| 8. Resolution offered: The reportee is consulted in landing on a resolution to the report. If there isn't a clear way to resolve the report, the report can be reviewed by the moderation team representatives from OpenJS projects to ensure that the the action and resolution are appropriate. |
Co-Authored-By: Myles Borins <myles.borins@gmail.com> Co-Authored-By: Sendil Kumar N <sendilkumarn@live.com>
|
@keywordnew would it be ok if I did a pass to try and line it up with the previous text that covered the external description of the process? |
* Insert links * Remove content * Use suggested language
* Revise description and completion criteria * Add further questions
keywordnew
force-pushed
the
mhc/handling-reports
branch
from
527e6b4 to
16e4431
Compare
|
Thanks for your patience @MylesBorins @mhdawson. Sorry for dragging my feet on this and being a blocker. Hit a bottleneck with my bandwidth this month. Please feel free to add changes to the branch, especially if that's the most straightforward way to get the language to a good place. |
Co-Authored-By: Manil Chowdhury <manil.chowdhury@gmail.com>
Co-Authored-By: Matteo Collina <matteo.collina@gmail.com>
|
Discussed in CPC meeting, agreed that we can land and them open PR to move to Stage 2 and address any new questions/issues etc. as part of that PR. |
|
To respond explicitly to: #271 (comment) Yes, it looks good to me. Thank you @mhdawson! Thanks everyone for pushing this through. Landing this PR now. |
This addresses #160.
This draft needs discussion.
Reports made to report@openjsf.org will follow this process once ratified.