Considering a general reorganization of this site!

The category layout we have now for Fedora Discussions isn’t horrible, but it’s also basically unchanged from what we came up with completely arbitrarily as “sure, sounds good” when we were first launching the site. Two years later, I think it’s worth thinking about that more intentionally.

The current basic structure divides things into:

  • Social conversations
  • Desktop Fedora Linux topics
  • Not-Desktop Fedora Linux topics
  • Project Conversations (basically, “Fedora”, not “Fedora Linux”)
  • Special Interest Groups (very murky vs the above)
  • Site Feedback

(Plus also there is the hidden-by-default #projects-in-copr category.)

I think we probably could do better. What should this look like as the site grows?


This same thing applies to Fedora Chat, where (following the same "we make up some initial structure based on best guesses at the time) we have:

  • Welcome
  • Conversations (both social and technical — user-help — are grouped here)
  • Project Teams (right now a flat space, but we might restructure to match the org chart, with a Mindshare/Engineering split).
  • Meetings (probably not relevant here)
  • Bot Chatter (ditto, although I guess we could have some for things like the compose check report messages which annoy me on devel-list)
  • The Earth – global-regional user/contributor community channels

Since Chat and Discussion are two different modes of conversation (sync and async), they don’t necessarily need to follow the same pattern, but it seems like some parallel would make sense.

Since this is the site for project conversations (user questions should go to Ask site), I’d prefer if we structure it around working groups and sub projects. I’d say it even is less important what the exact structure is, than that the structure of the forum is consistent with the structure of the project we explain in various other places, for example in the orgchart or on a Matrix server.

The Desktop vs non-Desktop separation doesn’t fit into any of our org structures, so I would get rid of it.

Yeah. I think that was definitely created with “user forum” more in mind, and at the time it wasn’t quite clear if Ask was going to be successful on Discourse or not. Now that the answer to that is “definitively yes”, I think rearranging with a contributor-project focus in mind is the obvious right thing to do.

The main catch is: discourse doesn’t do deep nesting, as part of its design philosophy. And it’s not great with dozens of subcategories. (The suggestion is to use tags, but I don’t think that really fits our reason for categorizing, which is team focused rather than, say, feature focused.)

I think the number of top-level categories (5 + site feedback) is about right. Could do one fewer or one more. One idea:

  • Welcome
    This would have some “Getting Started” posts, mostly about Discourse (like Guide to interacting with this site by email) but at least one pointing to Fedora Join and other “getting started with the Fedora Project” info. Plus, two subcategories:
    • Fedora Project Announcements
    • Introduce yourself!
    • Site Feedback
  • General Conversations
    • Fedora Council Discussion
    • Off-Topic Fun
    • Off-topic Tech
  • Mindshare Teams
    Each of Mindshare Teams and Engineering Teams would also get a top-level wiki posts explaining that not all teams use discourse for discussion, with a pointer to Available lists - Fedora Mailing-Lists (and maybe to individual team comms, although continue to be skeptical about our ability to keep such a list up to date despite best intentions).
    • Classroom
    • Community Blog
    • CommOps
    • Magazine
    • Podcast
    • Program Management
    • Chat (Matrix) ( ← need to figure out non-confusing way to name this)
  • Engineering Teams (Or, tech teams, or something?)
    • Websites & Apps
    • Gaming
    • Workstation
    • Silverblue
    • Kinoite
    • CoreOS
    • IoT
    • Containers (note: seems inactive)
    • Copr
    • Go
    • Rust
    • Haskell
    • RPM Packaging

… but I think that makes Mindshare and Engineering to be Kind of Big Lists (especially as more teams get interested). I think maybe an additional split of each Mindshare and Engineering would do it, but I’m not sure what lines those splits would be along.

On the other hand, General Conversations and Welcome could probably be combined somehow.

I actually have the same feedback as @bookwar!

To me, these categories are the crux of activity on discussion.fp.o. I am happy with the way they present now, but perhaps shifting them to better match the org chart could make more sense.

Probably the “easiest” change we could make here would be to move those three categories higher up on the page?

I do feel that these categories are a better fit for Ask Fedora, but I also haven’t spent a lot of time in those categories or kept up with conversations there. While I don’t think we could jump to remove them since there are people who use these categories daily, maybe we could do some community polling about merging the user-focused parts of this forum into Ask Fedora, and increasing the emphasis of this site as a place for regular contributions across the org chart (i.e. engineering-oriented and mindshare-oriented teams).

The suggestion is to use tags, but I don’t think that really fits our reason for categorizing, which is team focused rather than, say, feature focused.)

I would actually try that.

Separating each individual team into a dedicated mailing lists or categories has its benefits but it also creates a more closed environment. And adds problems like: what do I do if I have a cross-team question?

So even on a mailing lists level there are attempts to switch from mailing list per group model to a one mailing list with tags. I saw this approach in action in Openstack Development mailing list and it worked quite nicely: every subproject has its own personal tag, and then you can add as many tags as you need to a mail to discuss a certain topic.

We already try to do the same in fedora-devel sometimes, when we apply [ELN] tag to discuss the ELN specific question without getting off the main list. And for smaller SIGs it is a preferred way.

1 Like

+1 on this for sure.

(Re: tags)

Okay, I’m open minded here. I definitely feel the frustration of cross-posting, and tags neatly solve that.

We can make categories require posts be tagged, with at least N tags from a “tag group” (a set of tags we define). Can you give a picture of what the category organization might look like with this idea? And, if we’d have mandatory tags in some categories what they might be?

Note that Discourse makes it easy to filter by tag, and users can auto-watch certain tags, or mute notifications for topics with given tags. For folks who prefer to interact via email, the process would be to add tags to the “Watched” list (just like subscribing to the relevant messages) and changing the email notification setting to “Always”.

For people are dubious, by the way, Discourse has a rather spirited defense of the idea here: It’s Time We Talked About Tags, and for anyone who really wants to geek out, Shirky: Ontology is Overrated -- Categories, Links, and Tags.

Preserving categories is an important way for me as a way to reduce cognitive load. Tags may make sense for lists and Ask, but I believe discussion.fp.o is a different case.

On a mailing list, this was tedious. You had to first subscribe to all the mailing lists individually you wanted to contact. That also meant usually you obtained their list’s traffic and had to either read it, filter it, or ignore it. It could be mildly inconvenient for high-traffic lists.

On Discourse, from the web interface, it is easy to choose where you want a post to go, and even to have it moved somewhere else retroactively if it is a better fit. Clicking in one post can easily allow you to create a “forked” conversation somewhere else on the forum. I think this is a useful way to avoid conversation silos.

If using Discourse from a mail client, the best practice might be to turn on mailing list mode in individual user preferences and create custom filters, or to subscribe to specific categories. If a tag becomes popular or gets widely used, someone will not know unless they remember to update their Discourse preferences from the web interface to subscribe to a new tag.

This makes sense for a high-traffic mailing list and you can utilize mail filters to follow common topics. But maybe the sub-team or sub-topic tags could be mapped to a new or existing Discourse category instead? Like how the Program Management Team category fits underneath the Project Conversations category and so forth.

For the non tagged approach, here’s a suggestion / idea I got from Discourse support to help reduce the visual/mental load of potentially dozens of subcategories. We could mute all of those subcategories by default, which would hide them from the top-level / front page view except for people who intentionally unmute them. (Like subscribing to the list, basically.)

Muted subcategories still show up in the boxes at the top of a category, if that is enabled. Right now for demo purposes see

I think this is probably a good approach, and makes me less concerned about stuffing a bunch of subcategories in one place.

1 Like

One thing to maybe be aware of with that last view – the “no subcategory view” – is that it is extremely easy to click on a conversation and jump in without realizing “where” you are. I’ve done that several times already because I have my default view set to “latest”. I jumped in on multiple council discussions without realizing that it was meant only for council members (sorry about that BTW). Can subcategories be set read-only for all except a certain group?

Categories can be set that way, but actually the Council Discussion category is meant for wider community input too. So that’s fine!

I do agree that the “where” feedback the software provides is pretty subtle. I think it’s part of the general design conception that is opposed to deep or strong hierarchy. We could do some theming stuff to make the appearance of different categories stronger, but I haven’t felt it to be a big problem in practice.

1 Like

I consider this as a positive impact of the non-categorized view. In this particular example I think that Council Discussions is not discussion by the Council it is Discussions with the Council.

Because we used a separate mailing list before, these discussions never really happened with wider community participation, even though we several times tried to explicitly invite community to it. And now it just happens automatically :slight_smile:

We may want to consider better color-coding and naming schema for labels though. Right now it seems we assign color more or less randomly, but we may develop some system and represent certain type of labels by it.

1 Like

Yes, I can confirm that this is the current process. :slight_smile:

Color-coding and consistent symbology / etc is something that @MadelinePeck is working on right now. If you’d like to switch up the categories / basical organizational structure you’ll want to keep her in the loop. She’s using the coloring coding system of the Fedora Badges as a baseline.
(Quick edit to say, her work is for the chat server but could apply here too)


We can make categories require posts be tagged, with at least N tags from a “tag group” (a set of tags we define). Can you give a picture of what the category organization might look like with this idea? And, if we’d have mandatory tags in some categories what they might be?

This is the dump of what I have in mind right now:

  - Welcome
  - Everything
  - Off-topic Tech
  - Off-topic Fun

Service desk
- Announcements
- Site feedback & requests
- FAQ and Help

Project Discussions
- Engineering
    Labels: cloud-sig, workstation-wg, spins-sig, qa-team, infra-team,..
- Mindshare
    Labels: join-sig, docs-team,marketing-team...
- Other

Project Work
- Fedora Magazine articles review

That last section came from realization that Magazine folks use forum differently from other teams.

Thus if we have shared space with labels for discussions, we also need a separate category in case team uses it for a very specific custom workflow which the group manages.

The audience for the “Project work” category would be different from a Project discussions. We may want to even remove it from default “top” and “latest” listings, so that only people who got into SIG work through the discussion and SIG docs know that they should explicitly subscribe to the category if they participate in the specific type of work.

1 Like

If the noise from the magazine proposals is too much for this site, we can switch to using pagure for the proposals. In fact, we might anyway. If we do, then I expect the magazine category would mainly be a wiki style post with a link to the new proposals system (

It’s no problem — Discourse supports this easily. As @bookwar says we can set up the category in a distinct way with its own rules, and if it gets disruptive we can block it from showing up at the higher levels.

No, I don’t think it is a problem which needs to be solved. I think it is good for teams to find whatever way works for them. And I see how Discourse platform can be very useful in accommodating different workflows.

I was just thinking that the one use case where category is definitely preferred over labeling is where posts require special treatment:

You don’t want random folks to discuss the article review before it is published in the community blog. You want the dedicated team of editors to work on the thread according to the defined process. That’s why it goes into a separate category with its own rules.

So basically:

  • Category = set of rules
  • Label = topics and themes

You can not have overlapping categories as the rules will be mixed and unclear. But you can have one thread to cover multiple topics, thus labelled with multiple labels.

It’d be nice to have a test instance to set this up to see how it goes. In your picture, would we make choosing (at least) one of those labels mandatory for the category?