meta.discourse.org 上主题标记为 ☑️ 已解决、已完成或已修复的不一致问题

你好,亲爱的 Discourse 工作人员,感谢你们用自己的产品运营并悉心维护这个精彩的在线论坛。

我注意到我们在 Support 板块启用了“已解决”(Solved)插件。看到这种精彩的自产自销实践,令人欣喜!同样令人赞赏的还有对 fixedcompleted 标签的使用。

然而,遗憾的是,#support、#contribute:bug、Contribute > FeatureContribute > UX 板块中有大量帖子尚未标记这些标签。这对论坛用户来说相当令人困惑,也阻碍了对现有解决方案的有效搜索。基本上,如果这些标签不能得到一致使用,那么它们可能就不应该被使用。

我恳请今后将此事项列为优先事项,并指派专人(可能是实习生,或者是 AI)负责正确标记那些旧帖子。

10 个赞

谢谢你,Nathan!感谢你提出这个问题。:sunflower: 我们确实希望在这方面做得更多。

看起来为 Support 类别启用解决方案在该类别中效果相当不错。fixedcompleted 标签也很有帮助,可以在所有类别中使用。

3 个赞

我没有在 Marketplace 中看到 completed 标签。

我认为这些是仅限员工使用的。

也许可以将其扩展到 trust_level_3?正如 Jay 在上面指出的那样,这也有助于 #marketplace。

2 个赞

FWIW 对于 Marketplacedelivered,它不限于团队。

4 个赞

感谢分享这些背景信息,James!:hugs:

总之,目前看来我们有五种方式表明一个话题已经告一段落,需要收尾。这样概括是否准确?

方式 位置 责任人
:check_box_with_check: Discourse Solved Support #installation Development #data-reporting Support > SSO 话题所有者、@team、TL4
fixed Contribute > Bug Contribute > UX(适用于所有地方) @team
completed Contribute > Feature Contribute > UX @team
delivered Marketplace 所有成员
:locked: 关闭话题 所有地方 @team 及自动机制

这确实感觉种类繁多。我不确定为什么标签会有所不同。也许这样有助于用户分别浏览这些标签列表。不过,这些标签及其用途并不那么容易被发现。

:check_box_with_check: 「solved」标签很容易被发现,且在支持类话题中效果很好。我认为将其限制在支持类别中是合理的。在该类别中能够筛选已解决/未解决的话题很有帮助——不过我常常忘记使用那个下拉菜单,希望它在界面中更醒目一些。:blush:

fixed 仅用于 Contribute > BugContribute > UX,表示某个 bug 或用户体验问题已修复。

completed 用于 #support、Contribute > Feature#contribute:ux。之所以也用于 Contribute > UX,是因为用户体验类话题通常也包含功能请求。曾有一个话题 "Reader Mode" theme component feedback 位于 Contribute > Site feedback,但我已将其移至 Customization > Theme component,因为随着该组件的发布,它现在似乎更适合放在那里。

delivered 仅用于 #marketplace。

话题因多种原因被 :locked: 关闭:

  • Support 类话题在得到解决后,若一个月无新回复则自动关闭
  • Marketplace 类话题无论是否标记为 delivered,若一个月无新回复则自动关闭
  • 版主手动关闭话题
    • 当话题已解决时
    • 为防止继续回复(例如文档类或 release-notes 类话题)
    • 作为管理策略,用于结束已失去建设性或已告一段落的讨论

一些可能的后续步骤:

  • #fixed、completeddelivered 标签添加说明,解释我们如何使用它们
  • 创建一个数据探索器查询,生成类似上表的结果,但列出实际且最新的已解决/未解决、已修复/未修复、已完成/未完成、已交付/未交付的话题数量
  • 创建一个数据探索器查询,列出在指定时间段内被关闭、修复、完成或交付的话题
  • Contribute > Site feedback 中创建一个话题,每周通过自动化方式分享上述查询结果
  • 在此创建一个话题,提供一份关于如何收尾话题的简易指南,并组建一个团队按照该指南,按时间倒序逐步处理待收尾的话题列表
4 个赞

我添加了如下说明,当鼠标悬停在标签上或进入标签页面时会显示。如果你有建议,请告诉我。我在保持简洁和提供更详细的上下文之间有些纠结。这些分类本身也有更详细的描述。

fixed

我们优先修复在 Contribute > BugContribute > UX 分类中报告的软件错误。一旦错误被修复,就会打上此标签。

