Stan Discourse improvements

@martinmodrak, I figured we could start a thread with improvements for Stan discourse. We can change them if enough people think it’s a good idea.

I’ll start with:

  • Change the email subject line: “[The Stan Forums] [] Title.” I’d like to reduce “[The Stan Forums]” to “[Stan]”. (This won’t conflict with github notifications which emails with “[org/repo]”)

@martinmodrak, do we follow a process to change these things?

That’s a sensible point. I don’t know how many people have setup e-mail filters based on the old signature, so I wouldn’t rush it. Maybe consider starting a separate thread on “Changing subject line of mails from Discourse” - here it would be easy for affected people to miss it.

Not really. I also don’t think it would be very useful to have a highly structured process for a set of really ad-hoc considerations that vary in scope and impact. However, I think there should be the spirit of openness and consensus. So for anything that could affect the broader community I think we should have a public discussion on the forums and the discussion should be discoverable (hence my suggestion for a separate thread with a descriptive title for your proposal).

Does that make sense?

@martinmodrak, thanks for that. I definitely agree with the separate thread, public discussion, public opinion.

What I don’t know relates to how this goes forward:

  • if there’s overwhelming support and no objections, it’s simple and it can be implemented.
  • what happens if there’s active support and objections? Should it still be implemented?
  • what happens if there’s no support or objections? Should it still be implemented?

In an extreme case, it could be seen that it’s an announcement and it’ll be changed no matter what the community says. In the other extreme, if there’s not unanimous support, then nothing can be done. I think most things will be in-between and just having a reasonable guidance would help. Something that could be made concrete is we can have a thread and open for discussion for 3 weeks; at the end, the Community Manager can make the call.

In this particular case, I think it makes sense to change it even on objection. (compressing subject lines is useful, there’s no ambiguity in the updated subject line, the new one is equally programmatic.)

But I’m thinking about other things that we could do to make the forums better. How would we go about rearranging categories and tags?

I do think a lot of this needs to handled on a case-by-case basis. We don’t (as far as I know) have a steady stream of suggestions or a large number of people that actively work on this which would likely neccessitate a more formal handling. It is also important to consider the impact - so e.g. when I was adding the “Left Behind” menu item, I didn’t have a big discussion as I assumed it is easy to revert and unlikely to severely annoy anybody, so I’d rather have “post-publication” feedback than discussion before. For something as big as reorganizing forums I think a strong mandate is needed.

I think most of the rules mentioned in Revised SGB proposal for voting on technical issues should apply, although those were not formally approved for changes to Discourse. If there is support and objections, we should strive to find a consensus - my experience is that more often than most people expect you can find solutions that make everybody happy, but it needs more time and creativity. If nobody voiced an opinion, my first thoughts are to ensure that the proposal actually reached the relevant people. Nobody engaging is generally a bad sign and I would generally not implement anything with medium/big impact if I didn’t get any opinions.

Finally, we could have some form of voting if consensus is not achievable.

While having something like “3 week period for discussion” as a guideline might help a bit, I think the important part is not the letter, but the spirit. I think the main factor is not time (though time is important) but trying to maximize engagement of affected users with the topic. If I post an important announcement at the same time there are elections for the SGB, an important technical vote and an update from the CoC committee, it doesn’t matter how long it is up, it is much less likely to be noticed. So I try not to do that. I try to actively tag people I find most likely to be affected by a proposal or disagree with it. If a topic doesn’t get reactions I try to bump it up (unless other important stuff is happening), etc.

On rearranging categories and tags: this is something I’ve been thinking about a lot and we had some public discussion of this: How to best support field-specific Stan communities on Discourse and Let's use tags for field-specific content and much more!

Part of the reason I am not moving forward on reorganizing categories is that I fear I have not yet gotten enough feedback from the community (the other is that I am a bit overwhelmed with other stuff and this seems really high-effort, moderate risk task with only small to moderate payoff)

Does that make sense?

1 Like

Thanks. I’ll put up the post.

I completely agree with you. Practically, though, there should be some guidance.

I was trying to “see the whole board” before making a move (been watching too much West Wing) or “measure twice, cut once.” I’d rather go through the mental exercise of exploring options before setting things in motion. That said, this is an easy one. I’ll start by creating a new topic and we’ll see if there’s any response.

1 Like

So is this thread still taking forum improvement ideas?

  • Code snippet syntax highlighting is great but recently I noticed Rust language’s Discourse forum has something more: a copy button in the upper right corner of the code block. Very convenient for anyone who wants to run the code or work on it in a editor.

Do you know if this is a plugin setting?

I don’t know how it (or Discourse in general) works; I just saw it and figured it probably isn’t too complicated.

A little bit of searching took me here:


Auto-close topics after 90 days of inactivity.

The lack of activity indicates that discussion has run its course. Closing the topic prompts users to create a new topic if they have something new to say. It’s also a gentle nudge, prompting users to look for more recent information. (Typically the information in a very old, inactive post is out-of-date.)


This is awesome. Happy to update the settings… that was definitely enough for me to track down the option.

Do we just change it?

1 Like

Yeah I think just go for it.

1 Like

@nhuurre, this should be done.

test code chunk

Cool, works for me. I can copy it if I hover over the top right corner.

any idea on how to make that happen in Discourse?

Is there really such a widespread problem with zombie threads here that it needs to be enforced? Sometimes, content from 3 months earlier is still relevant and an existing thread provides useful context / makes searching easier…

1 Like

I think it might make sense for the support requests, which are a bit like issues. (And the most common kind of topic.)

I don’t know exactly why the policy is so helpful and has so few downsides. Here’s my guess: posting to a (very) old issue without looking for new information is a reasonably common problem—which the policy solves. And people who have a genuine need to revive an issue are not harmed by having to create a new topic.

It seems like 30 days is the norm.

Here are two sites which use the feature (links to closed posts):

Both seem to use 30 days as the limit.

There’s a category specific setting. See

There’s also an auto close setting for topics with solutions.

I’ve been thinking about this already. I have mixed feelings. From my experience, there definitely are cases where people resurrect old threads and it genuinely isn’t the best idea. However I think those are mixed quite evenly with constructive resurrections - e.g. someone posting an updated code for a newer version of Stan or “Hey, I figured this out, you can use XX”. And we do have quite a few cases where figuring out a computational problem literally takes years. So I think it is a mixed bag… (I also found the use of the autoclosing at slightly annoying in a few cases as a bunch of info I tried to find is scattered over multiple threads where some start "Cannot post to the orignal topic, so … ") Also, when you post a new topic linking to an old topic, the old topic gets the link back, but it is not very prominent.

Note that Discourse also let’s you work from the other side - instead of disallowing “resurrections” by default, they can stay enabled and when a user adds an irrelevant post to an old thread Leaders and above can move the post (and potentialy all the ensuing discussion) to a new thread. So the best approach really depends on the relative frequency of productive and non-productive resurrections.

I agree there would be benefits, but I am not so certain they will outweigh the downsides. My opinion is however not very settled on this. Still I think this is exactly the kind of change that would warrant broader discussion (while I am quite OK with just adding an option to copy code without asking anybody, thanks @syclik)

Maybe doing this only for topics with solutions would be quite sensible. It would also make sense to do this only for the support requests, however, our current forum structure doesn’t let us easily separate those from the other topics.

Does that make sense?

@martinmodrak, do you think it’s ok to move forward with shortening the email subject line?

1 Like