Should we lengthen the auto-close time?

Hi everyone :wave:

I don’t quite recall where exactly I’ve last seen it, but I’ve certainly heard the desire have the internals forum lift its current setting that topics auto-close 3 months after the last reply. This is unlike other places where Rust development is discussed (e.g. Zulip, GitHub), and probably not the best fit for the often slower pace of discussions and development of Rust.

On the other hand, I do see some value on preventing some instances of necroposting.

  • People who were part of an old discussion might have moved on and appreciate when they don’t have to expect notifications about old topics anymore eventually.
  • Some discussions may have become long outdated or superseded by newer developments
  • Allowing a forum discussion to have an end helps keep topics shorter:
    • Opening a new topic to continue an old discussion can encourage the poster to summarize existing discussions (perhaps even across different platforms) and allows others the reply without feeling the need to read through a huge wall of existing posts first.
  • At some point, even the people that were already part of an old thread don’t remember many details and would have to re-read through the whole thing.
  • An old topic is particularly visible on the “Latest” home page of the forum. It already has a high view and reply count; as a user of the forum we are used to mostly come across recent discussions, this can have confusing effects.
    I have certainly already personally experienced the seemingly “new, hot, debated topic” where I’ve only noticed the time stamps on all the posts a little while later – especially over on the users forum where necroposts on pre-auto-close-timer-introduction were a somewhat regular occurrence until about 2 years ago.

I personally believe, we should thus consider to keep the auto-close timer, but make it longer than the current 3 months after the last reply. Perhaps even much longer – maybe 1 or 2 years after the last reply?

But I don’t want to make this a completely arbitrary decision, and I think you all are the best people to ask about this. Feel free to share what you think would be best and why – especially if you would prefer other options like keeping it at 3 months or removing the auto-close completely.

For context, I also just came across the last discussion on this that set the time to the current 3 months value, 5 years ago:

Discourse auto-close settings - Rust Internals


Another thing that I believe we can improve the current auto-close message:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

It should probably contain best courses of action, such as opening a new topic, or messaging moderators to re-open a topic. The latter option is particularly useful to add updated or correcting information in topics that are easily found in search engines; or to keep discussion threads alive for longer when they are linked to from other places (e.g. GitHub) as “the place to further discuss” or “the place to give feedback”, on some feature in development.[1]

(Unfortunately, it does seem such a change would not affect any existing closed topics.)


  1. Here’s an example for this; the relevant IRLO topic has already been re-opened because a user noticed the issue and flagged moderators – by now, this topic is also so old that any reasonably extended topic timer would have closed it already. ↩︎

14 Likes

I think a period of at least one year would be good, because I often see issues/PRs sit idle for approximately that long. (Perhaps Rust contribution is a seasonal activity for some?)

14 Likes

Somehow, the auto-close hasn't been an issue for me. Discourse displays links to old threads nicely, so if necessary it's easy enough to create a new thread that links to the old one.

8 Likes

Yeah, when you link from a different thread it adds a backlink to the original thread, even when it's closed, which is nice.

Big fan of updating the guidance, though. Ideally the new thread would say up front what's changed that makes it worth bothering bringing up again.

10 Likes

The biggest reason we enabled this to begin with is that spam bots would necropost to old threads that had lots of search engine juice. I'm not opposed to changing it to whatever, as long as spam doesn't increase.

13 Likes

Is it possible to expand the ability to reopen threads to a wider set of users? For instance, give every "trust level 2" user the ability to reopen a thread? That would deter spammers, while making it easy for users.

5 Likes

While I like the idea of regular users being able to reopen threads, that would not encourage the summarisation others mentioned earlier in this thread.

1 Like

But does Discourse display backlinks to newer threads in an old thread, after it is closed? Like Github issues. (Not sure how to test this, I don't have a closed issue readily at hand)

I think it's important to give people coming from Google some pointers to read on new developments

And in any case, 3 months is too short to autoclose a thread in this forum

2 Likes

As far as direct site settings go, the answer is probably no; at least I wasn’t able to find anything.

(I haven’t looked into the “Discourse Automation” plugin any further, so there might be “custom” ways of letting a wider set of users trigger re-opens in some way.)


Yes it does; for example, you’ll see the backlink in the thread I mentioned here:

That link doesn't work: "Oops! That page doesn’t exist or is private."

2 Likes

Oh, my bad… the problems you get when having too many rights on the platform. I didn’t even notice that that topic was in the hidden “staff” category, :man_facepalming: – I’ll partially blame Discourse for even deciding to be showing it in the “Your topic is similar to” popup while writing this one.

Though I should have made the connection when the preview wouldn’t render. I don’t see any issue in making that particular thread public (still unlisted); as it seems relevant to this discussion.

1 Like

I just came across another relevant prior discussion

Point of interest: when I go to the topic you just mentioned I don't see a backref to the current discussion. Maybe I'm not looking in the right place? Or maybe it's because I'm on mobile (using a browser (Brave on Android) rather than an app)? Or is it because the way you linked that topic?

The backlink should be visible at the bottom of the topic’s original post, i.e. here:

Nope, definitely not:

Read that wrong, needed to look at the OP apparently.

I was thinking it would work like github, where it is a timeline of things happening, and thus appear near the end.

1 Like

The backlink can be comment-specific too (might be in the middle of the thread).

Huh, I feel that is less than ideal in a long thread. I would prefer the github approach where I can see at the end that someone mentioned the issue 2 years down the line. Because the whole page is a big timeline (modulo edited posts).

1 Like

I've bumped into this a few times when I wanted to go back and add something to an earlier discussion, only to find out it was auto-closed.

I agree with basically everything, from the suggested timespan of 1-2 years (maybe 18 months?), to extending the method with a recommended course of action.

3 Likes

I feel the two are sort of a wash as they exist today. The GH approach is arguably a better fit for links to the entire thread. But I link to specific comments pretty often on URLO,[1] because of the content of that specific comment. And the backlinks themselves are comment-specific too.

Whereas on GitHub, all backlinks show up when the forward link was created, but don't tell you which comment it was talking about (if it was a specific comment), and the backlink is not comment-specific -- which is particularly painful when it sends me to the top of some 100+ comment issue.

Links to comments and events[2] that are under the fold aren't working for me on GitHub at all right now(!), making the following example even worse than it normally is, but anyway:


  1. and occasionally IRLO ↩︎

  2. including backlinks ↩︎

  3. look for "Pointer metadata" if under-the-fold links are broken for you too ↩︎

3 Likes