By the way, these forums are running on hosted Discourse instances, so we can’t just make arbitrary changes to the software (unless someone wants to propose those changes upstream and do the work to get them accepted and implemented).
This at least sounds like a control useful to every Discourse user: some way of gating necromancy from the Level 0 users. I don’t know how best to propose it upstream or I would.
This also feels like the “correct” solution: make necromancy a skill that you earn just like other skills earned through levels.
I wanted to add a few things that I noticed in Zullip in the last couple of uses that could be improved, but I was also busy, so didn’t have the time (or energy?) to create a completely new topic, summarising the old one, and adding my remarks.
So instead, I closed my browser tab as soon as I saw that I couldn’t respond to it any more, and didn’t bother adding my suggestions.
Now, this might be good (if I didn’t want to spend the energy to create a proper post/topic, perhaps my drive-by comments wouldn’t have been particularly helpful), but it also didn’t really feel very “welcoming” to me, wanting to contribute a few minutes of my time to improve the Rust community (at least that was my hope), only to be greeted by an (unresolved) topic from a few months ago, that was already locked.
In terms of providing a welcoming environment as a Rust community, these small paper cuts feel to me like degrading that experience, perhaps not significantly so on their own, but taken together (not that this happens often in this community, thankfully!) they could.
This is a tough problem to solve. One one hand you could be browsing a link through another post and want to comment on it but it is closed, but on the other hand, sometimes it does get annoying when people post messages on old topics.
Also we often have a thread for crate releases, where we reply in the same post for minor releases and create new posts for major releases, and often end up having a gap of more than 3 months between minor releases which will make this a hassle since the thread will be locked and we will have to create a new post for minor releases.
IMO that happens because there is no alert before posting a reply that the thread is not current. If there were an intercepting alert when someone clicks “Reply” to a post that’s more than N (e.g., = 3) months old, most readers would suppress their impulse to respond to the post and thus reactivate the thread.
auto-notifications triggered for me today when I logged in, to inform me that the “Welcome to Rust internals” PM from 2015, which you get by joining, got auto-closed, so apparently it was added around 90 days ago ? As I’m here since 2015.
Another pointer for consideration:
I was reading this GitHub issue:
Which ended with “let’s continue the discussion on Discourse”, which led to here:
Which is now locked, due to inactivity. Even though the original issue isn’t resolved yet, and might get more input in the future (which would now require a new post, linking to the old post).
I realise this is a difficult thing to tackle, but I figured adding some real-world examples of how this affects the community would be a good idea.
One problem is that “the damage has already been done”, since all old (valuable) posts were insta-closed when this feature was enabled, so I’m not sure if that can be reverted, even if we wanted to, but perhaps it makes sense to come up with a better way to solve this problem going forward?
As a point in case, I just found out about Volatile and sensitive memory, which is seemingly used as a reference for how volatile accesses work in Rust, but the conclusion there does not match our current understanding of the interaction of
dereferencable. That thread really shouold be amended to warn people about this, and add a link to https://github.com/rust-lang/unsafe-code-guidelines/issues/33.
I flagged the thread and asked the mods to do this, but such additional barriers make it much less likely that such corrections happen at all.
Interestingly, DMs are also closed auto-matically after 90 days… I, like others, am starting to find it a bit of a hinderance.
@mbrubeck Now that this policy has been in place for a while, do you find that it is actually helping? If so, would it be possible to at least extend the deadline to 180 days and see if it still has benefit?
Interestingly, it seems like not all threads are set to auto-close?
That thread isn’t 90 days old?
There’s a tag at the bottom like “This topic will close 3 months after the last reply.” This meta thread does have it, but that stacked-borrows thread does not.
Is this still happening with new DMs? I know that a while ago, existing DM threads were accidentally set to auto-expire (because of a faulty database backfill), but this shouldn’t happen with any new DM threads started from now on.
I think it’s helping but it’s very hard to say with much confidence (mainly because moderation issues are always highly variable from week to week and month to month). I agree that a 180-day timer seems like a good idea to try; we’ll discuss this.
I reopened that thread at your request, and did not add a new auto-close timer right away because that would immediately close it. (Bit of a flaw in the implementation, there.)
No, the thread you reopened was a different one (and thanks for that!).
Ah, I see. The DM I looked at was somewhat older, so it might have been closed before.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
Is there a dedicated thread to request topics be reopened? For example, there was a discussion on const generics and const arguments that was happening on the const generics issue on github. The github issue was locked because the posts were off-topic, but they could not be moved to the thread because it was locked.
To ask us to re-open a thread: click the "Flag" icon, choose "Something else" for the type of flag, and enter your request into the text box that appears. (Flags are the best way to contact the moderators because they give us a really prominent notification.)