Thursday, September 15, 2016

Re: IRC SIG needs external oversight

On Thu, 15 Sep 2016 15:19:01 +0200
Brian Exelbierd <> wrote:

> This theme came up a couple of times. It sounds like we need to deal
> with both mechanical issues (join spam) and CoC style issues (racist
> trolls).

Well, and all the other things... people getting upset, people being
treated poorly by others, bad advice, disruptive people, etc.
> Instead of thinking of IRC as a separate entity, I think we should
> give consideration to reforming the group with a more all-encompassing
> charter. All of our communications methods should be subject to the
> same guidelines and the same responses.

I think thats not a bad idea (in fact I wanted to do this a long time
ago), but there's some hurdles to that. At least:

We can get lists of: list moderators, ask moderators, irc operators,
but thats not conclusive. Some of those people may not be active, some
very helpfull and active people may not be on those lists, some of them
may not want to be.
> An issue on ask.fpo, a mailing list, telegram and irc shouldn't get
> four different responses.

Sure, but there's different setups in all of them. Say someone wanted
to spew some spam. On ask if it's their first post it would be
moderated, the moderators would delete it. No one but them would see
it. On a mailing list they would subscribe and post and list moderators
would be able to stop them posting again, but everyone would see the
post and they would have to talk to the list about it, ask people not
to respond, etc. On irc they would be able to keep spewing until
someone noticed and quieted them.

> 1. Could this group work with or combine with the Diversity or CommOps
> groups to create a group of people who can step in when something
> happens and our CoC guidelines are called into question? This would
> also spread the workload and reduce burnout.

Sure, but again the overlap here isn't as high as you might think.
People I see on IRC are seldom also active on ask or lists. An ask
moderator wouldn't have any idea the irc commands or know when to step
in, etc.

> 2. On services, like IRC, where we know the FAS ID of every person,
> let's make it policy that we reach out via at least two communications
> methods. On other services, we do our best effort toward that goal.

We don't know the fas id of everyone. We know it in some cases (where
people put their irc nick in their fas account data and it's correct).

> 3. Can we become more transparent about bans and the equivalent on
> other communications methods? Knowing who has been banned, why and
> what actions were taken in advance is much better than having a
> slug-fest in tickets.

Perhaps. You mean when taking the action? or ?
> 4. We should have a clear set of guidelines for mechanical issues and
> a clear document to point people too. Ideally, for those
> communication methods that support it, we should do something like
> bounce people to a #fedora-unregistered equivalent so they get a
> clear prompt in method that something has happened. It can also
> reinforce the pointer to the documentation.
> 5. Help the people who do this work by developing a set of stock
> phrases that can be crafted in advance during a calm moment. These
> phrases can hopefully have been tested in various parts of the
> project to try and reduce any misreading by individuals from
> different cultures. Obviously, we will never have a perfect set of
> phrases, but it can be a lot easier to respond to someone if you
> don't have to craft a careful response in the heat of the moment.
> This will also help make sure that our messaging stays the same.

Sure, we already have that on irc somewhat with bot messages "You have
been quieted in the channel because you were disrupting things, please
take a break and come back in a little while"

Anyhow, I'm personally not against reorganizing our support setup, but
I think we would need to get a bunch of the stakeholders together and
come up with some plan/organization to do that.


No comments:

Post a Comment