@gbcox I think we are on the same page.
With regards to devel list, I think having a technical contributors conversation here is a great idea. My one concern is that we could easily get split conversations. That isn’t necessarily bad, but it is a concern. We already have this problem though. Perhaps by having a new conversation point we will find a solution …
ok, sign me up! As far as the split conversations we may be able to mitigate that somewhat with the mailing list function - or maybe you’ve already looked into that. It won’t be much of a problem initially anyway because it will take time for people to acquaint themselves with the new categories - so we have time to figure out a solution, or maybe attrition will take care of it.
To be clear, I would be super hesitant, today, to subscribe devel list (or ANY other mailing list) to a Discourse forum where the expectation is that the ML folks will continue as though Discourse isn’t there.
Is there an expectation that acting as an admin also includes a responsibility to (retro-)moderate the Discourse community as a whole, deleting content that is against policy and manage bans of users as required? These issues will become relevant once Discourse use increases and challenges that exist on Fedora mailing lists today will become relevant here as well.
(I don’t have an opinion here—I just want to make sure that people understand what they are signing up for.)
s there an expectation that acting as an admin also includes a responsibility to (retro-)moderate the Discourse community as a whole, deleting content that is against policy and manage bans of users as required?
Yes, absolutely. Thanks for asking the clarifying question.
That’s fine, that wasn’t what I meant. I was just thinking out loud regarding possible mitigations - my goal is not to force people away from the mailing lists - however, I don’t believe we should let anti-Discourse people control the future of Discourse.
Discourse has tools to assist with this. People can read about them here: Discourse Moderation Guide - moderators - Discourse Meta
Users can also flag posts themselves which bring them to the attention to moderators.
Offenders can be silenced or suspended, and this can be set for a specific period of time. If the user is a repeat offender after the silenced/suspended period expires the timing can be increased.
Personally, I don’t think this would need to be used very often, if at all. Most of the time, people just need a friendly nudge - and as long as people aren’t breaking Fedora policy, we should let the discussion continue. If it becomes off-topic, we could move it to another thread.
We should also take advantage of the moderator communication functions.
I believe moderation guidelines and policy from the Fedora Council would best enable volunteer contributors to succeed in asynchronous community leadership roles. I also suggest opening this type of role to Fedora Advocates.
As I see it, moderation guidelines and policy by the Fedora Council is a “best practices” community management guide written with the Fedora Code of Conduct in mind. Given the CoC is an abstract policy, the moderation guidelines/policy are a concrete implementation of what managing a community in the spirit of the Fedora CoC looks like. Adding more admins today solves the current challenge but that does not scale, and creates a different problem instead (free-range moderation).
In an isolated experiment moderating for a very large forum community, I found behavioral guidance explaining how to react to different kinds of behavior and framing justified responses from a moderator as useful tools. They were effective at lowering moderator stress and held moderators accountable to a more transparent and open standard (also decreasing resistance with troublemakers). It also decreased on-boarding fatigue for new community moderators.
Additionally, Advocates are a large, distributed group of contributors with lower barriers of entry. CommOps is a small, more narrow group of contributors with a higher barrier of entry. Integrating community leadership roles into Fedora Advocates acknowledges and appreciates this type of community contribution and encourages people already doing this type of work to engage directly upstream.
Including the role of community management to Fedora Advocates widens who is included. Moderation guidelines and policy from the Fedora Council potentially helps “downstream” Fedora user / contributor communities build healthy communities that adhere to the spirit of the Fedora CoC, since the current CoC is a value statement, not an instructional policy.
What do y’all think? I am thinking cautiously about maintenance of something like this Discourse site and what kind of a commitment that requires at the volunteer level.
I believe moderation guidelines and policy from the Fedora Council would best enable volunteer contributors to succeed in asynchronous community leadership roles.
The Council delegates the specifics of moderation to the team managing it.
I also suggest opening this type of role to Fedora Advocates.
You can open it up to whomever you want. People can be a part of both groups, but this seems clearly outside the definition of Advocates. If someone participates as a moderator, it is with the CommOps hat on, not the the Advocate hat. CommOps has been looking for something to focus on, and I would say “if not this, then what?”
How about we just get started :). @gbcox you seem interested and willing. Barring objections, I suggest that we make you an admin and let you get to work. Do NOT feel like you have to do all the work a team of admins could from day one, just do what you can and wish to do. If you run into challenges, ping me or Ben and we can help out. When you need to make hard decisions, let me know so we can work together and I can be a sounding board for you.
Over time, as we attract more admins we can look at formalizing how the work is done. WDYT?
Aside, not sure if this is of interest to anyone, but these are the mod guidelines followed on the Fedora Discord server: Moderation guidelines for inclusive community
Replying from email to get an understanding of the complaints about the mailing list interface.
@bex - Sounds good to me. In the meantime, can we get the “Technical Contributors” category started (or whatever other name seems more appropriate). Would also be helpful if we all had a team meeting at some point.
Thanks!
Visit Topic or reply to this email to respond.
Ok, @gbcox, you are now an Admin. With great power comes great responsibility, etc. 
There’s a “Moderator Discussion” category that already exists; does that cover the “technical contributors” category you want, or was that something else?
Thanks @mattdm … regarding the “technical contributors” category, I was referring to this:
Which is basically to create a catch all technical/devel category which functions in much the same way that the devel mailing list currently functions.
Ah, I see. Hmmm, I’m not sure that’s necessarily so useful, since it’s easy to cross-link and move topics between categories. But it’s worth trying. I guess under the “Project Conversations” main category to start?
Yeah, I agree “Project Conversations” would be the appropriate place. What was confusing for me was the only subcategories I see there are “CommOps” and “COPR” - so if you wanted to talk about an issue with fedpkg, dnf, bodhi, koji, etc. there isn’t an obvious place to start the topic.
You should have the power now. Go ahead and create it and we’ll see what happens.
ok, I’ll give it a whirl… Thanks Matt…
I came back across this thread after a long time. We’ve come a long way since kicking off the Discourse site in June 2019. It could be a good idea to think about moderation guidelines in the context of the ongoing Code of Conduct work too.
No action needed, but I wonder if others have thoughts now that two-ish years passed since we last reviewed moderation guidelines.
In the last two years, I’ve developed a strong opinion: there need to be moderation guidelines that are separate from the code of conduct. A lot of moderation should be just routine, and not raise to the level of “incidents”. This is better for the moderators, better for keeping the site running smoothly, and better for gently encouraging good behavior rather than escalating. The CoC needs to be there in the unfortunate event of escalation or ongoing problems, or of course for serious incidents, but most moderation shouldn’t need to invoke it.