completed

当在 Contribute > FeatureContribute > UX 分类中建议的功能被实现时,会打上此标签。

delivered

Marketplace 中的主题被提供者或接收者确认已交付时,会打上此标签。

3 个赞

天哪,你说得好像很复杂似的。:slight_smile:

表面上看,你只需在已修复的 bug 上添加 fixed 标签,在已实现的功能请求上添加 completed 标签。[1] 这是关闭话题流程的一部分(同时也让相关方及时了解最新进展)。最初引入这些标签是为了提供某种视觉提示,表明“好事发生了”,以区别于表示话题已关闭的锁形图标。当这些标签被一致应用时,在滚动浏览类别的话题列表时,你会看到一片令人愉悦的绿色波浪。

delivered 是另一个独立但类似的标签,不由团队控制,因此可用于 Marketplace

对于“已解决”(Solved),除了通用的 Support 类别外,还有许多其他类别也处于活跃状态。基本上,任何大多数话题都是可以获得解答的问题的类别都适用。例如:#support、#installation、#dev、#data-reporting、#support:sso。

理想情况下,最佳实践是由原帖作者(OP)标记解决方案,但我们知道这有时不会发生(原因多种多样),所以我通常会定期回溯话题列表,在几周后(一旦话题被视为“已废弃”)清理一些尚未解决的话题。

仅供参考,该话题对应的 Customization > Theme component 主题是 https://meta.discourse.org/t/reader-mode/307916,因此你链接的那个 feedback 话题实际上不应该放在 Customization > Theme component 中(因为它不是一个主题组件话题)。它可能应该放在 Contribute > FeatureContribute > UX 中,因为随着这类话题越来越多,它们似乎已经主要集中到了这些类别中。

(我认为它最初是在 Contribute > Site feedback 中,因为这是在这里进行的一项实验)


  1. 至于 Contribute > UX,它处于两者之间的过渡地带,具体使用哪个标签取决于特定话题的“风格”。 ↩︎

8 个赞

太棒了!谢谢你填补了这些空白。我已经更新了上面的表格。

自你离开后,就没有系统性地做过这件事,这也是为什么我们现在有这个主题来讨论如何赶上进度并建立一套机制,以免再次落后。

说得对!我已经把它移到了 #contribute:feature。

1 个赞

是的,我想这就是我发帖时想表达的意思。@JammyDodger - 我们想念你和你为让 Meta 顺利运行所付出的努力!我个人希望他们能给你一个你无法拒绝的提议……

6 个赞

我之所以回到这个话题,是因为我最近因为标记了 Contribute > Feature 中的一个话题而受到了责备。我认为这个话题应该被标记为 completed,但实际上并没有。

我希望能够自己给它打上标签。然而,由于该标签仅限于 @staff,我无法这样做。嘿,作为一个 TL4,我可以做很多潜在破坏性的事情,但就是不能做这个。我甚至无法在某些分类中编辑标签(例如 Customization > Plugin)。

那么,人们应该如何在不引起管理员反感并被训斥的情况下,将这些小问题反馈给管理员呢?还是说,计划是让它保持一团糟?

6 个赞

我认为可以将主题标记为“其他事项”,并说明您认为它应该被标记为已完成/已修复,至少对于“旧”主题(即:已完成/修复 6 个月但主题尚未更新的主题)是如此。

(尽管其他人对此有不同意见)

对于紧急事项:我们的工作人员最好确保跟进他们修复的事情。

6 个赞

我认为,如果我们为这个论坛活跃的过去 13 年中每个已完成的功能添加标签,只是因为人们有强迫症(OCD),那将是所有人浪费时间。

该标签本身是较新的,从未被广泛采用,我们可以简单地关闭已完成功能的帖子,允许每个人根据需要创建新帖子并引用旧帖子。

我宁愿删除 completed 标签。它被应用了 400 次,最初只是为了帮助人们编写更新日志,但现在处理方式已经不同了。

6 个赞

我不确定这是否是真正的原因。最初实施它的目的是提供一个视觉指示器,将已完成的特性请求与其他已关闭的话题区分开来。这里 somewhere 有我与 Sam 和 Dave 之间的对话,其中包含更多信息,如果你搜索一下的话。(我想是在某些“悄悄话”中,但具体位置记不清了)

