Revisiting subcategories

Continuing the discussion from Permissions change?:

The question is what we are trying to achieve with the sub-categories? House-keeping? Sorting?

and

We discussed that in the first days. The outcome was: it is useless to have a bunch of specialized categories. After all, for instance: if I encounter an issue on Silverblue but related to GNOME, the post should go under the first category or is it suitable for every category? […] If someoune want to be more specific, there are the tags.

Which I don’t disagree with.

I do wonder if it’s useful to split up “Troubleshooting / Crashes / Bad behavior” from “How do I do this thing?” kind of topics. A lot of the former tend to be very specific to one user in one situation, and require a different approach and sort of knowledge. They’re also more likely to expire as they’re resolved by software updates.

It’s possible to change (personal per-user) notification settings on a per-category basis. I don’t think that’s can be done with tags. So that might be one reason for a separate category.

Also, Categories can have default templates for posts. This might be particularly useful for troubleshooting questions.

3 Likes

@mattdm this was the principle: [1]

  • Level 1 asks: what are you doing? Are you installing, or customising, or using, or upgrading a Fedora installation?

  • Level 2 tries to be more specific, for example, asking: are you on a Desktop, or a Server, or using Containers, or the Cloud, or some other platform?

Announcements: for community announcements. Here, new topics require moderator approval. Ideally, this category should only be used for announcements, and it is left to the moderators to close topics to further replies as needed.

  • Installing Fedora: for queries relating to the installation of a new Fedora system.
    ** General: for normal/usual installations using the standard installation media provided by the community.
    ** Advanced: for advanced installation such as the use of kickstart files, advanced disc organisation, and so on.
    ** Hardware: for hardware related queries.
  • Customising a Fedora installation: for queries relating to the personalisation of default installs to suit users.
    ** General: for queries relating to customisation using tools provided by the community, such as adding or removing software via a package manager.
    ** Advanced: for queries relating to more complex customisations which may include, for example, installing software from source.
  • Using Fedora: for queries related to the daily usage of an installed and personalised Fedora installation.
    ** On a Desktop: for queries related to an installation on a workstation or a laptop, and includes the various Desktop Environments.
    ** On a Server: for queries related to a Fedora Server Installation.
    ** With Containers: for queries related to the use of Fedora with Container technology.
    ** On the Cloud: for queries related to the use of Fedora with Cloud technology.
    ** Other platforms: for queries related to other platforms.
  • Upgrading a Fedora installation: for queries related to upgrading to newer Fedora releases.
    ** Using DNF: for queries related to the use of the suggested DNF upgrade method.
    ** Using other tools: for queries related to upgrading Fedora systems using any other methods.

And yes of course we took in count some sites like mandriva not manjaro site because it is not multilingual site (however hoe old is it? maybe 1 year, they don’t separate into sub-categories in Language Category [2]…

you can see the track here and all the worked done:

[1] https://pagure.io/Ask-Fedora-SOP-docs/commits/master

[2] https://pagure.io/fedora-join/Fedora-Join/issues?status=Closed&tags=C%3A+AskFedora&close_status=

References

Regards.,

2 Likes

Notifications can also be managed by tags:

The idea with the sub-categories (for Discourse was limited to 2 levels back then—not checked if that is still the case), as @hhlp has documented was to help direct users to the right place to ask their questions. There’s really not much more. There are different organisational systems and after lots of discussion, we decided it was best to keep categories broad and simple.

@florian: we didn’t want to have per product/edition categories because lots of things overlap and then it just causes confusion for users. It also isn’t clear on what basis this distinction should be made: spins? But generally, the component causing issues only becomes known after we diagnose issues. So even if a user puts something under “KDE”, it could end up being a kernel issue affecting everyone in general—not following the intention of the categories.

So, we said, let it be two broad categories: if you’re using/customising, go here…, if you are installing/upgrading go here…

In general, what is the intention of revisiting subcategories—is there an issue we’re looking to solve?

2 Likes

I did notice the default templates—I don’t know if that’s a new feature. We could have something simple set up there to encourage users to give us some basic info about their systems—a subset of what fpaste --sysinfo provides, perhaps.

I think the categories and subcategories should be more dynamical defined and sorted, whenever it’s possible automatically( Deep learning mechanism through the system) . A modern database like IBM’S DB2 supports such things.I assume that the background-system of this forum is database driven.
A simpler way to manage it, is the possibility to recategorize a posting through the moderator and/or the poster. A static given category at posting time for a dynamic process (e.g. support) makes it impossible to stay clear and clean and this can be observed sometimes in this forum. The ideal should be a sound and actual knowledge-base for Fedora and it’s different “flavours”.

Not really — I just wanted to check in to make sure it’s working, and to see if there are any emerging patterns that we see.

2 Likes

Thanks. That’s good to know, but this is clearly overkill and not possible for us to do. First, we don’t host the site, Discourse hosts it for us. So we do not have access to the database, and do not have a say in how Discourse sets up their infrastructure. (We don’t want to have a say, we only want to use the platform—that’s the point of paying Discourse to manage it all)

Even if we did have all of this, I still wouldn’t think diving into Deep Learning is the best use of the limited resources at our disposal. If Discourse adds this feature and we can enable it with a click in the admin panel, fine. Otherwise, -1.

go deeper:

About Discourse, perse:

  • Discourse is a complete open source, everyone is welcome to hack…
  • Database system in under progrestSQL
  • if you’re well enough in webdeveloper, you have a knowledge all the stuff that a web developer should know, I’m sure they will give you a warm Welcome!.
    • Ruby and Rails too
    • JavaScript
    • HTML
    • Handlebars
    • SCSS
    • CSS
    • Shell

About the Site:

  • neither fedora nor redhat host the site is a paid subcription in upstream and live inside a container.
  • We don’t have acces to the system in any ways.

About your Question:

  • You’re suggestion a complete revmap on how discourse works… and that work should be done on Discourse.

Regards.,