Restructuring the forums: pre-proposal

Following the discussion on use cases people have for the forums (at Restructuring The Forums - Kick-off), this is my current thinking on how to best restructure the forums. I hope to collect feedback on those thoughts and then start a new topic with final proposal for discussion and final approval.

The general idea is to make the structure of the categories much more aligned with the use cases. And then some other less radical changes.

I would propose to change our categories to:

  • Installation
    • Windows
    • Unix
    • Mac
  • Getting Help
  • Developers
  • Announcements
  • Publicity
  • Jobs
  • Community

It is IMHO important to reduce the number of categories as too many categories make creating new posts a bit confusing and a bunch of the categories are rarely used anyway. I would also emphasize that the structure is mostly not to aid searching, but to let people follow/watch/mute categories they are/aren’t interested in and thus have a better experience when just visiting the forums.

We currently have a few restricted categories (e.g. Stan Development Team only). I think discussion on which of those to keep is a bit separate and also they don’t clutter the forum content (as they are visible to only a small fraction of users, who already know how Discourse works), so I don’t see any problem in keeping them as-is for now.

Details on categories

The current Developers, Announcements, Publicity and Jobs categories are IMHO working well (I can see how people might want to list/follow/mute those categories specifically and they all have non-negligible traffic) and don’t really need a change. Additionally, I think the Developers category should IMHO be extended to also include discussion of algorithms (it does that to an extent already).

I am unsure what to do with “Question for developers” use case (e.g. I want to better understand some aspect on how Stan is implemented; I want to discuss a potential improvement to Stan). We might want to channel those questions to the Developers category, Help category or even a separate category - any thoughts?

The Installation category is IMHO sorely needed to let us track the volume of installation problems and let users who are willing to provide installation support see the unanswered questions there. Since installation problems (and people who can help) differ greatly by platform and almost no installation question is likely to involve multiple platforms, it IMHO makes sense to have per-platform subcategories.

The Getting Help (name could be likely improved, or could maybe just be “General”) category should then include most of what is currently in General, Modelling and Interfaces categories. The main reason is that many questions combine concerns about modelling and interfaces with syntax and other general concerns.

We might potentially want to split the “Help” category into two: one for more “Beginner” questions and other for “Advanced” discussion. The naming would need to be improved, but I think a sensible dividing line would be either “Help with a specific model” vs. “Help with a general math/stats problem”, or alternatively somewhere between “I think most people with some Stan experience could answer my question” and “I am not sure this problem is even solvable”. The pros are that it could let people focus better (especially there might be people who only feel confident answering easier questions who might want to follow that category) and that we might want to auto-close the beginner questions (as they are usually short-lived and there is little benefit in someone posting to an old thread), while a productive discussion over an advanced topic can easily span a very long and might benefit from “late comers” and we thus might not want to auto-close. Additionally a category that is explicitly “beginner-friendly” could make it a bit less intimidating for novice users to ask questions.

I don’t want to split the help topics into help with syntax vs. modelling vs. math, as in my experience many questions would be misclassified - most often people ask for syntax, but their problem is actually conceptual (“how to declare a discrete parameter”), but the mixups in other directions are also IMHO not rare.

The help and installation categories are probably also the only ones that need to support the “Mark as solution” feature, while posts in other categories can automatically be presumed to not require a solution (or reaction) at all.

The Community category should then include discussions about the community and its governance. It would include the current Meetings, Stan Governance and Google Summer of Code categories as well as most of the Project Proposals category and topics tagged discourse.

I think we might thus be able to avoid having a “General” category (we may say that what doesn’t belong elsewhere probably belongs to “Getting Help”). The only use case we identified earlier that doesn’t have an obvious home is questions about hardware. But maybe I am looking too narrowly and a “General” or “Miscellaneous” category would be helpful (or “Getting help” could actually be “General”).


You’ll notice that the structure of categories currently ignores the various interfaces. I think interfaces are best handled by tags as they cut across almost any other sensible categorization of topics. For some categories, we may even enforce that at least one interface tag is present when starting a new topic.

A downside of using tags to distinguish interfaces was mentioned by @ariddell at Let's use tags for field-specific content and much more! - #5 by ariddell : With interfaces in a category, you can mute the user questions about an interface, while still following developer discussion about this interface. If we move to tags, muting the tag to avoid seeing user questions about an interface will also mute the developer discussions about an interface (not completely sure how muting a tag interacts with following a category, but I would expect the muted tag to have higher priority).

It might be possible (I didn’t test) to achieve a similar behaviour by muting the “Help” category and following specific tags.

