Should old threads be auto-locked (more aggressively)?

Occasionally I’ll get most of the way through an interesting thread and think I might have something to add–until I notice the whole discussion was from one or two years ago, except for the last post.

Sometimes it makes sense to keep a thread around to get sporadic updates (e.g. @barneygale’s thread about extending pathlib). But I think in most cases, particularly in Ideas and the like, this is more jarring than useful. Most of the participants haven’t thought about the topic in a long time, their opinions may have shifted, and the python landscape itself has changed. It’s great to have an archive of these discussions but I’m not sure that resurrecting old threads is valuable–better to start a new thread and refer to the old one.

Maybe threads should be locked after a few months of inactivity? I don’t know what a reasonable time limit is, or if there is one, but I thought I’d bring up the idea here to see if others feel the same.

7 Likes

I’ll just add in that there are also other potential solutions but I don’t know if Discourse supports them: for instance, a banner or other notification that a thread is older than X months might be a less intrusive nudge. Of course I can check the dates of the posts (and I do) but it’s easy to miss.

IMO, especially for Ideas , threads shouldn’t be locked. Yes, opinions and context might have shifted, but that rarely means that the original idea is completely useless (unless it was useless at the start already). Recreating a new thread with the same idea just because the original thread was archived just fragments discussions. The discussions can still happen with the context of the original discussions.

Thread closures should be reserved for actually problematic situations, like if the original post is deliberately inflammatory.

OTOH, automatically closing or adding warnigs Python Help threads does sound more useful: Since the goal is to help the original user, if they don’t have any questions anymore, resurrecting that thread is not gonna do anything good.

8 Likes

I don’t think it’s a big enough issue to warrant something as heavy-handed as locking threads.

6 Likes

I think that’s the best case scenario but not the common one. Maybe I’m just suffering from confirmation bias, but it’s rare for an old thread to be resurrected and continue as it was. It’s more likely that someone found the thread and jumped in without noticing the date.

You’re probably right. I don’t think of auto-locking as particularly draconian (it’s not personal, just a way to move things along) but this is not a huge problem. I should be more suspicious when a long thread suddenly appears at the top of the forum.

The best internet forums I’ve used allowed idiosyncratic posting style, avoided moderator actions against good-faith posters, and restricted those moderator actions to warnings + temporary bans, rather than edits to posts, locking or thread splitting. Personally I’m grateful to the moderators of this forum for taking such an approach with my “extensible pathlib” thread!

I’ve wanted to ask the same question recently but I chose to just mute the thread :person_shrugging:

2 Likes

What would be helpful is if Discuss marked old threads explicitly. I often find myself reading back through an old thread because someone posted a new reply, and only at the end do I notice the original post date.

1 Like

Agreed. The current “1 year later” note is rather subtle and easy to miss.

3 Likes

Yes, it is placed above the link’s anchor, so for me it is outside the browser viewport and not visible unless I scroll back up.

1 Like

To note, threads in Committers are set to auto-close after 1 year; something like that could be extended to certain other categories if the community agrees (e.g. perhaps Python Help , where it seems to make more sense than in Committers , but not, e.g. Ideas or PEPs ).

As a sidenote, I’ve found it rather odd in Committers in the first place—only core devs can post anyway, and most threads are usually either only relevant for a couple weeks (nomination votes, etc), or may be relevant at some point in the future.

This already exists, no?

While the latter would probably have to be fixed upstream in Discourse, when it is scrolled into view could emphasize it more via configurable CSS, I’d think. Any specific suggestions for this? If someone can link an example thread, we can all test how it would look via our browsers’ F12 developer tools.

2 Likes

I think the confusing default date format for old posts is part of the problem. Especially in very old threads, I often find myself parsing e.g. “Jun '18” as “June 18:th” instead of “June of 2018”.

There is apparently a setting to instead display the date as “Jun 2018”: Show post Year? - feature - Discourse Meta

Would it help to change the post format from “Jun '18” to “Jun 2018”?

5 Likes

That seems like a relatively non-brainer incremental step in the right direction to at least reduce ambiguity and misparsing, especially on a highly international forum like this one, even if it may not entirely solve the issue. @admins ?

Random example: Scroll up slightly to see the “3 months later” notice:

That’s a rather poor example since there was no explicit resolution and therefore a question was justified. The alternative would be opening a new thread to ask about that one.

Ah, I guess I’ve never tried to resurrect an old thread so I didn’t know that was there! I wonder what the threshold is.

Sorry, I thought just any example of the notice was needed, to test CSS changes to make it more visible. There’s nothing wrong with your post.

3 Likes

I think the default is ≈6 months, but its configurable by the admins.

1 Like

Do you have a suggestion for a better value?

I don’t have a strong preference myself, but 6 months seems a bit long in most cases; since it’s only advisory and not too intrusive, maybe something like ≈2 months would make sense?