Extend usage of slow mode to fight battle of "live chat"

feature
1

We love the slow mode feature and would like to extend the usage of it. We would like to have permanent slow mode for all categories – not just new topics of them but also all existing topics.

First, let us explain why we want to do it.

We have about 10K members and 13K topics as of now. Some of our users are not used to develop meaningful and thoughtful discussion. Instead, they do live chat and treat the entire forum as a message App. This is not what we love to see – we want meaningful discussions in our community. However, in most cases, “suspend” or “silence” are too harsh and not applicable. This is where the slow mode feature jumps in. Thanks to this feature, we can slow down and prevent live chat becomes hotter. From our understanding, correct us if we are wrong, there are two ways to activate slow mode:

  • manually activate it for a specific topic, and
  • do it at category level: once the setting is enabled for a certain category, all NEW topics under the category will have slow mode activated automatically.

Currently, our moderators spot “hot topics” (topics became live chat) and make them in slow mode manually. The problem is, since not all existing topics are in slow mode, other topics that are not in slow mode bump up and become live chat again. Thus, some users begin to complain: “why some topics keep bumping up but not getting slow mode (punishment)”, “why this topic is in slow mode with 4 hours remaining yet another is 1 hour”, etc. Even more, there are conspiracy theories about it and our team gets criticized a lot (not that we are not used to it though) due to how “randomly” slow mode gets activated. And this will only get worse since we have very limited resource yet the amounts of users and topics keep increasing.

We want to resolve the issue, or at least make things in a better shape, by taking the following approaches:

  1. have ALL public topics in slow mode: this is to prevent live chat and encourage meaningful discussion.
  2. set default home page as “New” (or anything that is not “Latest”) for all users and the site: this is to allow users that are interested in finding real contents (not just some “ha ha” and “hi” threads) to have better experience while visiting our site. In the beginning, we set “Latest” as the default home page of the site. We observed that this would make users see “hot topics” by default. Furthermore, since we have too many this kind of “hot topics”, new users or users have limited time visiting our site might think all the topics they can see were meaningless chatting, or think it is normal/okay to have live chat here – sadly, it is hurting our community severely. We hope changing default home page to “New” can ease the problem. At least users, by default, get to see something other than live chat threads first.

For 1, we plan to:

1a. activate slow mode for all categories – this will take care of all new topics.

1b. batch update all existing public topics to have slow mode activated. → This is a step we do not know how to do. We do not find slow mode option while doing batch update for topics through UI. Manually update every topic one at a time through UI is not an option considering our limited resources and the amounts of existing topics. Does anyone know what we can do to make this happen? For example, connect to the database and change some fields maybe? We only want to make the change to public topic. Message should not be affected. Or, does adding “slow mode” option in batch update UI make sense?

For 2, we will:

2a. in site setting, make “new” as the first item for top menu.

2b. batch update default home page for all users. → this is also a step we need advice on how to achieve.

We need help for 1b and 2b and would like to have any inputs on better solutions. Anything could be helpful. Appreciate!

6 Likes
2

I think I’d like to see something along these lines in the category settings:

image
image837×124 8.51 KB

I believe you can solve 1b by modifying the topics via the rails console. I tested locally to see if this works the way I expect but I still strongly suggest you test in a staging environment before attempting this on your live Discourse or wait for confirmation from someone on the Discourse team that this is a good solution. (And probably still test in staging even if they do.)

Assuming you are using a Linux server with a standard install, SSH or otherwise get to a shell on the server and use the following:

cd /var/discourse
./launcher enter app
rails c

Then in the resulting rails console:

Topic.where.not(archetype: "private_message").update_all(slow_mode_seconds: 120)

120 is the number of seconds before another post is allowed, so replace that as desired. If you also want to avoid setting this for certain categories, you can chain this with .where.not(category_id: n), e.g. to avoid setting slow mode for categories 3 and 4, you would modify the above like so:

Topic.where.not(archetype: "private_message").where.not(category_id: 3).where.not(category_id: 4).update_all(slow_mode_seconds: 120)

You can get the ID for a category by visiting the category in your browser and looking at the address bar to find something like “c/staff/3”

3 Likes
3

Thanks you @Simon_Manning ! Your reply helped and guided us finding a similar way for 2b.

This is what we are going to do for 2b (in case anyone is interested in). After entering rails console:

UserOption.update_all(homepage_id: 4)

homepage_id 4 is “New” in our testing site. I am not sure if it is consistent due to different site settings. But it is easy to check. Just have one user with the default home page set for “New” and get into database to check the homepage_id of this user. The friendly instructions on how to get into database and check data can be found here.

2 Likes
4

I am open to automating this, so topics get forced into slow mode automatically. But please help me decide:

  • how does the system know when to switch to slow mode?
  • what data points does the system look at to decide to switch to slow mode?
1 Like