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

贡献 网站反馈
1

我想和大家聊聊我正在尝试的一项实验。你们中的一些人可能比我更了解社区的历史，所以请不吝赐教！ :hugs:

我已经将 Support（支持）分类设置为：在最后一次回复后的 30 天自动关闭主题。鉴于我近期在该分类中的经验，这似乎是合适的。到那时，问题通常已经解决，或者提问者已经不再关注。其他有类似疑问的人可以针对自己的具体情况开启新的主题。

过去几个月里，我一直在处理 Support 分类中那些未解决的旧主题，使用的是侧边栏中的这个过滤器。在许多情况下，由于非常细心且乐于助人的成员回答问题，主题实际上很快就能得到解决。:hugs: 有时，在一两周后，主题确实需要一点推动，以便检查提问者的问题是否已解决，并询问一些澄清性的问题以帮助他们（例如：重现步骤是什么？你使用的是官方安装说明吗？安全模式下是否有效？等等）。当我这样做时，我通常会添加一个主题计时器，使其在最后一次回复后 30 天自动关闭。如果提问者或社区中的其他成员在 30 天内没有回复，我认为让主题自动关闭是完全没问题的。

然而，也存在将主题从 Support 移动到另一个分类更有意义的情况，我也一直在这样做。例如：
→ #community（社区）= 开放式社区建设问题
→ Development（开发）= 定制、创建新插件等
→ Contribute > Feature（贡献：功能）或 Contribute > UX（贡献：用户体验）= 功能请求或用户界面改进/修复
→ Contribute > 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 的存在，你甚至不必为决定标题、类别和标签而犹豫不决。在我看来，关于关闭所有支持主题的严格规定已经过时了，而且在旧的论坛软件上是必要的。

14 个赞
9

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

我可能对此有误，但根据我近几个月的经验，我的感觉是 Support（支持）版块与我们目前的其他版块有所不同。人们来到这里是为了立刻解决问题，而且这些问题几乎总是与他们的具体情况紧密相关。如果话题不能在合理时间内得到解决，他们就会失去兴趣并离开，或者变得不耐烦并在其他话题中再次提问。与此同时，支持版块可能会充斥着未回答的问题。后来的旅行者为了提出自己略有不同的问题而顶起这些旧帖，但这其实更适合开一个新话题。

这与我们允许并鼓励开放式讨论的其他版块不同。当人们将本应属于其他版块的话题发布到 Support 时，例如这实际上是 Contribute > 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 这一操作。但在我保存更改时，界面却没有发出警告，这有点奇怪。我已在 Contribute > UX 话题中 指出了这个问题。

1 个赞
14

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

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

2 个赞
15

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

1 个赞
16

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

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

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

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

3 个赞