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

网站反馈
1

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

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

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

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

8 个赞
2

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

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

3 个赞
3

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

4

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

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

2 个赞
5

FWIW 对于 Marketplace 有 delivered，它不限于团队。

4 个赞
6

谢谢分享背景信息，詹姆斯！: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 中创建一个话题，每周使用自动化分享上述查询的结果
  • 在这里创建一个带有简短操作指南的话题，用于收尾话题，并组建一个团队来按照时间倒序开始处理列表
3 个赞
7

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

fixed

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

completed

当 Feature 和 UX 类别中建议的功能实现后，就会被标记为此标签。

delivered

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

3 个赞
8

哎呀。你把它说得太复杂了。 :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 中（因为它不是一个主题组件话题）。它可能应该在 Feature 或 UX 中，因为我认为现在有更多这样的组件存在，它们已经归于这些类别。

（我认为它在 Site feedback 中，因为它是在 meta 上的一次实验）

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

6 个赞
9

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

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

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

1 个赞
10

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

4 个赞