On Thu, Sep 15, 2016, at 04:51 PM, Kevin Fenzi wrote: > On Thu, 15 Sep 2016 15:19:01 +0200 > Brian Exelbierd <bex@xxxxxxxxx> 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. I was using an, albeit extreme, example of a CoC violation. My point was to cover these situations. > > 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. Another theme I am seeing over and over again is the idea of our inability to determine who is active and who is not. Frankly, this is a problem that needs to be fixed but one that shouldn't stand in the way of our moving forward with other solutions. > > 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. The fact that one is a real-time communication method and one is asynchronous shouldn't stop us from having a similar response. It just needs to be a different response timing and possibly format. > > 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. One thing the involvement of these groups brings is new people and new energy. Even if these groups only started to be involved as part of a weekly issues review we may be able to learn more from the "after action reports." I also still feel very strongly that we need after action reporting, as has been suggested by jflory, amongst others. I believe we should be able to figure out what actions have been taken and by whom. > > 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). I stand corrected. I was thinking about the nickbot registration and equating it to FAS. You are 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 ? I mean, I believe that if a ban, for example, is issues, the particulars should be documented somewhere. This way if there is a subsequent problem, it isn't a surprise. > > 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" Somewhat doesn't seem to be cutting it here. We need to do more of this until it becomes automatic. > 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. Who do you think needs to be in the meeting. Let's act. regards, bex _______________________________________________ council-discuss mailing list -- council-discuss@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to council-discuss-leave@xxxxxxxxxxxxxxxxxxxxxxx
