最后回复后 30 天自动关闭支持主题

网站反馈
1

我想和大家沟通一下我正在进行的一项实验。你们中有些人可能比我更了解社区的过往，所以请教教我吧！ :hugs:

我已经将 Support 分类设置为在最后回复后 30 天自动关闭主题。鉴于我最近在该分类中的经历，这似乎是合适的。届时，主题要么已经解决，要么提问者已经离开。其他有类似问题的人可以根据自己的情况开启新主题。

在过去的几个月里，我一直在处理 Support 分类中未解决的旧主题，使用的是我侧边栏中的这个过滤器。在很多情况下，由于社区成员非常专注和乐于助人，主题会很快得到解决。:hugs: 有时，主题在几周后需要一些推动，以便跟进提问者，了解他们的问题是否已解决，并询问一些有助于他们解决问题的澄清性问题（重现步骤是什么？你是否使用了官方安装说明？在安全模式下是否有效？等等）。当我这样做时，我通常会设置一个主题计时器，在最后回复后 30 天自动关闭。如果提问者或社区中的其他成员在 30 天内没有回复，我认为让主题自动关闭是完全可以的。

然而，有时将主题从 Support 移动到其他分类也是有意义的，我一直在这样做。例如：
→ Community = 开放式的社区建设问题
→ Dev = 定制、创建新插件等
→ Feature 或 UX = 功能请求或用户界面改进/修复
→ Bug = bug 报告

通过将 Support 中的主题设置为一个月后自动关闭，而不是手动关闭，我节省了一些时间，因为目前使用管理员工具栏进行此操作有点麻烦。这需要点击好几次！

3 个赞
2

您是否考虑过如何查找在 Support 中发布的帖子，因为这些帖子是预先选定的，然后由社区成员移至其他类别？我可以移动帖子，但我无法移除计时器。因此，在我移动帖子后，需要其他人移除计时器。

这类似于移至 community-wiki 的帖子未成为 wikis，并且从那里移出的帖子仍然是 wikis。 但从该类别移出或移入该类别的帖子比从 Support 移出的帖子要少。

3 个赞
3

感谢您提出这一点。您可能只需将其标记给版主以进行更改，除非您认为您将一直这样做。您现在多久在类别之间移动主题一次？

4

我们将拭目以待 :innocent:

或者，您可以要求数据浏览器查找在某个时间段内移动了多少主题

示例查询 
-- [params]
-- date :start_date
-- date :end_date

SELECT
  pr.user_id,
  (regexp_match(pr.modifications, 'category_id:\s*-\s*([0-9]+)\s*-\s*([0-9]+)'))[1]::int AS old_category_id,
  (regexp_match(pr.modifications, 'category_id:\s*-\s*([0-9]+)\s*-\s*([0-9]+)'))[2]::int AS new_category_id,
  COUNT(*) AS change_count
FROM post_revisions pr
WHERE pr.modifications LIKE '%category_id:%'
  AND pr.modifications ~ 'category_id:\s*-\s*[0-9]+\s*-\s*[0-9]+'
  AND pr.updated_at::date BETWEEN :start_date::date AND :end_date::date
GROUP BY pr.user_id, old_category_id, new_category_id
ORDER BY pr.user_id, change_count DESC
1 个赞
5

谢谢你的提问，Moin！

此 mod 提供了一个起始类别选择器，并按日期列出了从该类别中移出的单个主题：

-- TOPICS MOVED LIST
-- [params]
-- date :start_date
-- date :end_date
-- category_id :cat_id

SELECT
  pr.user_id, pr.post_id, pr.updated_at,
  (regexp_match(pr.modifications, 'category_id:\s*-\s*([0-9]+)\s*-\s*([0-9]+)'))[1]::int AS old_category_id,
  (regexp_match(pr.modifications, 'category_id:\s*-\s*([0-9]+)\s*-\s*([0-9]+)'))[2]::int AS new_category_id
FROM post_revisions pr
WHERE (regexp_match(pr.modifications, 'category_id:\s*-\s*([0-9]+)\s*-\s*([0-9]+)'))[1]::int = :cat_id::int
  AND pr.updated_at::date BETWEEN :start_date::date AND :end_date::date
ORDER BY pr.updated_at DESC

move_list
move_list1355×372 22.8 KB

1 个赞
6

我不是那种会比你拥有“更好的社区记忆”的人，但就我所知，你的方法听起来很合理。我很高兴有人在审查未解决的主题——如果我理解正确的话，那些没有回复帖子的主题不会在没有被顶起来的情况下被自动关闭（我自己也有几个这样的帖子……）

1 个赞
7

@tobiaseigen 我认为主题通常在创建后的 1-3 天内被移动。也许主题计时器应该从第 3 天开始添加，以便在主题被移动时提供一些缓冲时间？不过我怀疑这是否可能在没有插件的情况下实现。

