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.
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.
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”.
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
Project Discussion - Fedora Discussion (“rows” view enabled; note that this really needs some consistency with icons for different categories! I’ll put that on my todo list)
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.
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
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.
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 fedora.im 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:
Generic
- 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
council
devel
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.
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 (pagure.io/fedora-magazine-newroom).
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?
