Quality of offering on one Discourse

Mozilla Communities Web Services
#1

Background

For reasons that are still true, when we first discussed getting Discourse adopted by Mozilla we had planned to offer a “multi-site”, multiple instances of Discourse with an SSO offering and ideally some portal that allowed for searching across instances/managing categories across instances.

Problem

One issue with one Discourse is the lack of per category moderation. This represents a real loss of autonomy and functionality for communities if they were to migrate from a stand-alone discussion forum to Mozilla infra.

Another issue is that the more categories that are on an instance that are not relevant to many of the users on that instance the more degraded the search and suggestion features become, the more unusable the category listing pages become.

Question

Would our communities be better served by independent or loosely connected Discourse instances than by a single Discourse instance?

I understand that one of the reasons multi-site was abandoned was that making the built-in search work across instances was prohibitive. I would suggest that we actually do not want to replace the built in search to search across instances, that users would be better served by only searching in the current instance with highly related categories. We would want to introduce an easy way to get back to the main page to switch instances and possibly have a global search, though the users that do work across many instances could rely on Google in the mean time.

Are there other features or functionality supporting staying on one instance that we should take into consideration?

#2

One thing I like about our single-instance setup is discoverability of forums.

Along those lines, do we have categories that conflict in search right now?

#3

Yes we’d definitely want to have something for discoverability of other categories across instances.

I don’t know if there is currently an issue. Think about the effects it had when we added AMO. Now imagine we were to onboard another 5 or 10 large active communities, with multiple subcategories each. Would that be sustainable? Where would that start to hurt, ie which functions might become harder to use?

#4

I think that is can be helpful only for local communities because actually everyone right now receive notification from forum sections of different local communities also if it is a member of another one.
I mean, for me Discourse is helpful for local like the international and every locale has their instance so there are no conflict for search.

1 Like
#5

This is the context I’m thinking about. What we have on the one Discourse now is some regional communities, but mostly categories related to centralized contribution to Mozilla (Reps, Add-ons, Common Voice). I’m thinking about whether we should offer to host larger local communities in the same instance or if it would be better to keep them separate, though possibly have a central directory depending on code constraints. Though I want to make sure we are not overlooking potential problems in settling on one model or the other.

#6

I understand how communities might feel this is the case, but considering the vast majority of moderation we do is deleting spam, followed by removing posts which violate the participation guidelines - both of which don’t require a knowledge of the community using the category - I wonder if per category moderation is actually needed?

We definitely take a more organised approach to moderation though, and that’s something I plan to work on this quarter.

I definitely agree this is an issue - one which we’re already facing. But given the technical headache that trying to link up multiple discourse instances would be, I think solving these problems by expanding and improving these features would be better.

Of these, I think the category listing page - and the whole subscription management system - is the most broken, and I’ve already had some extensive discussions upstream about this. They seem keen to solve our heterogeneous instance usecase - we just need to be the driving force behind it.

These two issues should link to the main discussions:

2 Likes
#7

Thanks for the reply! Good to see we’re on the same page about pain points.

We (MCWS and you + CoSS?) should work together on something of a roadmap in terms of what improvements need to be made before we should offer to host which usecases on the main instance, eg we what improvements should be done before we offer to migrate a community with a thriving BB system on OVH to Discourse.

I saw a suggestion to rather than limit moderator powers to a certain category, limit the notifications of flags to only related categories. I think that would be a possible solution along with good guidelines. I assume there is a way to track which moderator performed which action? That way if someone oversteps in another category there is accountability.

2 Likes
#8

Help on this would be excellent! :smile:

What would you find easiest/your recommendation be for starting this? Just throwing things in a shared google doc and then going from there?

Yes, that seems like a good idea to me too - I often-times find myself wanting to leave things to the add-ons team to review, but the red icon persisting just bugs me.

There’s also the ability to assign topics to users with the discourse-assign plugin, which I haven’t fully looked into yet.

Yes, everything (should be, I haven’t done an audit) logged - if there’s stuff that isn’t being, upstream would definitely support adding it.

#9

I think this may be the path of least resistance to start. I am not thrilled with Google docs, but I think it’s a good place to gather the info, then ideally we can move to a Discourse wiki topic when we have something we can frame.

1 Like