就我个人而言,当时我觉得要跟上节奏并不算特别繁重。:person_shrugging: 我确实更专注于“活跃”窗口,以确保/latest 页面顶部的话题更加一致,不过如果其他话题出现在我的视野中(如相关话题等),我也会处理。对 Contribute > Feature 类别进行全面审计确实是一项更大的工作。:)(这并不是说梳理并清理/合并/关闭多年来被遗漏的话题没有价值,只是想说这会非常耗时,你需要权衡它在优先级列表中的位置)。

这是对可能发生的状况的担忧,还是这种情况实际上已经发生了?如果只是偶尔发生,我认为问题不大;但如果成为一种模式,我同意标记系统并不是处理此事的最佳方式。我认为私信会是收集这些信息的一种更少侵扰性的方式。

但我也理解,你并不希望开发人员和设计师等被过多地卷入其中,因为他们还有更重要的工作要做,而不是来整理元数据。:heart:

4 个赞

也许那些需要版主处理但不紧急的事情,可以通过私信报告给一个单独的群组收件箱。这样整理性的记录就不会淹没审核队列,从而不会掩盖那些需要尽快采取行动的主题,但仍然有一个地方可以收集这些内容,以便有人在有空闲时间时可以处理它们。

这可以适用于所有类型的附注,例如缺少标签、主题组件主题中损坏的预览链接,或者可以关闭的功能主题,以便将票数返还给用户。

6 个赞

哦!我才意识到版主组里没有人!现在我明白为什么我几周前发给 @moderators 的私信没有得到回复了…… :sad_but_relieved_face:

我创建那个是为了我“更温和、更友善地进行版面管理”的想法的一部分。有一个可以联系到版主并确保会得到回复的单一联系点非常重要。我希望重新考虑移除那个的决定。

另外,为了更友善、更温和,我尽力避免将“浪费时间”作为版主决定的理由。我不认为那些旨在帮助保持讨论整洁的、善意的社区领导者应该因此感到难过。

回到主题……我有一个常规的待办事项是审查和清理旧的主题,这是一个很好的手动任务,因为我经常能顺带处理掉一些遗留问题。有时主题可以直接删除,或者可以合并等。但这确实是一项艰巨的任务,我只做到了几年前的内容。

我赞成允许像 @nathank 这样受信任的老用户添加标签,而不是让他们标记主题以供工作人员审查,尤其是在目前没有社区经理或专门的版主团队的情况下。

编辑:我的侧边栏里仍然有链接!这些链接是为了查看开放、未解决且超过一周的主题。我仍然觉得这些链接对了解我们解决主题的进展情况很有帮助。如果工作人员没有时间做这件事,也许我们更多的人可以帮忙做一下。

5 个赞

我们目前正处于版主管理的一个过渡期,因此我们此时所做的某些决定可能不会持久,但就这个特定主题,这是我的两分钱:

我认为我们应该努力达到这样的境地:

  • 标记(Flags)用于更重要的事情
  • 我们有一种方法来处理其他更琐碎的事情,或进行一般性的整理(gardening)

如果我们想使用 completed(已完成),那么我们应该授权一组人来处理此事,而无需使用标记。或许:

  • 授予 TL3 和 TL4 权限,以便将事物标记为“已完成”
  • 创建一个“整理”(gardening)主题,人们可以在其中对任何类型的“内容整理”提出建议
4 个赞

我非常感谢。由于您只能举报一次帖子,以后不能再举报,我一直不愿将标记用于琐碎的问题,例如主题组件主题中不再起作用的预览链接。

我建议使用收件箱,因为我认为存档已处理的请求可能有助于跟踪已解决的问题。这在回复很多的帖子中可能会更困难。

我不确定添加 completedfixed 标签但无法关闭主题有多大帮助。如果仍然需要其他人来关闭主题,这帮助不大。

6 个赞

我们正在考虑对带有这些标签的主题执行自动化关闭操作——不确定将这些实验推向完成有多难。

3 个赞

提供我对这个问题的看法。

我每天都会阅读每一篇帖子。真的。我最后一篇未读的帖子是在 2024 年 6 月。因此,我看到了无数的 bug/ux 报告被修复或完成。通常情况下,我只会标记它们以便关闭。我不太觉得需要使用 fixedcompleted 标签,只需要关闭主题即可。在我看来,仅此一项就表明该主题已解决。

另一方面,我也同意这个观点:

所以,如果

被实现,并与

相结合,我认为这将非常完善。

3 个赞