I know the installer doesn’t do upgrades anymore and hasn’t for a long time, but these still seem like related concerns which perhaps could be put together.
Hrm, but fresh installs and upgrades are complete different processes and tend to cause different issues. Questions regarding installation will encompass all installation cases: spins/labs/hardware/netinstalls/kickstarts/disc partitioning and so on which will generally be very very focussed on anaconda. Upgrades will rarely touch on these, unless someone tries to do something rather advanced like modify their disc partitioning. In such cases, though, fresh installs are usually the suggested approach anyway.
It all boiled down from us trying to match our categories to the lifecycle of a fedora installation: fresh install, customisation, usage, upgrades.
What do you think?
Edit: afterthought: given that installations and upgrades will both happen mostly around a new Fedora release, it may be a bit much to manage the incoming flood of questions if they all go to one category?
I can see the lifecycle point. I was just kind of thinking in terms of granularity — customizing KDE menus and customizing CoreOS are pretty far apart but in the same bucket here, and so install and upgrades seemed like both “smaller” categories. But maybe not!
Thinking about this a bit more as I read the Getting Started post. It’s all a cycle, right? We can think of upgrading as the last stage in the process, or else it’s the beginning of using a new release. And in fact, both upgrading and installing are ways to start with a new release.
Ah! I figured out why I don’t like it. It makes me feel like these two activities get more apparent weight than I’d like them to from a pure marketing perspective.I mean, I want it to be easy for people to get help with them, and it’s true that they’re areas where people are likely to need help, but I don’t like the narrative that Fedora is all about installing and upgrading. One might spend an hour installing, and half an hour upgrading once or twice a year. That’s 2 hours out of 8760, so it seems wrong to give them 2 out of 4 categories.
So that’s my argument. I’ll let you all decide if it’s convincing.
Sure. I honestly don’t think the categories matter much. We could combine “installation/customisation/upgrades” into one really, and leave “using” as the main other category if that’ll work better from a marketing perspective?
The current categories were based on the tools that they’re likely to involve. Installation is very very anaconda specific, while upgrading doesn’t use anaconda at all—it’s either DNF-system-upgrade/Gnome-software or another gui that we support/people using plain dnf updates. Similarly, customising systems is most likely to involve installing/removing packages via whatever tools and lots of cosmetic changes that people do with extensions and themes and what not.
So if we combine installing and upgrading, we’re going to get anaconda and dnf-upgrade queries in the same place. I guess it’d have been perfect if we had another category level. We could then have had “using” and “setting up” as main categories, and then “install/upgrade/customise” as sub-categories in the latter.
Should we do:
- using fedora
- setting up (installing/customising/upgrading) Fedora
as two main categories?
Never it’s bad idea keep the things simple , +1 for two main categories
I liked very much the idea of the categories related to the lifecycle (install -> customize -> use -> upgrade).
BTW not having the subcategories anymore, it is also true that this categorization is a bit incomplete and confusing.
At the end of the day, having less categories is fine an less confusing.
My suggestions are
- installing and upgrading
- using and troubleshooting
As I think about this even more and drink coffee, use of a system rarely fits into the neat pattern of “install, configure, use”. Rather, it’s “get it going, and then start using, and then figure out something you want different, then use some more, then run into a problem, fix that, get back to work…”
Sounds good. Let’s update them categories everyone!
Cool. I also think it’s good to start with fewer categories. As the site grows, we can add more if we need 'em.
I agree with fewer categories, but I wonder what our goals are. Without clear goals, it is not easy to say how many categories is better. We can even go without any sub-categories and use tagging in these cases too.
I completely agree with NOT grouping customization with install/upgrade.
About adding categories later, it is not easy unless we don’t want to move old topics to new categories or when we effectively convert a tag to a sub-category (assuming that it is easy to move all topics with a specific tag to a new category)
Thinking a bit more, I decided to ask this question (again?):
Who are we going to help with these categories? We have (at least) 3 users: A: Who wants to ask; B: Who answers; C: Who searches for some info
My opinion: these don’t help A. it is just an overhead for A.
Might help some B users, but I doubt we have any/many who prefer to only see install or usage questions but not the other.
And for C, I’d guess that since the number of topics in a sub-category are big, C will mostly need a powerful search feature and tags can be much more useful than two or three general categories.
So… looking at the Announcements category, it is clearly different. So, I’d say:
- Fedora Q/A
I’m not sure, but we might find other useful categories like above to add. As an example, a “how to” category might be useful for general howto docs which can be completed/updated over time by people (and might finally graduate to quick-docs for example!)
The goal is to loosely organise questions while not organising too much which may confuse users.
Like the start here post says, these are not set in stone and it is up to users to decide what category to choose.
For A: no, one click to choose a category doesnt really count as “overhead” in my book.
For B: irrespective of categories, they will use the “latest” and other views that list posts. That doesnt really mean no categorisation is needed.
For C: you can limit searches to posts within a category
Ah, so merge the two troubleshooting categories into one? Fine, but we wont call it Q/A. First, that makes lots of community folks think of testing (QA), and second, we dont want to make users think that this is a Q&A platform either. Let’s go with “troubleshooting” as @not-mattdm-at-all suggested?
What if we do:
- troubleshooting in English: using, installing+upgrading
- … Spanish… (etc)
and we use the top level language categories for announcements (anyone can post, but posts here will require staff approval like the announce mailing lists?)
So the subcategories are clearly for troubleshooting, and we still have two very broad subcategories, and we dont waste the top level language category either?
I’ve now updated the English category:
- the top level category is meant for announcements and is moderated. (I’ve also mentioned this in the about post).
- the two sub-categories are our main use oriented categories.
Similarly, I’ve also tweaked the Community category:
- the top level category is for general discussions about the community
- the “on contributing…” sub-category is for contribution related discussions.
Then we can close this topic too
Spanish are ready all fixed now
Persian categories are now synced
Italian is in sync too
All categories are ready. Closing this topic now.