A softer slow mode: slow bumps?

Feature
1

I really like the intention behind slow mode, but it doesn’t quite address the most common driver for flamewars on our discourse:

  • Someone comes in “hot” — often someone new, often someone from another community — and lists a bunch of grievances
  • Lots of existing members respond to talk to/at the original poster with varying motivations (but with the “I think someone is wrong on the internet” syndrome ranking high)
  • The original poster wants to respond to/at everyone
  • Even in the best of discussions, things snowball rapidly.

Slow mode doesn’t help here, because there’s a many-to-one problem. It often just further alienates the new member as they’re the one that feels the brunt of the limitation: many can respond to them while their cool down timer is burning and then they only get one post to respond.

One tool I wish I had in my toolbox for situations like these is to slow down the bumping of the topic. The default listings (both latest and top) prioritize these “hot” topics. I’d love to be able to limit the bumps to once-every-12-hours or some such. Then it’s not a complete de-listing, but it’s a significant de-emphasizing that could help limit the number of new entrants to the discussion (unless they actively seek it out, which is just fine).

16 Likes
2

A motivated user could write a single reply and quite many other posters though, right? ….that still would be possible in slow mode.

But I do agree that a reduced-bumping would also be useful in slow-mode. :slight_smile:

2 Likes
3

Absolutely, but such monster posts that reply to many messages make the topic even harder to manage. Splits become impossible, and they tend to put the poster even more on a war-path (or at the very least, give the appearance of aggravation just by virtue of the large wall of text).

5 Likes
4

That’s actually another unintended consequence of slow mode that we’ve seen on Julia discourse, which is a paid hosted instance that’s quite active: slow mode gets turned on and some people start editing their posts instead of writing new ones. Similar problem with setting someone who’s being problematic to TL0: they can’t make new posts but they can still edit their old ones, so they’ll do that, which is especially bad if they’re written inflammatory stuff which people reply to and they then edit, making the response look out of line.

But yes, I definitely second @mbauman’s suggestion—being able to prevent a hot topic from getting bumped so often would be very helpful for cooling things down.

3 Likes
5

In addition to preventing the hot topic from getting bumped, it might be an idea to delay the notifications. That kind of solves the issue where someone replies to or mentions multiple users.

4 Likes
6

A trick you can use today is to make topics like this unlisted, we do plan to add timers that can relist, but you could do that by hand

“Bury” topic has popped up in the past, and something we have thought about

5 Likes
7

I don’t really understand what you are proposing. Can you show me a UI mockup of how this would work, what the user would see, what the staff member would see?

That’s why editing is limited by default in Slow Mode. You can turn off the editing limits if you trust your community not to do this.

And consider what @sam said. Make the topic unlisted. Please make full use of the existing tools in your toolkit before proposing more.

8

The core idea is pretty simple: I’d call it something like “Limit Topic Bumps…” in the admin topic menu (likely placed next to the “:anchor: Reset Bump Date” item). It’d pop up a modal box that’d prompt you to enter the time period. Text would be something like: “Limit the frequency that this topic appears at the top of the Latest and other category views to be at most once every X hours”, with a default of something like 8 hours.

I don’t really feel strongly about how it’d be implemented; it could be stateful (keep track of the last post that bumped the topic update time, and only update it if the time of a new post is more than X hours in the future) or it could be stateless (always set the topic update time to be the floor’ed even multiple of X hours from either the unix epoch or the first post). Or something else, whatever.

As far as what’s displayed to the user, I’m not 100% convinced it needs to be communicated to them, but it could appear like an “unlisted” post item, simply stating: “this topic will only appear at the top of topic lists once every X hours.”

As far as other tools, we do sometimes use thread unlisting, but this is all about combative new users — often the kind of person who may take great umbrage at any hint of censorship. And I really don’t want to censor/hide/delete things. The whole point is a softer intervention that hopefully would be less likely to cause more aggravation in and of itself but would hopefully help keep the temperature a little lower.

This is somewhat inspired by the way that Hacker News will penalize topics with significantly more comments than upvotes.

2 Likes
9

What are your feelings on this @sam @eviltrout? We could have an integer here representing time, where 0 means “never allow it to be bumped” and 1-6000 could be “allow 1 bump ever {x} minutes” or something like that.

1 Like
10

It’s an interesting idea - something like debouncing for bumps.

It seems like a power tool but I can see it being useful. I don’t think it’s an easy thing to add – probably something like a medium level of effort.

1 Like
11

I think it can be useful in some scenarios to prevent a topic from getting too much heat in the first place if caught early by moderation. Specially in instances with a lot of users.

If the topic is already heated and the discussion self-sustaining, slow mode will probably do a better job since the notifications the users receive from interactions in the topic will (probably) keep it going.

I was checking the source code and aside from changing the models, would change bypass_bump? be enough to prevent them from being bumped?

Maybe add a field in Topic, something like min_seconds_between_bumps for example and another condition in `bypass_bump?:

def bypass_bump?
  !@post_successfully_saved ||
    @topic_changes.errored? ||
    @opts[:bypass_bump] == true ||
    @post.whisper? ||
    only_hidden_tags_changed? ||
    @topic.min_seconds_between_bumps == 0 ||
    (@topic.min_seconds_between_bumps > 0 && 
      (Time.now - @topic.bumped_at) / 60 < @topic.min_seconds_between_bumps) 
end

Not sure about the 0 value indicating that the topic should not be bumped at all. It can confuse some users. If done this way, I think if it would be better UX if the webapp does not expose the zero directly to the user.

3 Likes
12

If I’m interpreting this correctly, the decision on whether to bump would happen at the time a reply is posted but if no subsequent replies are posted after the no-bump period, the topic will never bump.

Would that be the desired behaviour or should the topic always bump at the end of the no-bump period if a reply has been posted during the period? If it should always bump, should it bump to “now” or the time of the latest reply?

2 Likes
13

Yes, in this approach the decision would happen when the reply is posted and without subsequent replies the topic would never get bumped again. If I’m correct since by no means I’m an expert in Discourse source code this would be the easy way to implement this.

The other possible behavior, bump after the cool down period would probably required more work as @eviltrout said, since it would require the application to store the next expected bump and have some kind of scheduler or sidekiq job to perform the pending bumps periodically.

Both approaches are valid and if this ever gets implemented I don´t know which one will be chosen.

I personally don´t mind if a problematic topic never gets bumped again if there are no subsequent replies. But that´s just my opinion.

2 Likes
14

My thinking is the simplest logic is this:

  • topic has a setting, “can only be bumped once every {x} minutes” where the number of minutes is an adjustable setting, ranging from zero (the default, can be bumped as many times as there are replies) to ~10,000 (can only be bumped once a week). Let’s assume someone has entered 60 minutes, the topic can be bumped only once every 60 minutes max.

  • when a reply is posted, check the last bump date:

    • if the last bump date was more than 60 minutes ago, allow the topic to be bumped by this new reply.

    • if the last bump date was less than 60 minutes ago, do not bump the topic when posting this new reply.

Yeah, this seems simple and workable… let’s add it to the next release @sam @eviltrout?

6 Likes
15

Could -1 (cannot bump indefinitely) also be valuable? I think I’m leaning towards no, it would be difficult to find such topics later (without extra work) and if an admin really wants a topic to never, ever bump again, it probably makes more sense to just close it.

16

I actually think that the max time set should be a configurable setting in the admin page. Something like max_slowbump_time or something.

Also, while we’re at it. Could it be possible to also apply slow bumps at the catagory-level?