At the recent annual OSeMOSYS steering committee meeting, we discussed the option of moving the current OSeMOSYS discussion forum over to the openmod forum. @ludwig.huelk and I discussed this briefly at the Vienna openmod in March '23.
The current Google Groups solution is not really working for us. We’d be interested in migrating existing messages over the openmod Discourse, if that is possible, and setting up a minimal number of categories to help manage the different types of messages.
Any thoughts as to how feasible and desirable this would be for openmod? Obviously OSeMOSYS has a large user group, so it would be great to introduce those users to the broader openmod community as well.
I’ll respond under two hats. First, as a regular member of this community, I am very comfortable with the idea. The oemof project, for example, has 161 topics (or pages) listed under their oemof tag. And this recent thread on a potential new feature is a good example of how things can and should work.
And second, as lead admin on the forum, I am happy to help out with the migration. The Discourse development team runs a forum of course and there are many threads there about migrating content from all manner of other platforms and services.
Setting up a dedicated category and a set of sub‑categories should be straightforward. Category‑specific moderation is now supported. (Perhaps we should do this for oemof as well, they currently operate under the Q&A category.)
Private topics are possible, should that be necessary.
To note that I find admin’ing Discourse to be quite satisfying. The software is certainly well designed and quite mature now. Communiteq, who provide our commercial hosting, are also great to deal with.
Any thoughts from others in this community? Feel free to offer your views — be they for or against. R
I think the overall benefits for the community would be positive, and there’s plenty of relevant content in the OSeMOSYS archives.
According to this post, it looks as though there’s already a solid set of tools to migrate the messages over. I’m not sure how you’d import the messages to an existing Discourse instance, but it seems very flexible.
Could we arrange a quick meeting to talk this through?
Personally, I find offering “all” model support over openmod not suitable (incl. oemof) and might discourage the openmod use in mid-term. Not sure how others feel about that. The problems when more and more models offer support over openmod:
Support spam. I get weekly openmod updates and need to filter out non-oemof support stuff (imagine this is growing with other models → we have 10-20 support questions per week. I can imagine OSeMOSYS might have more)
When being on openmod and checking out the overview of “topics” the default is “all tags” and “all categories”. Again, understanding what is not model support relevant will become more difficult.
I think the forum is better suited for asking questions if the own support group cannot help/ or to share new features/ new data etc.
Maybe there are solutions to avoid certain model support tags from these overviews per default. This would avoid support spam & enable modelling groups to access the discussion over the tags. Until this is not possible, I would prefer that modelling groups just have their own support forum. Suitable solutions:
Hi @MaxParzen Just to let you know that Tom Brown and I had this same debate near the beginning of the forum (when it ran from Tom’s hardware). Tom opted to provide support and I have followed that policy since. Overall, it is a community decision. But I feel as lead admin I should follow and not lead in this context. So I very much welcome such discussion. R
Just to clarify. I would highly welcome that all models can host their support on openmod. Just finding a solution to the above challenges is required, in my opinion. Maybe someone can find solutions/ explore what is possible. Hope we find something
Discourse can certainly scale to meet that kind of traffic. So it is essentially a question of the organization and configuration of the site. More thought needed in that regard. Anyone else wish to chip in with their views and opinions on these matters? R
On the current OSeMOSYS forum there are different types of messages all bundled into one forum - exactly the mess we’d like to (and could) avoid on Discourse.
The rough categories are:
Course-related
“How do I complete OSeMOSYS exercise x in course y?”
General energy systems modelling related
“Can I do this … with OSeMOSYS?”
“How can I model a pumped hydro plant in OSeMOSYS?”
OSeMOSYS specific
“Help! I can’t get my model to run”
“I’ve been trying to do this … here’s an example… and now I’m stuck.”
The course-related topics should not spam all users; general topics are relevant for all of openmod; and this is one of the benefits we see of bringing the OSeMOSYS community to openmod; OSeMOSYS specific questions may be of interest, but are probably less interesting to all.
@robbie.morrison - any suggestions for how to handle this? Active moderation? Tags or categories to filter messages - so only general topics are shared broadly (all will be publicly viewable)?
Hi @willu47 I will need to explore the Discourse software meta forum to see which features can assist and how they might be arranged to advantage. Thanks for providing some context too. That effort will be over this coming weekend. R
We discussed this at the beginning and I wasn’t super happy about the support for models running over the forum (unless ALL models do it). We tolerated it with oemof to see how it goes. The argument against is that having 1-2 models running support over the forum looks like an endorsement by openmod, especially since both have open energy in their names. Whereas openmod should stay model neutral and focus on model-overarching stuff (although of course announcements about models and workshops is fine). Also people coming here to find out about openmod find primarily information about oemof. Separate websites for each project would make more sense to me.
@tom_brown - Can we then agree on a compromise where we develop a separate category for “model support” posts for oemof and OSeMOSYS (and REMix judging by their recent mailing) which ensures that users are not spammed by default with the potentially large volume of messages?
I don’t see why anyone would deem openmod to endorse a model through association.
Finally, this seems to be one step towards achieving a critical mass of “model support” via openmod. I hope that other models will follow.
A few thoughts. You can add AMIRIS to the list of projects currently using this forum for support.
And I think that we, as a community, can make it quite clear that there is no endorsement through association by seeking support here. Indeed, projects that run their own venues (say using Discord) are welcome to provide a stub on the forum back to their dedicated channels and locations. Indeed all projects will have backrooms somewhere.
In terms of architecture, I have been pondering on whether to opt for Discourse categories or a stand‑alone Discourse forum with shared membership (and also trying not to dwell on the Instagram/Threads fiasco in the process!). From a maintenance perspective, two separated sites could be preferable, in the sense that the lines of responsibility are clear and physical.
From a social perspective though, I think categories are a better option. Very recent traffic on this forum that explored the similarities and differences between two frameworks (oemof and REMix as it happens) would not have been as spontaneous across two different sites. Issues related to maintenance overheads and the demarcation of responsibilities can be handled using categories too. For instance, category‑specific moderation is now supported by Discourse. Users can opt to suppress categories too, if too much support‑related traffic develops, against their liking.
On the other hand, I do notice that some information exchange on framework‑specific channels would be of wider interest to this community (and I am not suggesting this practice is strategic in any sense, just a reflection of where people gather and interact).
How do we want to proceed? Just stumble along — in which case, I can set up some categories and approve some moderators. Or would some kind of more considered and collective approach be better? And in the process, provide more oversight than the ad‑hoc admin currently metered out by myself and @leonhard.hofbauer. Any further ideas or reactions, R
This thread looks helpful: Muted Default Categories Not Working - #4 by Sentinelrv - support - Discourse Meta Someone was running a discourse group and muted the Discourse category “advertisement” per default such that it won’t appear in the “lastest”. The admin can do that for existing and future users. Probably we can apply that for any model support channel?
Hi @MaxParzen That is useful. This morning, I have been looking at various features around categories, subcategories, groups, and trust‑levels to see how these can patch together to provide what we might need. R
