Although 4 hours is then already super slow motion, should be either configurable in the topic drop-down of this new feature or at least globally, because “slow” can mean something different for community A compared to community B.
Youtube live chat is a great example but the way the implement slow-mode there is a bit different from a Discourse site.
Slow mode in Youtube only applies to livestream chats. Since you can only have one livestream at a time on Youtube, the way they handle the “preferences” for how slow is slow-mode wouldn’t really apply in Discourse.
On Youtube, you can control that on a per-live-stream basis. Adding that kind of granular control in Discourse where you can specify how slow is slow-mode on a per-topic basis is probably a bit too much.
Perhaps a site-wide setting would work better in Discourse?
Something like slow_mode_duration
and default to 1 hour? (Given that it’s already a heated discussion and I think 1 hour is enough for most people to cool off)
Let’s make it a configurable number of minutes with some pre-seeded time amounts, for example Telegram does:
Which we can translate to:
Yes!
I’d say also a composer warning is a good idea:
Awesome, let’s make it so
I think you need to fill out some of the intermediate values there, it’s biased too hard towards the short durations. How about this list:
- 15 minutes
- 1 hour
- 4 hours
- 23 hours (we can call this 1 day in the interface, but this one needs a little leniency)
- 6.5 days (“1 week”)
The duration selector should probably support seconds even though we don’t really want to encourage people doing that. Well, that’s why it isn’t a preset! Somebody’s probably going to have fun setting it to 42 seconds or something like that.
We should definitely encourage people to edit their replies and be more considering, so I think the only editing restriction should be disabling bump if you’re within the slow mode window.
I love this idea. It’s the kind of thing I always wanted to add to Discourse. I did not know Youtube already had this.
Looking forward to this feature. Unfortunately not available for tonight’s Presidential debate
BTW: It would be good, if this will also be available for category moderators right from the start.
Yeeeeeeah. Even on my site I’m not looking forward to that one.
Sure @eviltrout did you want to assign this?
Super happy that we’ve gotten to this! Any updates @Roman_Rizzi or @eviltrout?
There’s a PR ready for this feature, which I aim to merge this week! I’ll post an update here when it’s available.
How to disable slow mode again, once it has been enabled for a topic?
Two ways:
- Using the button inside the
Set slow mode
modal. - Clicking the at the bottom of the topic.
I still need to fix a couple of issues. I have a PR open and will probably merge it tomorrow:
I merged some fixes this week. The feature should be stable now and you can enable it from the topic menu:
We are looking for active feedback on this feature, so please feel free to deploy latest Discourse and exercise it!
I anticipate this being very useful in about 12 days…
Thank you so much! We’ve already started using this and it seems exactly what we needed.
I contributed some translations for this feature.
Today’s the day (week? month?)… let the testing begin! We are heavily prioritizing improvements to this feature so keep the feedback coming!
We’ve had users complain that they can’t edit their posts to correct grammatical mistakes, since edits count towards the rate limit. While I think allowing free editing would defeat the purpose of this function, I think editing counting towards the rate limit is definitely counterintuitive.
What about allowing a admin-defined grace period where users are still allowed to edit, and then disallow editing of posts? I think any case where a user editing their own post resets the timer is just likely to cause frustration.
Users can edit their posts during the grace period determined by the editing_grace_period
site setting. Keep in mind that the edit could still fail if the diff is too big. Admins can tweak this via the editing_grace_period_max_diff
and editing_grace_period_max_diff_high_trust
settings.