Please fill in this template fully and provide all requested information. Incomplete tickets may be dropped.
This feedback is: {{{ [ ] Positive [ ] Negative [x] Neutral }}}
My IRC nick is: striker
Please briefly describe the interaction that caused you to file this ticket:
The #fedora-diversity channel has a lack of concrete user and op codes of conduct and has recently been the in-direct target of personal attacks. Pulling the channel under the Fedora IRC SIG umbrella will give the channel a foundation of rules as well as operator assistance from those OPs who have the bandwidth to lurk there.
Please note other IRC nicks that are involved in this interaction: nirik, tatica
Please describe what action or positive change could be adopted based on this feedback:
The channel founder (tatica) and the fedbot owner (nirik) agree upon the above reason and then take the necessary actions to include #fedora-diversity within the Fedora IRC SIG umbrella.
Mattdm has already given his un-spoken approval of the sub-project Diversity, per his attending and participating in the meetings. Including the project's channel within the Fedora IRC SIG umbrella would be helpful in this case, if both parties agree.
Hi,
So the following is what I was sending in an email to tatica, decause, and a few others, but to open the discussion publicly, I'm reposting the email to this ticket to help centralize the discussion about this issue.
I am going to offer the following explanation as context to my actions of issuing the bans and why I did so, as well as offer some solutions to the problems as well.
== Background / Context ==
I first made the mistake of not sending this immediately after I issued the ban, which should have been the first action after the ban.
I'd like the explain the context behind my actions.
Someone reached out to me about ayil and anosh in channel on Saturday. They shared with me some logs from a channel on the Rizon IRC network showing these users (along with others) quoting logs from #fedora-diversity and negatively commenting on the discussion.
These users are also the same group that has recently performed coordinated attacks against similar groups in the broad Linux community, to Ubuntu Women and ArchWomen. Their actions are clearly shown by past actions to be of malice and spite.
After reading the logs given to me and noting previous discussion that has happened in #fedora-diversity, I believed it to be justified to issue bans to these users as the channel was clearly becoming a hostile place and the result of their presence would be to force channel members into private messages. In my views, this defeats the entire purpose of the channel if members cannot feel like they can discuss or collaborate without their messages being fed directly to people who have a record of personal harassment. I think it defeats the entire purpose of what we're trying to create.
I know there is a precedent to not ban users based on past actions in other locations or other places, but I am strongly of the belief that at least for this channel, #fedora-women, and #fedora-outreachy.
To put this as an example, say you are at a social event. Someone else at the event openly harasses you, is completely disrespectful, insults you, and very clearly makes you unwelcome. You leave. Later on, you are at another social event, where the same person is also. They may not be talking, but are you really going to feel comfortable and welcome in a place where someone who very clearly has no good will is?
== "Special Cases" rules ==
For these reasons, I think the three aforementioned channels need to have their own set of "Special Cases" to make them isolated from those who may not be "vocal" in channel, but are sitting in the channel with ill intent.
I recently learned of some resources from the ArchWomen community of a list of users who have harassed, disrespected, and attacked members of similar communities. If we don't choose to preemptively act with that list, it would be a useful thing to have available to us of users who have a past record for us to monitor. Fedora's Diversity efforts are obviously very new, and I think reaching out to these communities that have been around a bit longer and have some experience with what we are trying to do would be smart and wise.
== Granting OP privileges to IRC SIG ==
I also think it would be a good idea to also grant OP privileges to the #fedora-ops team for adding more people to act as first responders in the event of some coordinated attack or awful behavior, as a preemptive measure.
Replying to [comment:1 strikerttd]:
I think this sounds good. I spend most of my Fedora time reading and solving direct cases that need my attention and due local issues I cannot spend so much online time on IRC. So having extra protection sounds about right, knowing when you need help is be smart.
I think that Diversity channel will need an extra pair of rules only for the protection of the people hanging out in there, yet, those need to be written. I'll make sure to point that in our next meeting. however, the diversity channel can go under IRC SIG umbrella at any moment, it's a +1 from me.
I have developed the following, with Tatica's approval:
The #fedora-diversity channel is not asking to formally be under the IRC support SIG, but #fedora-diversity requests the assistance of interested members of the IRC support SIG to help monitor this channel. Any voting member of the IRC support SIG may be added to the ChanServ access list of #fedora-diversity upon request. (Voting member is defined as a member of the irc-support-operators FAS group).
Leaving this ticket open so that this can be discussed at the next IRC support SIG meeting.
Any irc-support-operators member who wishes to be an op in #fedora-diversity can contact Tatica or I to be added.
It was decided by the diversity channel not to be included within the Fedora IRC SIG umbrella. I will close this ticket for now.
Login to comment on this ticket.