I think this type of usage is relatively rare, while advantages of recategorization can affect most users. So with apologies to Allen, I would still currently prefer the recategorization, even if don’t find a good solution to this issue. Happy to hear if there is a solution that satisfies all the constraints, or if others disagree about my evaluation.

Auto-closing topics

I think that for most categories we should setup auto-closing of topics, probably something like a month since last activity. The potential exceptions are the “Help - advanced” category (if created) and Developers category, which IMHO contain/would contain a large proportion of discussions spanning longer time frames which could be hurt by auto-closing.

Default view

We IMHO also should change the default view (what people see first when they open the forums) to categories, after the number of categories is reduced, I think this would do a better job at summarising what the current buzz is.

Changes to tags

I think tags are currently relatively under-utilized, but I think the situation is getting better.

Remove the old specification, modelling and techniques tags - I don’t see how they could be useful to anyone and they are first suggestions for tags in new questions, hiding more useful tags (like type of interface, class of models, etc.). Going over tags that are currently not used a lot (see The Stan Forums) and consider removing some of them is also going to be necessary.

We might want to help tags work well by having an effort to check and update tags on popular topics (say 10+ likes) from forum history.

Tagging people who participated in the previous discussions around restructuring: @BFiles , @jroon, @jsocolar, @mitzimorris , @cmcd @yizhang @jonah @syclik as well as all @trust_level_4 users.

Looking forward to hear your feedback.


I feel pretty confident that this will be an improvement. Thank you!

The one question I have is about the reasoning for auto-closing. I believe you that there are good reasons for doing this, but I’m not too sure what they are. On the other hand, I think there are a couple of use cases for not doing this:

  • Are we confident that we won’t let well-posed questions slip through the cracks for a month without an answer?
  • Are we confident that there is nothing older than a month in Discourse right now that is simply incorrect and uncorrected?
  • Occasionally I encounter an old post that could benefit from updating. Usually I find these posts as I search the Discourse for problems that are relevant to my work, so I suspect that others might find and use them from time to time. Do we want to avoid updating these? Here’s a recent example:
    Hierarchical prior for the regression coefficients

One thing that I find lacking is having a fun, model insights, discussion tag. I don’t really know a good name for this but it’s these discussions around new models and solutions that brought me to the forums a few years ago. I’ve found the last year to be more oriented around help, which your proposal is making more structured. I’d like to bring more discussion around these cool techniques and finds. Some of which have moved into the design docs. I’m not sure many new people to the community would feel as comfortable commenting on design docs as they would participating in a discourse discussion.


Yeah I think this would be an improvement. Right now I find that people will often post in an interface category because that’s what interface they’re using, not because the question is specific to that interface. When that happens it reduces the number of people who might respond to the question because some potential responders are (understandably) only checking a subset of the interface categories or ignoring the interface categories.


thanks for the feedback so far. I think auto-closing deserves a bit more thorough discussion then I offered initially.

When does auto-closing help?

The most common situtation where I wish we had some auto-closing is when a new user revives an old topic, by basically introducing a new question - this is usually driven by some superficial similarity between the original topic and the problem at hand (e.g. something like “Divergent transitions in Poisson model”) while the problem is often very different. This is most often associated with topics that are like “Help me with my model” or “How do I analyze this data”, where the advice depends heavily on details of the data and model. This hurts both the forums (that become harder to navigate) and the user asking the question (because revivals of old threads receive less attention).

Currently, when this happens, a Leader/moderator or above can split the topic into two, but it is rarely actually done.

When does auto-closing hurt?

Auto-closing is undesirable when there is a long running discussion or a problem that is unresolved after initial discussion and it is later discovered by somebody who has found something relevant in the meantime.

If the topic was closed mistakenly, one can create a new topic and link to the previous discussion.

So whether auto-closing is sensible IMHO depends on the ratio of cases where it helps and where it doesn’t help and how annoying do we consider the corrective actions (split a topic vs. continue discussion in a new topic). Part of the motiviation for splitting the Help category into two is because the “Help with my model” or “How do I analyze this data” questions are very rarely usefully revived, while we get a non-negligible number of long running discussions on more abstract modelling issues.

Many forums with similar aims (e.g. have auto-closing, so it probably works for them

That’s a great point and we should definitely try to encourage this. I think this overlaps with the rationale for a category for “Help with a general math/stats problems” , so maybe if we had “Help with a specific model/dataset” and then “Discuss general math/stats/modelling problems” it could cover this use case as well? I think the difference between sharing an insight and asking for help/feedback is not very clear cut anyway, so trying to split those two might be difficult.