Procedure is to file a Private Council Ticket.
Wording needs approval.
Metadata Update from @bex: - Issue assigned to bex
Proposed wording to be added to the end of https://getfedora.org/code-of-conduct
If you believe anyone is in physical danger, please notify appropriate law enforcement first. If you believe someone is violating the code of conduct we ask that you consider having a civil conversation with the person and directly discussing your concerns. We recognize that this is not always possible, practical or successful. Therefore you may also report violations or suspected violations to the Fedora Council. Please open a new private issue in the Fedora Council Pagure Repository. All reports will be kept confidential, however the parties involved will be contacted and disclosure to the parties involved may be required. In these cases we will discuss this situation with all parties involved.
If you are unsure whether the incident is a violation, or whether the space where it happened is covered by this Code of Conduct, we encourage you to still report it. We would much rather have a few extra reports where we decide to take no action, rather than miss a report of an actual violation.
In your report please make sure you check the box to make the issue private and include:
This text is borrowed heavily from https://www.djangoproject.com/conduct/reporting/
Opinions/edits?
Looks good to me.
So, with all due respect, and since you ask for my opinion, i think there is a lot of thing wrong in the changes that were made from the Django procedure.
First, I think that removing the part about "we may publish something" is bad. And while I do not know why this was removed, I see 2 outcomes, either we think we will publish something, or we think we will never do it.
If we think we may publish something sometime, then I do not see why we would remove it. It may slightly simplify the text, but has the side effect of creating some surprises, of hiding the idea that maybe we need to communicate sometime, and no longer convey the expectation that we will be transparent sometime. Surprise is something we should not expect for a reporting procedure, whose goal is to communicate what we will do so people can trust us with the report.
If we remove because we do not plan to publish anything, then this will communicate to a incident reporter that whatever happen, this will stay secret. And I think that's sending the wrong signal to the people that the code of conduct is supposed to help. To be said bluntly, I think that would be potentially be siding with the aggressor if we never publish anything
So I think we should get that part back.
Now, on a 2nd change. If I compare the django project code with the proposed one, there is one big difference. The django one start by "please report to us". The proposed one however start by "please consider discussing with people, even if we recognize that sometime, this cannot be done, so you can also talk to us". This doesn't send the right signal, since report is a 2nd option, the first option being "deal with it yourself", which is not really conveying "we will take your concerns seriously".
As a 3rd point, while I guess that we omit that now because we have no process yet and because that's a proposal, the fact that we have no idea of what happen after filling a report is also not sending the right vibes. If someone open a ticket, they wouldn't know what happen, what to expect besides "this will be treated confidentially". There is no expectation of having a answer, nothing.
In fact, the mere reporting process is not really adequate for some situation: - Not everybody has a fedora account - Pagure is not mobile friendly - the duty of keeping the issue private fall on the reporter, which from a UX point of view mean that some would fail, just by forgetting.
So maybe this should be amended.
Penultimately, this part "All reports will be kept confidential, however the parties involved will be contacted and disclosure to the parties involved may be required. In these cases we will discuss this situation with all parties involved" should be clarified.
For example, if the person reporting do not wish to interact anymore with the person whose behaviour was reported (for safety reason, like PTSD), what guarantees do they have this will not happen ? Would their name be given, despites it being a potential safety issue. ( Example of issue, A grope B, but A do not know the name of B, so revealing the identity of B would be bad ). I would suggest that if there is a report, then the course of action should be decided first with the reporter, and we should assume what we will be doing in this case.
And in the end, the whole idea of adapting the procedure is quite strange. We frown upon having a custom license for code. We dislike forking and patching code in the distribution. So why would we treat this document differently by substantially changing it, when we do not really have a ton of experience with what it implies ?
It is not like Django is something totally different from Fedora. Both are project around free software, with several venues of discussions, involving humans, with sometime conference or equivalents meetings. I do not see substantial difference, unlike the difference we would see between a company and a anarchist commune (and for a example on how the later would deal with violation, the article of Isis Agora Lovecraft on Jacob Appelbaum is a good summary: https://blog.patternsinthevoid.net/the-forest-for-the-trees.html ).
So maybe we could just take the Django CoC as is, minus minimal adaptation regarding names and governance instances.
Maybe the first sentence can be "If a crime has been committed, contact the local police. If you need assistance with doing this, contact the moderators at the event you are attending."
As for asking people to speak with a CoC violator first, that doesn't have anything to do with how to report a violation and doesn't really belong in that section. I think it is already covered in "respect other users" and interacting in good faith. So maybe just remove that because I'm sure someone has already tried that route before deciding to report.
I think the go project has a great section on CoC reporting and enforcement: https://golang.org/conduct
I particularly like that they mention de-escalation, not posting to social media to start a witch hunt, and what the process involves as well as addressing conflicts of interest.
I just found out about this blog post by Sage Sharp
https://otter.technology/blog/2017/12/28/code-of-conduct-enforcement-warning-signs/
It might be interesting to see how our CoC + proposal compare to the recommendations
Metadata Update from @bex: - Issue priority set to: Waiting on Assignee
Metadata Update from @bex: - Issue tagged with: code-of-conduct
Metadata Update from @bex: - Issue unmarked as depending on: #145
We have considered your feedback and we have decided to continue forward with a new CoC proposal and Council management. This proposal will include filing private tickets and we will be adding instructions as soon as the language is approved.
Metadata Update from @bex: - Issue close_status updated to: resolved - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.