Discussed in 2016-08-09 meeting.
It is unclear how and to whom a member of the Fedora community can confidently and responsibly report violations of the Code of Conduct to.
It has been noted and discussed about the difficulty in where or to who to report Code of Conduct violations to. Before, this may have technically fallen towards the Fedora Council to handle. But there are issues with using their Trac to report this. It requires the person to make the report in the public and open. This can be difficult or sometimes impossible for a victim to do in fear of the harassment or "punishment" they may receive for doing so. It's important that we have a way for community members to feel safe in how and to whom they report violations.
In light of the Diversity Adviser position, this may be a responsibility best deferred to the Adviser. This is a question that should be raised to the Council as soon as possible, if an answer is not clear at this time. Currently, @tatica holds the position as Diversity Adviser and is the best point of contact for issues related to this.
Publicly posted guidelines about how to report violations will be helpful for community members knowing how they can do so safely and responsibly. This would also involve having the right tooling available as well, e.g. the private Pagure repo mentioned in #1 for people to use, or email. Creating these guidelines will help make it easier for community members to communicate issues that could arise in the future.
I think this will be the best case studio for the inbox. With this Diversity Inbox we should be able, through a simple set of questions, to determine how the CoC was violated and how the affected person was involved. This will require a lot of work but it's 100% doable.
In Arch Linux's CoC they list staff members for various communities, like the forums and IRC and how to contact them: https://wiki.archlinux.org/index.php/Code_of_conduct#Enforcement
Fedora has a much larger community that includes forums, IRC, blogs, etc. But it may be a good idea to document how to contact moderators in each one in a single place.
@meskarune My follow-up question to this is whether it would be better to have a singular, unified place for all relevant people to have access to (e.g. a private Pagure repo) or if it would be better to encourage individuals to reach out to an individual, and then that individual shares it with the team if it's something they need help addressing? I'm trying to put myself in the shoes of someone who is feeling victimized to best understand what would be the most comfortable option. Do you have any thoughts or opinions on which route might be better to pursue?
I created a small test repository on the staging version of Pagure to test out the idea of using a Pagure repo for handling private repos. I like how transparent it makes who has access to the repo (anyone that has access to the repo, clearly displayed at the right of the main page of the repo) and therefore can view private issues. This could also be explained in a README in the repo too.
I see @meskarune and @bee2502 had signed in before on stg.pagure.io so I added them to the repo. If anyone else wants to see, just sign into the staging instance and I can add you (just make sure you tell me somewhere once you have done so)!
After playing with the Pagure repo, I think it's safe to use this as a tool for handling future reports from someone, whether they wish it to remain public or private. pagure1285 will be an additional feature we can use to ensure the privacy of any future reports. fedmsg notifications can be disabled on the repository to prevent the accidental leak of a notification on the global notification bus.
I would like to propose the following:
Thoughts?
Proposed solution After playing with the Pagure repo, I think it's safe to use this as a tool for handling future reports from someone, whether they wish it to remain public or private. pagure1285 will be an additional feature we can use to ensure the privacy of any future reports. fedmsg notifications can be disabled on the repository to prevent the accidental leak of a notification on the global notification bus. We need to do some good testing for privacy once it is all set. I would like to propose the following: Create an official repository for Code of Conduct (or maybe Community?) reports
Proposed solution After playing with the Pagure repo, I think it's safe to use this as a tool for handling future reports from someone, whether they wish it to remain public or private. pagure1285 will be an additional feature we can use to ensure the privacy of any future reports. fedmsg notifications can be disabled on the repository to prevent the accidental leak of a notification on the global notification bus. We need to do some good testing for privacy once it is all set. I would like to propose the following:
Create an official repository for Code of Conduct (or maybe Community?) reports
yes
Add appropriate people to the repository Does this mean Fedora leadership (e.g. Diversity Adviser and Council members) only? Or does this include Diversity Team members?
I would say lets add team members too, we are very small in numbers in the team and as we discussed, we are a team of diverse people (from different part of the word) , so we can give our prospective to the case, first the members do the drilling of the case and represent the facts to Diversity Adviser and Council Members, So we can say solving a case may be two fold process.
Create a detailed README file explaining what the repository is for and how to use it
yeah and publicize it well enough. I would love to write a post on this and include in all the talks I will do.
Add it as a resource to the Diversity Team and Diversity Adviser wiki pages
yes yes
Thanks for taking care of this @jflory7
Just putting these links here for later reference:
When will this be going to the council?
Can we look at not burying this data in the wiki?
I like the idea of a git repo with issues. People could attach logs, screenshots and other documentation so its easier to keep records. I think a single point of contact to help coordinate CoC issues would be very helpful, but having a list of moderators would also be helpful for the coordinator. I don't know if fedora has an email like abuse@fedora or if people on the IRC and forums already have reporting systems in place. If there are already per-exstisting ways to report problems on various platforms they should be documented in a way that is easy for someone to find and use.
Discussed during the 2017 Diversity FAD.
The end result of a lot of our discussion on this is that before we make decisions on this, we want to research and better understand how other communities handle these kinds of things so we can learn from what is successful in other communities or learn what to avoid. I'll break this comment into some general resources we noted and then our discussion points for how we wanted to approach this.
These are still a lot of raw notes, but this sums up where we left off on this discussion.
Metadata Update from @jflory7: - Issue priority set to: None (was: 10)
Metadata Update from @jflory7: - Issue priority set to: 30
I helped write the Ubuntu Code of Conduct and served on the Ubuntu Community Council which oversaw disputes in the community.
I will be happy to discuss my thoughts on CoC guidelines and how the Ubuntu Community Council dealt with disputes.
I am slightly surprised to not see https://www.coc-handbook.com/ in the list of resources, so I am mentioning it. It is based on the experience from the django girls organizers (and django under the hood events), who are both quite successful into getting inclusion right (IMHO).
@cprofitt
I helped write the Ubuntu Code of Conduct and served on the Ubuntu Community Council which oversaw disputes in the community. I will be happy to discuss my thoughts on CoC guidelines and how the Ubuntu Community Council dealt with disputes.
Can you add them here?
Most of the forum moderators and IRC ops are probably already actively looking out for CoC violations and kicking or banning according to their sub-project rules. It might be a good idea to find out what their process is, and also if they communicate with each other at all. If not, communications between various moderators can help catch problems faster if a person is causing issues in multiple places in the community. This way someone who trolls on irc and then later has a first offence on the forums might be handled more harshly than someone who has never caused problems anywhere.
As for in person events, having staff available specifically for monitoring and being points of contact in case of CoC violations would be a good idea. Also having a number people could send text messages to or a telegram or irc channel that people at the event could use to communicate would help greatly.
I think it might also be a good idea to contact Fedora staff who actively police the community to give some input on what would be the most helpful for them to do their jobs effectively. Most CoC violations are pretty obvious and don't require a long debate. Quick actions prevent any disruptions to the community. It's a problem if a person who is breaking the CoC doesn't get banned for days or weeks due to a long bureaucratic process. It just furthers community disruption. For edge cases having a point of contact to mediate would be really helpful and for violations that may be diversity issues the Diversity Advisor would certainly be a good fit for that.
Ubuntu related links: CoC - https://www.ubuntu.com/about/about-ubuntu/conduct Community Council - https://wiki.ubuntu.com/CommunityCouncil Ubuntu Community Governance - https://community.ubuntu.com/community-structure/governance
Notes: Fedora has no Benevolent Dictator so some parts of the Ubuntu CoC will clearly not apply. The general overall 'tone' or 'guiding principal' is 'be good to each other'. When I participated in creating the document I learned that one of the fears that was guiding certain language was one of gridlock. There was a desire to not allow disputes to gridlock the community. A clear mandate for 'leaders' to make decisions was included, but a requirement to do so in a transparent and tactful manner.
Another key component was for 'leaders' to know when to step down gracefully. This was designed to allow people to step away from the project when they realized that they could no longer dedicate sufficient time to the projects / items they were leading. In many cases leaders left and did not hand over 'control' or conflicts arose when leaders were non-responsive and holding up a process. While this falls outside what many think of as normal for a CoC I see value in having some provisions in place for dealing with these situations.
As a note -- almost every alleged violation of the CoC was disputed. At times the dispute was limited to the person being banned from IRC channels, but there were times that disputes were between large groups on either side. What ever body or person is responsible for making these decisions must have the 'authority' to do so and there must be a well documented appeal process that involves the ability to bring in people who do not have a conflict of interest. The policy has to apply to everyone regardless of how 'important' the person is to Fedora. High profile members of the community should not receive deferential treatment.
example: irc user is banned from #fedora channels due to repeated violations of the CoC. This person then claims that the IRC person / body that enacted the ban has a conflict of interest. That should elevate to a group of people who do not have any governance powers on IRC.
https://djangogirls.org/coc/ - Two main points to notice in djangogirls COC - 1. It is available in more than one language. Excellent ! 2. It is clearly highlighted that "The staff is well informed on how to deal with the incident and how to further proceed with the situation." . I will work on to explore this part to know "how".
It may also be worth looking at some social media companies, like Twitter for what they do: - https://support.twitter.com/articles/20175050# - https://support.twitter.com/articles/18311#
Wanted to drop this link that @bee2502 shared with me a while ago about the Mozilla Community Guidelines.
See continued discussion of this on this mailing list thread.
In their recent FAD, Council agreed that they will be taking this issue forward with an emphasis on an open and transparent process related to the Code of Conduct. The links to email thread and Community Blog Post related to this announcement from Council :
https://lists.fedoraproject.org/archives/list/council-discuss@lists.fedoraproject.org/thread/HQPSNVKBI3LTUVH6SVJZ7BMUVOPQJLCZ/
https://communityblog.fedoraproject.org/fedora-council-fad-2017-report/
I am not closing this ticket yet (but blocking this instead) as I feel that Diversity and Inclusion team should still be involved. My reasoning for this is mainly that there are some events which do not constitute as a CoC violation and yet they are such that lead to deterioration of inclusiveness of a community. Building an environment such that every Fedora community member feels included irrespective of their background, race, gender, demographic factors etc. is one of the Diversity team's goals and to achieve this - feedback is extremely important. I feel that the Diversity team should still work towards building such a safe space for community members where feedback is possible, extremely important and more importantly every community members' experiences are heard - whether good or bad.
I would love to hear the thoughts of Diversity team as well as the Fedora community on this.
Metadata Update from @bee2502: - Issue untagged with: fad - Issue tagged with: meeting
Metadata Update from @bee2502: - Issue tagged with: blocked
Bee and I discussed this a little further, and we came to the conclusion from the Council FAD report that the topic originally raised in this ticket is something that the Council is planning to work on. However, as it will be a transparent process, we will be following along closely to leave feedback and to help with our own perspective too.
@bee2502 is going to file a new ticket with more concrete ideas about the Diversity Team's role as she described in the previous comment, to keep this on our radar.
Metadata Update from @jflory7: - Issue untagged with: blocked
Metadata Update from @jflory7: - Issue untagged with: meeting - Issue close_status updated to: Duplicate - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.