I think this is a very powerful tool for keeping documentation topics clean. I would have this on most documentation topics on meta.
It means people can reply to them but they know upfront that replies are like tears in the rain. If you want something permanent:
Open a new topic
or
Edit the OP
Even though we can do this pruning by hand it is tedious. Plus, on a psychological level, when a computer does something cause âthese are the rules of the ball gameâ, it feels way better than us humans intervening. (oh why are you making up this rule now, not fair)
I think we might also want to retain replies that have a certain threshold of likes, just in case?
Other than that I think thereâs clear need for this based on our usage at least, in the âfirst post wikiâ kinda deals. It would have to be a per-topic setting though, right?
I like this. We have a lot of âstickiesâ (pinned posts) that might get a lot of heavy use now as we transition over to Discourse, but later wonât be as relevant. I donât want to have to remake the posts every so often.
I am in favor of this feature request for all the reasons cited above plus one more.
Here is some background for my reasoning. I have researched having a âchatâ feature in Discourse and understand the position of the Discourse team on people using private multi-recipient messages for chatting.
I know that both Babble and âQuick messagesâ plugins use the multi-recipient PMs at their core.
I think âQuick Messagesâ is almost exactly what suits us.
We want to have just a few selected people on our site who are allowed to chat but it seems to me that the feature requested by this topic, if implemented as a feature, would mitigate most of the negative issues with using multi-recipient PMs as a form of chatting.
Actually I hate chat, but it has its purpose for a team of people who are working together on creating a DRAFT of a long helpful general forum topic. The chat sidebar, can be on top while all the good stuff that results from the chatting gets transferred to the DRAFT topic, on the same screen below (preferably beside) the chat sidebar.
Our team is using RocketChat beside a Discourse window right now but I want an All-in-one solutionâŚ
Just my 2 cents and I really would like if this feature were added soon
I would like a âchat nowâ button beside each topic, so that âchatâ on the topic could be found easily in the future vs having to wade through a bunch of PMâs to see it there was a chat for a topic
EDIT: I am suggesting that âdeleting replies after X daysâ in these âlinked to a topicâ multi-recipient PMs that can also show up in a expandable/hide-able chat sidebar (in the chat sidebar, the PM is âcompressedâ by removing dead space and using image thumbnails), would be the ultimate for us.
Also, I do not think whispers are a close enough solution for our issue.
Now itâs done in the commit below. I did many changes in the âfuture-date-inputâ code. So let me know if there are any new UX issues related to it.
In that case, should we retain only the OP replies? Because if we retain a non-OP reply without its reply-to-post it will create confusion. For example, if we delete post #10 and retain post #11 in this topic then it wonât make any sense.
Iâd also like to put in my two cents in favor of manually saving replies. (As long as itâs a manual process, presumably whoever it is thatâs saving the replies will have the wit to save replies that make sense out of context.)
It can be somewhat surprising, so I would like us to have this number communicated to admins when they set the timer. Maybe we wait on the redesign of topic timers UI @martin is working on to add this in?
Note, this doe not solve @dfabulich problem, and to be honest I can not think of a clean workaround for manually protecting, here are some things I thought about
skip_auto_delete_reply_on_staff_like (default false) - similar to how we feature comments on BBS using staff likes
Automatically skip on âpost noticeâ ⌠adds noise
Always skip when staff posts, would have to be a setting
, following new line appears: