You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
i noticed that when a long enough list of new threads in a channel arises and some threads get an answer and some not, i think it's quite tedious to scroll through all unread threads (optionally multiplying that time by a number of channels, which person often looks at) since visiting the server for the last time to pick unanswered ones to then try to help solving them. I think it would be more convenient if there was kind of a widget/section (potentially configured to be opt-in by default, so uninterested folks wouldn't have to worry about turning it off or hiding it) containing dynamically grouped/marked threads unanswered for i.e. 24 hours to aid skimming them.
Technically, it might be some kind of a queue where every new thread is pushed into and after some timeout or if thread gets a reply posted by a non-author (because some folks send a few posts as their thread is created), such thread would be removed from the queue.
Me and @vcarl already had some intro discussion about it on Discord (which actually this issue is based on) and so far it seems that the constraint would be (quoting @vcarl):
unfortunately archived threads turn into "#deleted-channel" if they're linked to as a channel name
I am going to try dig into our bot's code, which is responsible for handling threads to see if i will be able to implement a working solution.
Meanwhile, i am looking forward to see any suggestions or opinions about the idea. :)
The text was updated successfully, but these errors were encountered:
containing dynamically grouped/marked threads unanswered for i.e. 24 hours to aid skimming them.
I think it might be sufficient to add some logic when we mark a thread as "locked", because we already reply with an extra hint on how to refine a question if it's not getting answered well.
jobs-moderation.ts also loads and tracks messages for a channel. Not 100% on all the differences against how autothread's loading works.
The autothread logic is run every hour, that or the job moderation loading might be a good reference for something accomplishing what you're describing with the queue of threads. This doesn't use a queue so that there isn't any state to lose on restart — scanning the channel completely works after a deploy, pushing new messages to a queue would reset every deploy.
I think there might be a couple of options here:
add in another schedule check-in before the thread is locked, so highlight threads before it's closed
if a thread is locked without replies, link to it to highlight that someone got missed (and maybe encourage them to post a followup? downside here is that no one can engage in a locked thread)
something else? if you have something in mind.
As for presenting it in a widget or something, maybe it could be posted into a thread? So it presents as a thread title posted by Reactibot, with the contents obscured. I'm not sure exactly how it would work though.
Hey,
i noticed that when a long enough list of new threads in a channel arises and some threads get an answer and some not, i think it's quite tedious to scroll through all unread threads (optionally multiplying that time by a number of channels, which person often looks at) since visiting the server for the last time to pick unanswered ones to then try to help solving them. I think it would be more convenient if there was kind of a widget/section (potentially configured to be opt-in by default, so uninterested folks wouldn't have to worry about turning it off or hiding it) containing dynamically grouped/marked threads unanswered for i.e. 24 hours to aid skimming them.
Technically, it might be some kind of a queue where every new thread is pushed into and after some timeout or if thread gets a reply posted by a non-author (because some folks send a few posts as their thread is created), such thread would be removed from the queue.
Me and @vcarl already had some intro discussion about it on Discord (which actually this issue is based on) and so far it seems that the constraint would be (quoting @vcarl):
I am going to try dig into our bot's code, which is responsible for handling threads to see if i will be able to implement a working solution.
Meanwhile, i am looking forward to see any suggestions or opinions about the idea. :)
The text was updated successfully, but these errors were encountered: