How would you like to add new categories for projects or committees?

I recently helped setup committee/`marketing`` and have prepared proposals for:

In both cases these projects use SourceForge email lists so they can migrate content (but not contact details).

I am anticipating setting up:

  • projects/geoserver
  • projects/geonetwork

But I am a bit confused by the top-level QGIS and SAC topics?

What is the plan / guidance for discourse categories?

I don’t think we’ve settled on one to be honest.

Originally we were going to have the projects at the root, and whatever sub they need below.

So like for example:

  • pgrouting

  • 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.

So I’d lean toward, projects being at root

  • root




        whatever levels

Could I recommend that a structure be established before inviting more groups here!

My own take that these tradeoffs are the usual public / private

  • If it is public facing content “QGIS”, “GeoServer” and “GeoNetwork” make sense top-level
  • If it is for “internal” list-serve style content then “committee/system admin” and “committee/marketing” makes sense.
  • Top-level “SAC” does not make sense (is not friendly) for anyone :stuck_out_tongue:
  • I do not think we need duplication (pgrouting/pgrouting-users, pgrouting/pgrouting-dev …)? Or did I not understand your example…

Still I will take the insight about two or three levels back to the geonetwork proposal where @ticheler wished to know the structure.

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.

1 Like

Hi there, thanks for raising up the topic.

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
  • (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.


I kind of like projects at the top, but the others I’m in agreement.

Maybe it’s because we don’t have that many projects yet.

I have moved SAC under Committees.

I think my main issue with projects, is mostly QGIS. QGIS is so big, that stuffing it under a projects category feels too deep.

The other projects I think have such few sub mailing lists that I’d be fine with that.

1 Like

I have also moved OSGeoLive since that is not too big yet and main part has not yet migrated for mailman.

Thanks for all the updates! I was not sure if OSGeo Live is an initiative, project or committee?

My understanding is that it has been all three over the course of its life and became an OSGeo project (which is a committee technically).

Checking on Board and Officers - OSGeo list shows an ISGeo Live project officer :slight_smile:

Checking OSGeoLive Initiative - OSGeo shows OSGeo Live as an initiative

Checking Committees - OSGeo here does not list OSGeo Live.

This may be an identity question for the OSGeo Live team more than a question of how to set discourse …

Yah we could always move it elsewhere. It’s not being used much anyway aside from translation. @kalxas @cvvergara @astrid_emde @darkblueb

Have any opinion on where OSGeoLive falls in the Project vs. Initiative spectrum.

I’ve always thought of it as a Committee/Initiative cause it really services all other projects.

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?

Exactly that is what I was thinking.


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)


My understanding is no, because

  • 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.

1 Like

What about…


1 Like