MEGATOPIC:公共福祉还是公共威胁?

When we founded Discourse in 2013, I had the idea that we’d support topics of any length or size, from 10 replies to 100 to 10,000 to 100,000 or even more!

A few years ago we ran into a technical limitation where we send down a list of all the post IDs in the topic when you enter the topic. This starts to cause problems on the client – particularly older smartphones with less memory and CPU power – at around ~10,000 replies, so we created a site setting that automatically closes topics at 10,000 replies and defaulted it to on. It’s certainly possible to turn this setting down or off, but we believe in “safe by default” at Discourse, and extremely large topics were no longer safe, at least for some clients.

This was meant to be a temporary solution as it was a significant amount of engineering effort to create a solution where we sent down only a partial list of topic ids based on what you are viewing. We planned to revisit this later.

However, as we started to investigate MEGATOPICS, it became clear that they are

  • not that common
  • often quite problematic

… and now after looking at this for quite some time, with many live examples, I believe that MEGATOPICS should, in fact, be permanently discouraged. Here’s why:

  • Megatopics are impractical to read. By the time you reach 10,000 replies, who in their right mind is going to sit down and read through all 10,000 of those replies? So how does anyone catch up with the current state of the topic – maybe by reading the first post and the first 50 replies? Reading only the last 100 posts? Even using our handy “summarize this topic” function, you’re looking at reading 1,000 of the most liked replies to understand what went on in that topic. Your best bet is for someone to read the whole thing and edit a summary into the first post, which would require a staff member, or the first post to be a wiki.

  • Megatopics are impractical to navigate. How long did it take this topic to get to 10,000 replies? A week? A month? A few years? While you can easily jump to the beginning and end of any topic using the handy timeline feature in Discourse, you are on your own figuring out what exactly happened in the vast middle of that topic. We’ve discussed adding breakpoints or chapters to topics at some point, but there were certainly important “events” in any long running topic you’ll need to dig through the dates and posts to figure out yourself.

  • Megatopics are genuinely rare “in the wild”. Right now I’m looking at the archives of a forum we migrated to Discourse in 2017 that dates back to 2003, and sorting by replies, I count 7 topics out of 87,602 that are over 10k replies. Seven! That’s about 1 megatopic for every ten thousand topics. There’s also a fairly steep dropoff in topic length at that point; only 9 additional topics are over 8k replies.

  • Megatopics tend to lose control of the actual topic. It is normal for a topic to veer and meander, but the longer the topic, the more likely it is that gentle conversational curves morph into radical changes. Furthermore, the longer the topic goes on, the more the world changes around the original opening post that kicked things off – if it is about a then-current news event, for example, other more recent news events may have rendered it moot or significantly altered its meaning and trajectory by now.

  • Megatopics are often users expressing a desire for a chatroom. There’s nothing wrong with the desire for a chatroom, but chat works best in actual chat software, which is designed to host impermanent, rambling, neverending conversations about anything – and where users can create their own channels at will. For example, here’s a topic titled Ask me [warhammer] lore questions which currently has 58,283 replies… and counting.

So here are my recommendations:

  • Use natural breakpoints in topic titles: years, seasons, months. A topic titled “Best Horror Movies” will be hard to find and hard to navigate. But a topic titled “Best Modern Horror Movies” or “Best Horror Movies of 2018” will fare much better.

  • If something significant has changed, start a new topic, and link to the old one. Instead of adding to the “Diablo III” topic, create a new “Diablo III – Reaper of Souls” topic to cover the game’s latest expansion and patches with the changes to the core game as a result. In discussing the Houston Oilers after their 1999 move to Nashville, create a new “Tennessee Titans” topic.

  • For big timeline events, consider creating a new topic. Big events are often worthy of their own topics. A huge release like Smash Brothers certainly deserves a new “Smash Brothers on Switch” topic where people interested in that can easier find it, versus being buried deep in the general Nintendo Switch catch-all topic. This can be linked both to and from the general Switch topic (or the general Smash Brothers topic) as needed, of course, and now it can be found easier via search as a standalone topic.

  • If your users are implicitly telling you they want chat, maybe set one up? It’s perfectly fine for Discourse to live side by side with ephemeral chat, and it’s exactly how we use Discourse internally! Chat doesn’t compete with the longer form conversations on Discourse, it is highly complementary to those conversations. There are plenty of great free chat options out there, like Slack and Discord.

68 个赞

I agree - on a forum there is limited use for a 10,000+ post Topic.

I would just have it so that when it reaches 10K, it’s automatically closed and the system posts a continuation Topic and then links the two. (Perhaps with a mod flag to bypass the restriction).

6 个赞

There’s also the use case of megatopics as landfills. The admins want you to stop trashing the forum with a bunch of garbage, so they’ve given you a landfill to dump it all in.

If off-topic chatter is becoming a problem in a community, instead of relegating it to a single topic within an existing category maybe create an entire “off-topic” category or sub-category. This at the very least grants the content some ability to have structure.

20 个赞

This is on point.

I recommend doing this, locking it to trust_level_0 to hide it from search bots, disabling badges and hiding from latest.

16 个赞

I honestly see no reason as to why this shouldn’t be left in the hands of those who are in charge of the forums. If they want topics to be over 10k then they should have topics over 10k.

Especially if it is a forum where such a thing is quite common.

I guess people can just make “[topic title] part 2” and so on but at that point you gotta wonder why not have it be 1 thing.

With this change we now have a topic sitting at 61k that is locked. Ho boy would that be a lot of parts.

4 个赞

At the end of the day it is up to you, but this topic is about ensuring you understand the ramifications of the choice you are making for the members of your community.

While Discourse is just a part of your life, we live and breathe it and it would be remiss of us if we didn’t ensure that everyone is armed with the knowledge to create the best experience possible for their audience.

17 个赞

For curiosity sake where in the settings can we change the default?

4 个赞

For our hosted customers this is suppressed unless you are an enterprise customer. Allowing megatopics in our multisite cluster causes performance problems so we just restricted this. Note, we do plan to change it so you can increase the PM limit up to 10k.

9 个赞

I’ve used this in the past. In my case, I also muted that category for all members and posted an announcement explaining how you can un-mute it if you’re interested in off-topic discussion.

6 个赞

Agreed. I think the following additional things should happen when a megatopic gets automatically closed:

  1. A continuation topic is automatically created. E.g. “What did you have for lunch today?” gets automatically superseded by “What did you have for lunch today? (2)”. This would work exactly like our Linked Topic creation, along with a closing notice linking to the new linked topic.

  2. If tags are enabled, the topics would also be assigned a generic tag.

1 个赞

Eh, maybe – that’s institutionalizing a) the continuation of exactly the same thing, which might not even be the right call and b) bad topic naming.

Having zero friction here is, I think, the wrong call. How about something more like a hint:

This topic was automatically closed because it was super duper long, like seriously!

Feel free to continue the discussion in a new topic.

Where “new topic” is equivalent to pushing the new topic button.

6 个赞

Chances are if a Topic reaches 10,000 posts - 10,000 is not the natural limit. By closing it you are shutting down something that members, more than likely, want to continue.

Maybe just add a mod setting in addition to what @erlend_sh has said “do not continue topic if reaches threshold”. I would also add an admin setting too (I’d probably want to keep the max to what may be more optimal for the server - so maybe half that at 5K?).

Having said that, if simply auto-closing it is much easier to do - do that, as there’s plenty of other (more useful) things that your resources could go on :smiley:

The SitePoint vBulletin forums had a few “mega threads”. But they were not what I’d call discussions. A few were “game” threads which were more post-to-post where there was no presumption that anyone would read every post from first to last. And there was a catch-all Introductions intended to consolidate multiple “Hi, I’m new here” threads. There were also some “opinion” threads which were little more than a series of “I like __ best” with a sprinkling of substance here and there.

I guess whether or not a community wants non-discussion topics in its forum is up to the community. But in my experience and in my opinion any discussion that starts to get anywhere near “mega” has become full of tangential and repititous posts that make reading from first to last such a major task that it is highly doubtful anyone would do so.

5 个赞

The limit is already a site setting (and has been for quite a while). See auto close topics post count and auto close messages post count. If you are self-hosted you are free to change these settings as much as you wish. On discourse.org hosting we’ve enforced the 10,000 post count setting globally (as Sam mentioned above), so that cannot be changed.

6 个赞

Revisiting this after a year, and after some experience with the philosophy of decentralized social networks, I have another way to frame the problem:

Discourse didn’t want to fix the performance problem because megatopics are trying to scale the software past the human limits.

10,000 replies is clearly arbitrary. But it’s also clearly way too many posts for a single topic. It’s just like the follower / following performance limits on Twitter-like platforms: if you actually need 100k followers, consider a blog instead :wink:

18 个赞

大主题帖很糟糕,第二部分:

作为一名刚加入 College Confidential 不久的用户,也是一位正在帮助高二学生应对大学申请流程的家长,我发现这些 [大主题帖] 令人应接不暇。我既对 像 doschicos 这样的人 慷慨提供相关信息感到 overwhelmed,同时也对这些 [主题帖] 的长度和复杂程度感到不知所措。我发现它们难以阅读,更难以从中进行分析以用于内容审核。

13 个赞

对于专注于具体任务且有明确终点的论坛来说,巨型话题(megatopics)是不利的。开放式社区讨论很容易在保持单一狭窄主题的同时迅速达到 1 万条回复。

我共同管理一个拥有不到 500 名注册用户的论坛,主要讨论新闻和时事,我们经常触及这一限制。我们关于 COVID-19 的第三个专属话题已经进行到一半,此外还有多个相关子话题。第二个话题仅在 21 天后就被迫关闭。

话虽如此,即使对我们而言,开启新话题也并非什么大事。虽然理论上我更喜欢拥有无限的话题容量,但如果实现这一功能需要付出巨大努力,我们也是可以接受的。

但我不认为巨型话题应该被视为罕见的边缘情况,也不应假设它们总是弊大于利。一些成熟的社区甚至以拥有既庞大又持久的单一话题为荣。

4 个赞

大主题总是一件坏事。这暗示你需要一个真正的聊天室。

这些社区已经死亡或正在消亡。它们只是尚未意识到这一点,因为缺乏自我认知。

8 个赞

我们关于 COVID-19 的主题帖情况也类似。第一个主题帖在运行两个月后不得不关闭,随后开启了第二个——而这个也将在一个月结束时关闭。由于帖子数量增长非常迅速,我们将每月开启一个新的主题帖。值得称赞的是,大家(包括我们自己)的讨论大多紧扣主题,只有少数帖子偏离到了政治话题上,但毕竟疫情本身已与政治紧密交织。此外,我们还专门设立了一个仅用于讨论 COVID-19 相关研究的主题帖,以及一个专门用于追踪病毒传播、病例数、死亡人数等数据的主题帖。

我们将每个主题帖的帖子数量上限控制在 1,000 条。我们是一个小型私人论坛,因此避免了其他论坛所面临的两难困境。

1 个赞

我们尝试过使用聊天室,但我们的用户更偏好你们的软件。

6 个赞