GNOME Discourse improvements brainstorm

As per our discussion on Engagement room on Matrix, are there any improvements you guys would love to see?

I personally would love to steal copy categories from KDE’s discourse. I feel like they’re much better and much more intuitive than what we have currently.

Feel free to leave some ideas here :slight_smile:

2 Likes

Maybe we could also use some custom theme? So it wouldnt feel as generic as right now. Ubuntu and KDE folks seem to being doing it and i think the effect is pretty nice.

That’s a recipe for disaster when it comes to updating Discourse, so: no.

“Intuitive” is not a thing that I care about: there’s nothing inherently “intuitive” in a category named “Brainstorm” compared to one named “Desktop”.

What kind of categories do you want to see? What kind of topics should go in each category?

After 5 years of administrating Discourse I can tell you that people barely use categories to begin with, even when they are quite self-explanatory. “Desktop” and “Applications” are probably the most used. “Platform” is used for development, so we could conceivably rename it that way.

1 Like

Maybe what we need to do is approach this the same way the design team approaches doing design of apps? Find a few discourse instances and see what you like about them, look at how engagement work and then create a proposal.

We already got one data point which is that categories seem to be ignored.

I agree with ebassi that having a custom theme is a recipe for disaster, we’ve done this multiple times over the years and it turned into a maintainability disaster because every time you have to do an upgrade then you have to possibly debug the css if any design element changes.

Stick to default look and feel as much as we can.

1 Like

Thanks for your work administering Discourse over the years, @ebassi . It’s very valuable and often overlooked.

In addition to looking at other instances to see what we like/dislike, I would also approach this question by looking at the main use cases. For me, these probably fall into 3 buckets:

  1. User support and discussion
  2. Third-party developer queries
  3. GNOME development (internal technical discussion)
  4. Non-technical GNOME project discussion (between contributors)

Personally as a GNOME contributor, what I really want is the ability to see the latest conversations about 3 and 4, while screening out the conversations from 1 and 2. This is partly about being able to see what is important to me personally, but also a matter of knowing who is participating and to what end. In my view, user and 3rd party developer discussion is fundamentally different from contributor discussion. The audiences and expectations are different, and the type of activities that you engage in for each one are different.

I personally find that the existing Discourse categories don’t map on to those fundamental types of conversation that I listed, and results in the site being hard to use. I don’t know where to go to find contributor discussion, and it’s difficult to subscribe to just those types of conversation.

For example; “Desktop” and “Applications” get used for both user and developer help, but they are not described in those terms. “Community” isn’t purely a place for contributor conversations, since it includes “User and community support for accessibility”. There doesn’t seem to be a category for “internal development discussion”.

I’ve previously thought that having two instances would be good: one for user and developer queries, and one for contributor discussion. It could be ask.gnome.org and forum.gnome.org. My feeling is that a dedicated contributor community platform would boost engagement and generate a sense of ownership.

If that’s not feasible then I’d be interested in reorganising (and clarifying) the categories, so that they are aligned with the 4 main use cases that I described above. I could potentially make a more concrete proposal along those lines, if that would be helpful.

Adding another instance is just a non-starter: it would require admin and moderation resources we don’t have, and it would make it impossible to move topics around—some things get discussed within the larger community, then moved to a smaller set of people, then back again.

It’s also hard for me to understand how you plan on identifying who is “internal” and who isn’t. Do we restrict access to Foundation members? We can do that for categories already; but we don’t neatly map “contributors” to “foundation members”, and never have.

From an archival and future reference perspective, it’s also really hard to justify: digging through mailing list archives is a fundamental aspect of figuring how the context of a decision, and that cannot happen with private topics. How are you planning to disclose “internal” topics?

If all you want is a space for contributors to talk amongst themselves, we can already create a “Teams” category, and have sub-categories for each team, with specific access control that determines who can read/write topics in them.

The categories in Discourse exist because Neil and I needed to create a bunch of those in 2019, and we decided to map to areas of interest, leaving tags to do the heavy lifting. They are not fixed, and new ones can be added…

1 Like

The community instance wouldn’t be restricted by membership and would be public. The two instances would just be differentiated by topic and how each site was presented. I get the point about being able to move topics around though - that’s an obvious disadvantage.

But let’s not get too hung up on the two instance idea. The main point I’m making here is that we need to address the different needs associated with some distinct use cases.

(And if two instances isn’t practical, I’d be interested in exploring how we can restructure the site we have.)

That sounds just a recipe for confusion for everyone involved. User support will naturally gravitate towards where people involved with the project are. I mean: we get user support questions on GitLab, what makes you think they won’t appear on the “internal discussion” instance, unless you add some ACL to prevent that?

As I said: categories can be added and renamed (within reason). We can add ACLs to control who can read/write topics. It’s up to you do subscribe to categories and tags you’re interested in. You can also navigate through the preferences to decide what kind of landing page you prefer.

I don’t really find the current categories, all that useful which is why I never really bothered using them, that in and of itself doesn’t mean that categories can’t be useful.

There’s some prior art that would probably be worth taking a glance at.

I think having some form of Ask category would be a good idea, trying to separate the categories based on target audience would also be wise.

Brainstorm isn’t that crazy an idea to me either, a thread started there is not likely to be a query that needs to be solved(what ask category should be for).

There are empty gitlab repo’s which would be better served on discourse instead, like app ideas, whiteboards, etc

If you want people to come to discourse first instead of going straight to an issue tracker then these kind of repo’s send the wrong message.

So yeah, that’s my 2 cents, I think that the categories could be reoriented to help contributors surface queries better and collectively contribute to solving them.

I think that maybe with a bit of restructuring it could prove to be a useful silo of information to build on from a documentation perspective.

P.S. thanks for all of the time and work you have put into discourse thus far ebassi, its much appreciated.

1 Like

Thank you for all your work over those years, ebassi! I want you to know that it is greatly appreciated.

“Intuitive” is not a thing that I care about: there’s nothing inherently “intuitive” in a category named “Brainstorm” compared to one named “Desktop”.

Yes, but if you’re a new user who wants to ask a question, a category named “Help” is nice place to go. You said that generally categories aren’t used. I have no reason to disagree on that, but I still think it can be useful to improve them.

I also think that things that should be on Discourse, aren’t. Like when someone is asking for design team to design something, they go to Design room on Matrix. But imo chat is awful for this, since its very easy for these requests to get lost. Discourse would be perfect for this, every request would in the open and it would be easy to track them.

Or as oillipheist said, empty gitlab repos like app ideas or whiteboard could be as well turned into Discourse categories (or sub-caterogies that would fall under category like Brainstorm or Design, for example). If we want to get people to use Discourse, then the best way to do that is to “force” them (by offering people something that Matrix or Gitlab doesnt).

My current idea on categories and their sorting looks sorta like this:

Help, a place for people to ask questions
Applications
Platform
Brainstorm, for discussing potential features or potential applications (something like App Ideas repo on Gitlab)
Design, for request to design team or mockups
Community
Local Communities, renamed International category (i also like how tags for local communities look like on KDE Discuss, can we have something similar?)
Site Feedback
Infrastructure

Maybe we could also combine Desktop and Applications categories into single Development one?