1 个赞
8

关闭所有主题有什么好处？当人们遇到与发帖人相同的问题时，回复一个已存在的主题（即使该主题很旧）有什么问题？

Discourse 可以轻松地将跑题的回复拆分成一个新主题，只需点击几下即可完成，而且由于 AI Helper 的存在，你甚至不必为决定标题、类别和标签而犹豫不决。在我看来，关于关闭所有支持主题的严格规定已经过时了，而且在旧的论坛软件上是必要的。

13 个赞
9

太棒了！感谢大家的回复。我很高兴开启了这个话题，以了解大家对此的看法。

我可能错了，但根据我近几个月的经验，我感觉#support（支持）类别与其他类别不同。人们来这里是想立即解决问题，而且问题几乎总是与他们自身的情况息息相关。如果问题没有得到相当快的解决，他们就会失去兴趣并离开，或者变得不耐烦，在其他话题中再次提问。与此同时，支持类别可能会充斥着未得到解答的问题。后来者会通过回复来提问他们自己略有不同的问题，而这些问题最好在新话题中提出。

这与其他类别不同，在其他类别中，我们允许并鼓励开放式话题。当人们在#support类别中发布属于其他类别的话题时，例如，因为它们实际上是#feature request（功能请求），我们可以移动它们。或者，如果有人在寻求创建插件的帮助，我们会将其移至#dev（开发）。

因此，无论如何，#support类别中未得到解答或讨论逐渐消失的话题需要跟进，以便最终得到解决。我认为，几周后添加回复，然后在最后一次回复后30天将其设置为关闭，似乎是一种确保这种情况发生的可行方法。

我在这里听到的声音是，在30天后自动关闭所有#support类别的话题可能不是一个好方法，因为我们经常移动它们，这意味着我们必须移除计时器。但我仍然认为我们应该以最终关闭所有#support类别话题为目标。

所以，我现在将关闭自动设置，但仍会在我认为合适的情况下添加计时器。如果你注意到我在某个话题上设置了计时器，而你认为不应该设置，请告诉我原因。

3 个赞
10

我尝试运行了数据浏览器查询，发现在过去四周内，我们总共将 53 个主题从 Support 移到了其他类别。这个数量足以让要求版主移除自动计时器变得非常不方便。

所以，我们得重新考虑如何确保所有在 Support 中发帖的人都能得到及时的回复！

看起来添加计时器在主题被标记为已解决时会自动关闭的类别设置时出现了问题。我现在将其设置为 72 小时，因为我不记得它之前具体设置的是多少了。

11

作为用户，当我遇到一个问题，找到一个我想发帖的相关主题，却发现它已关闭（不是指已 :check_box_with_check: 解决的主题）时，我总是感到沮丧。

然后我不得不联系工作人员，请求他们打开该主题，或者在原始主题本应回复的情况下创建一个新主题。

我不是特指元（meta），而是指我在其他论坛上遇到的用户体验。:smile:

8 个赞
12

是 30 天。您可以在这里看到它，例如 Passkey as (mandatory) 2FA

1 个赞
13

谢谢！已修复。它以小时为单位指定，而不是天或月，所以我不得不拿出计算器。720 小时！

编辑：另外，我刚想起我可以查看员工操作日志。它确实记录了我添加自动关闭计时器时删除了 720。但它在保存更改时没有在 UI 中警告我，这有点奇怪。我在 UX 主题中指出了这个问题：https://meta.discourse.org/t/category-settings-unexpected-solved-setting-change-due-to-auto-close/387583?u=tobiaseigen。

1 个赞
14

我也遇到过这种情况。我通常会开一个新话题，标题是“继续讨论[已关闭话题]……”

有时我只是想添加一个想法或建议，而不是进一步提问——但我认为支持人员的优先事项必须是新问题的可见性。如果已解决的话题可以一直开放供补充帖子，那么确保这一点似乎会很困难。

2 个赞
15

Virtualmin - Virtualmin Community 是一个例子：所有主题都会在两个月后自动关闭，无论其内容如何，也无论是否已解决。

1 个赞
16

为了结束这次谈话……感谢您的所有意见和帮助我思考。

对于#support主题，我仍然坚信目标是在绝大多数情况下在几周内关闭它们。这是确保每个寻求帮助的人都能及时得到答复的唯一方法。否则，人们将开始失去信心，并会到别处寻找答案。

我注意到，如果有一个理由让某个主题保持开放状态，那么它通常也适合移至另一个类别。

但我同意，在最后回复后30天自动关闭#support主题的想法对我们来说是行不通的。我们希望确保它们得到实际解决，并避免出现类别中充斥着未答复或仅半答复的问题的情况。

3 个赞