Specifically, I’d really like to get some people installed as actual admins. Maybe that’s some subset of CommOps, or it may just be that CommOps helps develop guidelines for selecting admins, admin authority, continuity, and etc.
Also, ping @gbcox because I know Gerald has expressed interest.
Referencing my other posts on this, I’m now assuming that the direction is to utilize Discourse to it’s fullest capabilities, i.e. “in for a penny, in for a pound”. Additionally, my understanding is that this is a hosted instance, so if we notice deficiencies, bugs, etc. we should be actively leaning on the Discourse folks to get the issues addressed - however, it’s our responsibility to identify and report. That’s why IMO the Feedback category is so important.
Yeah, I’d like to see us make this really successful. Obviously some people are also quite attached to mailing lists, so it’s not going to be a “shut down all other means of discussion” form of “in for a penny, in for a pound”, but that also doesn’t mean we shouldn’t take advantage of the possibilities.
And, yeah, it’s a hosted instance, so engaging upstream is the way to go. We are paying customers so we can use their support channels, too.
@gbcox thanks for the feedback. I understand what you’ve written, but in light of the Council’s desire to be communication system inclusive, perhaps we could detail it out a bit. This will also, perhaps, help those for whom English idioms are not native.
We need a group of admins for discourse who can handle the work-a-day issues of managing a communication site. They don’t need to do heavy technical implementation lifting (it’s hosted) or administration of the contracts, etc. They do need to keep an eye on the forum and help with some settings as appropriate.
We would like those admins to do two additional things: a) Identify bugs and issues we can report to Discourse. This will help us contribute back to their code being better and get us a better experience; b) Create a welcoming and useful communication alternative. This way teams in Fedora that find their needs aren’t being met by the other tools can find a place to do their work here. We aren’t really looking for a heavy handed push for conversion.
Does that align with your thoughts?
@bex… I can be an admin. I have technical experience so I can also adjust settings, report bugs and work with Discourse support. To be clear, I’m not looking for a forced conversion away from mailing lists. What I am interested in is expanding the existing categories so more people can find Discourse useful. @bcotton mentioned that existing teams make the decision on what platform to utilize… and that’s fine with me. However for things such as the Devel mailing list, it’s not associated with just one team. We should be able to replicate something here on Discourse that will also provide that type of forum. It could be called for example “Technical Contributors” or whatever. As @mattdm also alluded, we should be taking advantage of all the possibilities that Discourse offers - to me that means actively investigating, discussing and implementing things we collectively believe would be advantageous to the community.
@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.
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.