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

您好,亲爱的 Discourse 员工,你们用自己的产品精心维护着这个很棒的在线论坛。

我注意到我们为 Support 启用了 Solved Plugin。很高兴看到这种很棒的 dogfooding 实践!fixedcompleted 标签的使用也是如此。

不幸的是,#support、#bug、FeatureUX 中有大量的帖子没有标记这些。这让论坛用户感到非常困惑,并阻碍了对现有解决方案的有效搜索。基本上,如果这些标签不能被一致地使用,那么它们可能根本就不应该被使用。

我是否可以请求在未来优先处理此事,并指派某人(?实习生,??AI)负责正确标记旧的帖子?

10 个赞

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

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

3 个赞

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

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

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

2 个赞

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

4 个赞

谢谢分享背景信息,詹姆斯!:hugs:

那么总结一下,目前我们有五种方式来指示一个话题已经结束,需要进行收尾。这是否大致概括了情况?

什么 哪里
:check_box_with_check: Discourse Solved Support Installation Dev Data & reporting SSO 话题所有者,@team,TL4
fixed Bug UX (适用于所有地方) @team
completed Feature UX @team
delivered Marketplace 所有成员
:locked: close topic 所有地方 @team 和自动

我觉得这确实有太多的多样性了。我不知道为什么标签会不一样。也许能够单独浏览这些标签列表对大家来说是有帮助/有信息的。然而,这些标签及其用途并不容易被发现。

:check_box_with_check: solved 很容易被发现,并且在支持方面效果很好。我认为将其限制在该类别是合理的。能够在此类别中按已解决/未解决的话题进行筛选很有帮助——我经常忘记那个下拉菜单,希望它在UI中更容易被发现。:blush:

fixed 仅在 Bug UX 中使用,表示一个 bug 或 UX bug 已被修复。

completed 也用于 Support Feature #ux。UX 是因为 UX 话题通常也是功能请求。有一个话题,"Reader Mode" theme component feedback Site feedback 中,但我现在已将其移至 Theme component,现在组件已发布,那里似乎更合适。

delivered 仅在 Marketplace 中使用。

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

  • Support 话题在解决后一个月关闭,如果最后回复时间超过一个月
  • Marketplace 话题在最后回复时间超过一个月后关闭,无论是否 #delivered。
  • 版主关闭话题
    • 当问题解决时
    • 为防止回复(例如文档或 release-notes
    • 作为一种管理策略,以结束那些变得没有成效或已经结束的话题

一些潜在的后续步骤:

  • fixed completed delivered 标签添加描述,解释我们如何使用它们
  • 创建一个数据探索器查询,其结果类似于上表,但列出已解决/未解决、已修复/未修复、已完成/未完成、已交付/未交付话题的实际和最新数量
  • 创建一个数据探索器查询,列出在给定时间范围内已关闭、已修复、已完成、已交付的话题
  • Site feedback 中创建一个话题,每周使用自动化分享上述查询的结果
  • 在这里创建一个带有简短操作指南的话题,用于收尾话题,并组建一个团队来按照时间倒序开始处理列表
4 个赞

我添加了如下说明,当您将鼠标悬停在标签上或转到标签页面时会显示。如果您有任何建议,请告诉我。我正在权衡是保持简洁还是提供更详细的上下文。类别本身也有更详细的说明。

fixed

我们优先修复在 BugUX 类别中报告的软件错误。一旦错误得到修复,就会被标记为此标签。

completed

FeatureUX 类别中建议的功能实现后,就会被标记为此标签。

delivered

Marketplace 中的主题被提供者或接收者确认交付后,就会被标记为此标签。

3 个赞

哎呀。你把它说得太复杂了。 :slight_smile:

表面上,你给已修复的 bug 打上 fixed 标签,给已实现的特性请求打上 completed 标签。 [1] 这是关闭话题流程的一部分(并让相关方了解相关信息)。最初实施这些标签是为了提供一种“好事发生了”的视觉指示,而不是像已关闭话题那样只有一个锁定符号。当这些标签得到一致应用时,你在滚动浏览其类别话题列表时会看到一片漂亮的绿色。

(而 delivered 是一个单独但类似的标签,它不受团队控制,因此可以在 Marketplace 中使用)

对于“已解决”,有很多类别都启用了它,而不仅仅是通用的 Support 类别。几乎任何大部分话题都是可以得到解决方案的问题的类别。#support、#installation、#dev、#data-reporting、SSO

理想情况下,最佳做法是由 OP 标记解决方案,但我们知道这有时不会发生(出于各种原因),所以我通常会在几周后(一旦它们被视为“被放弃”)滚动查看话题列表并清理一些未解决的问题。

供参考,该主题组件的话题是 https://meta.discourse.org/t/reader-mode/307916,所以你链接的那个 feedback 话题实际上不应该在 Theme component 中(因为它不是一个主题组件话题)。它可能应该在 FeatureUX 中,因为我认为现在有更多这样的组件存在,它们已经归于这些类别。

(我认为它在 Site feedback 中,因为它是在 meta 上的一次实验)


  1. UX 则介于两者之间,可以根据具体主题的“风格”来使用 ↩︎

8 个赞

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

自从您离开后,这从未被系统地完成过,这就是为什么我们现在有这个话题来讨论如何赶上进度并建立一个系统,以免再次落后。

说得好!我已经将其移至 #feature。

1 个赞

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

6 个赞

我重新回到这个主题,因为我最近因为在一个我认为应该标记为 completed 的主题中标记了它,但它却没有被标记,而受到了训斥。

我本来只是想自己给它打上标签。然而,由于该标签仅限于 @staff,所以我不能这样做。嘿,作为一个 TL4,我可以做很多可能有破坏性的事情,但就是不能做那件。在某些分类(例如 Plugin)中,我甚至完全不能编辑标签。

那么,如何在不打扰版主并被训斥的情况下,向他们指出这些小问题呢?或者,计划就是让它有点乱吗?

6 个赞

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

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

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

6 个赞

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

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

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

6 个赞

我不确定我是否认同这是原因。它最初的实施是为了提供一个视觉指示器,将已完成的功能请求与其余已关闭的主题区分开来。这里有一段关于我、Sam 和 Dave 之间的对话,如果你搜索一下,可以找到更多信息。(我想是在一些私信中,但不太确定具体位置)

就个人而言,我当时觉得跟进它并不是一件特别繁重的事情。:person_shrugging: 我的确更专注于“活动”窗口,以确保 /latest 顶部的主题更加一致,但我也会处理偶然遇到的其他主题(相关主题等)。对 Feature 类别进行全面审计确实是一项更大的工作。:slight_smile: (并不是说梳理/合并/关闭多年来被遗漏的任何内容没有用,只是说这会很耗时,你需要权衡它在优先级列表中的位置。)

这是对可能发生的事情的担忧,还是这确实已经在发生?如果只是偶尔发生一次,我不认为那是个大问题,但如果它成为一种模式,我同意标记系统就不是最佳的解决方案。我认为私信(PM)是一种不那么具有侵入性的收集信息的方式。

但我也理解你不想让开发人员和设计师等人员过深地卷入其中,因为他们还有其他重要工作要做,而不是整理元信息。: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 个赞