Auto-closing threads: Why?

[ExpHP]

I’ve noticed that lately many recent threads have an expiration date:

I’m not sure how these are arising or why? Are moderators doing this to all new threads?

This seems to be setting up a pretty big paradigm shift; I feel that Discourse does a decent job at handling necromancy, and I’ve gotten the impression that, when you have something novel to add to the discussion, adding a post to an old thread is to be encouraged over creating a new thread.

Yes, there have been specific instances of pointless necromancy (after which a moderator promptly closed those threads), but it seems to me these instances are few and far between compared to good necromancy. The typical Rust community member knows how to revive old threads responsibly, and most threads don’t invite inane comments from passerby in the far future. For example, take this thread:

Explicit Captures for Closures and Code Blocks

In his second video on a games programming language, Jonathan Blow discusses the concept of C++ captures in its lambda syntax, and the potential generalization of the capture syntax to any block. I think that this feature could be useful to implement in Rust for the following reasons: Additional safety with potentially low compile-time overhead: if the programmer explicitly states the namespace of the closure, the compiler has an easier job of labeling everything in that namespace as moved/bor…

I could easily picture that in seven months, somebody might want to share that they successfully implemented this idea as a Rustc plugin or similar. If that happens, I would want to hear about it… and for that reason I would gladly take the risk of somebody potentially posting a useless comment that I don’t really want to read.

---

Edit: I can confirm at least that moderators are not doing this manually, as this thread was given a 3-month expiration the very moment it was posted. It must be a default setting somewhere.

[erlend_sh]

See (edited)

[elidupree]

When I click that link, it says “Sorry, you don’t have access to that topic!”

[mbrubeck]

(The topic above was posted in the “staff” category, and isn’t visible to most users.) Auto-closing is a Discourse feature that the admins recently enabled here by default, and we are still experimenting with it. You might notice that different topics have different auto-close durations, depending on the setting when the topic was created.

The benefit of the feature is that replies to old topics account for a lot of the spam and off-topic posts we get, which currently accounts for a large portion of the moderation work load. Posts that stay open forever also make it hard for old flame wars or contentious arguments to ever really die down, since a single reply is enough to bump the whole thing back to the top of everyone’s attention.

But of course we do also get useful replies to old topics, and in some cases it will be inconvenient or confusing to have to open new topics for those instead. I hope we can find an expiration time that still helps moderators while not being too inconvenient to users. In my experience, by the time a post is about six months idle, the majority of replies are either spam or would be better as a new topic. In cases where they aren’t, it shouldn’t be too hard to link the new topic to the old one, and moderators can even re-open the old topic and merge new threads into it if necessary.

[scottmcm]

I could easily picture that in seven months, somebody might want to share that they successfully implemented this idea as a Rustc plugin or similar. If that happens, I would want to hear about it…

I think that if it’s been a few months there’s no problem with someone posting a new thread with the announcement. That would encourage people to summarize the previous thread, too, to avoid new users feeling like they need to read potentially years of previous posts.

So personally I think I like the auto-close.

[fweimer]

Under which circumstances trigger auto-closing events notifications? Is this really necessary?

My understanding is that nothing can be done about the auto-closing anyway.

[scottmcm]

+1 to not finding the notifications useful – especially since they seem to trigger on private messages too.

[kornel]

Closing of private messages is weird and creepy.

I don’t mind closing of public threads, but they shouldn’t be all displaying “This topic will close 3 months after the last reply”, because that sounds like a warning from a moderator or something else unpleasant. And it’s just not helpful to see that note 10 seconds after posting a topic.

[petrochenkov]

The benefit of the feature is that replies to old topics account for a lot of the spam and off-topic posts we get, which currently accounts for a large portion of the moderation work load.

Do moderators remove spam messages very quickly?
I very rarely receive them in the mail from internals, certainly not in enough amounts to fight them with such a heavy hammer as thread closing.

[mbrubeck]

Do moderators remove spam messages very quickly?

Yes. A lage portion of spam messages are caught by automatic filters and put into the moderation queue immediately. Most of the remainder are hidden very quickly by community flagging.

I don’t mind closing of public threads, but they shouldn’t be all displaying “This topic will close 3 months after the last reply”

Yeah, the notifications and banners are really intrusive, and may be a reason to turn off this feature if we can’t disable them.

[mbrubeck]

Closing of private messages is weird and creepy.

I think this was an unintended result of a one-time manual database modification and will not happen to any private messages going forward.

[scottmcm]

Yeah, the notifications and banners are really intrusive, and may be a reason to turn off this feature if we can’t disable them.

Do we have control over the style sheet? If they were grey, small, and italic instead of black, large, and bold I would see them as informational and unimportant instead of intrusive and alarming.

[carols10cents]

Do we have control over the style sheet? If they were grey, small, and italic instead of black, large, and bold I would see them as informational and unimportant instead of intrusive and alarming.

I made the text match the “You will see a count of new replies…” informational text that appears below the “topic close” text.

[scottmcm]

I made the text match the “You will see a count of new replies…” informational text that appears below the “topic close” text.

Thanks, Carol! It looks great like this

[vi0]

If I wish two reply to a 2-year-old closed topic, shall I manually mention all the users of old thread when creating new thread?

Is it OK to post “bump” posts to pre-RFCs I care about to prevent them getting auto-closed? Maybe receiving a vote should also reset the timeout counter?

If closed-by-timeout therad was a “pre-RFC”, shall I also name the new thread “pre-RFC”? Shall I copy the content from old thread or just link?

Or are old “abandoned” pre-RFCs now implicitly closed instead of implicitly postponed? The next step may be auto-locking old Github issues then…

Example of a thread that was revived: pre-RFC: life-before-main / lib init

[Centril]

Perhaps a compromise could work:

• Auto-close threads after some time.
• But provide for a way to revive them where commenters explicitly have to acknowledge the necromancy they are about to commit (“Are you sure you want to revive this old thread…?”)

(I have revived old threads in the past when it was relevant, e.g. in the case of structural records…)

[nakacristo]

If there are threads that sensible should have a long life, such as pre-RFCs, then perhaps it would be better to manually flag those threads as such. Is this something that can be easily implemented?

[mbrubeck]

Feel free to press the Flag button and use the “Something Else” option to send a note to the moderators if you’d like us to extend/shorten/remove the timer on a specific thread.

[Centril]

@mbrubeck could a dedicated flag category “Revive” be introduced for that so as to avoid potential misunderstandings?

[repax]

Can’t auto-closed threads be automatically revived if the poster is a trusted member? This should rule out spammers?