Originally we were going to have the projects at the root, and whatever sub they need below.
So like for example:
pgrouting
pgrouting-dev
pgrouting-users
QGIS
various language specific user groups
main user group
main develop group
But one of the main reasons for that is that we were limited to 2 levels down, but I discovered that this is just a setting in the config (largely undocumented) because they don’t want people doing it. So I changed the max level to 3.
For some reason they decide 2 levels is the best way to prevent user overload.
Still though perhaps 2 levels down is still preferable and easiest for end users to grok.
pgrouting-users and pgrouting-dev are separate lists.
Just as postgis has a postgis-users, postgis-develop
One is for users using the system and another is for those trying to add new functionality or questions about how to add functionality. I think that is a common structure for many projects.
QGIS is a much more complicated beast and has way more sub categorizations.
I’m leaning toward projects should be at the root and then can subcategorize their category however they want.
Regarding SAC, to be honest, I’m pretty indifferent about where that lives. I’d be fine with it being in some committee sub category, and agree all committees can go under some umbrella called “Committees” and now that we have 3 levels, we could still keep a SAC category under Committees with subs for SAC-tickets, SAC-announcements, SAC discuss.
In my humble opinion, it would indeed be better to organize the categories at the top level. We will get quickly lost (if it’s not already the case) when the amount of root categories will increase.
It’s confusing to find
projects
general
local chapter
GFOSS.it (which is a local chapter isn’t it ?)
initiatives
and so on at the same level.
I would go for a cleaner root overview like
projects
local chapters
and other root categories to handle admin stuff, initiatives and son on.
Thanks for engaging on this topic @robe, the point about QGIS making sense top-level due to number of sublists is valid. And if one project is top-level then it makes sense for all projects to be top-level as they are what we are promoting yeah?
Even for a project like geonetwork we are proposing:
geonetwork - top-level category
geonetwork/user
geonetwork/user-ui - considered for geonetwork-ui project
geonetwork/user-fr
geonetwork/user-es
geonetwork/user-fr
geonetwork/devel
geonetwork/devel-ui - considered for geonetwork-ui project
Previous additionl notifications were available via geonetwork-commit but I do not think those make sense with a discourse setup. Git repositories provide decent options for commit notifications.
So I think that top-level for projects smaller than QGIS also makes sense?
One final question (from me) - if we move categories around does it effect those signed up to notifications as an email list group thing?
I do not have great visibility on how the relationship between groups and categories works (for projects wishing to preserve an email experience for async communication).
(also do we sign discourse comments? or is that redundant)
The email address a list listens to is what we set in the category config so has nothing to do with it’s location in a hierarchy.
Any threads by email go strictly by the thread id (the thread has an email address).
Things like watching a group and permissions are internally defined by the category ids and category ids don’t change when you shuffle them around.
The only things I think moving categories around affects, is the path to them navigating via web. But even that I think there is a place in discourse to define mapping urls, so I think a category can be referenced by more than one link. That part I have to check up on, but I recall seeing that in admin somewhere.
The category / group connection is the least intuitive for me on discourse and I think it can be improved. Like for example a group admin should be able to control a category in my mind (e.g. change the name, upload a logo etc), but only admins can do that. The only connection between a category and group is that you can designate a specific group as the a group that see / post / reply in a category and you can also auto watch categories for a person when they join a group or have exclusive groups that are by invitation only so that means you can have people be able to view categories by invitation only (based on their groups)
That feature is nice in some ways, for example you could have a geonetwork users group and allow anyone in that group to post to any category under geonetwork parent category. If they don’t want to watch a specific category they can unwatch those.
Thanks for all contributions to this topic. I like the idea of projects at the top level, but since they are so many and they mingle with Committees and other categories, the home page becomes a mess.
So I can think of two ways to clean this up:
1- Projects would be displayed in a separate section on the home page (some kind of a break between projects (QGIS, GeoServer, MapServer, PgRouting, GeoNetwork and so on) and a section with Local Chapters, Committees, General, Website etc.
2- Have a Projects top level anyway with all projects underneath.
I am happy that categories can be moved over time so we do not have to get this perfect right away so we can concentrate on migrating projects that wish to make the change.
I expect that long term we will have “osgeo-projects” and “community-projects” top-level categories, and that “qgis” will move …
