根据“谁最有可能修复它”来选择类别，感觉有点奇怪。你会因为一个全局 display: none 导致论坛空白，就认为这不是 bug 而由设计师来修复吗？
当然，你也可以说“这没关系，随便选一个，我们可以移动它”，但这仅对发帖有帮助。当我试图查找之前的报告时，我会同时在 Contribute > UX 中搜索这两类问题。是否可能独立于类别来追踪修复责任？
10 个赞
我和你一样，这额外地令人困惑，操作员很难知道该怎么做。
@tobiaseigen / @jordan.vidrine 对这个问题有什么看法？
@Moin 对如何能做得更好有什么建议？
我想一种替代方法是简单地将内容无条件地放在 feature/bug 中，并使用标签来表示用户体验。
这确实是个棘手的问题。
4 个赞
在我看来，这是一个不错的解决方案。它清楚地指明了应该发布到哪个分类，而关心 UX 的人可以关注那个标签。另一个好处是我们能够消除一个分类！
不确定如何处理目前位于 Contribute > UX 中的主题，这些主题可能更适合归入 Contribute > Bug 或 #contribute:feature。这可能是一个很好的练习，去逐一梳理并清理所有内容。
4 个赞
我有一些想法：
- 我认为将 3000 多个主题分成 2 个类别是项艰巨的任务，我想知道谁有时间承担这项工作。
- 此外，我认为并非所有 UX 中的主题都能轻松地分为“功能”和“错误”。对我来说，关于无法翻译的文本的报告不算是真正的错误报告[1]。同样，指出难以理解或过时的文本既不是功能请求也不是错误报告[2]。同样，既不包含错误也不包含具体改进建议的用户体验描述也不适合“功能”或“错误”类别[3]。
- 我不知道你们目前是如何处理的，但我有一个印象，即开发人员在必要时也会处理 UX 主题，反之亦然。我想知道是否可以保持现状，让负责监控某个类别的团队在需要时通知另一个团队，而无需移动帖子。不过，我无法完全评估这一点，因为我不知道之前的流程或现在的流程。
5 个赞
谢谢 Moin！你说得很有道理。我也看了一下 Contribute > UX 这个标签下的主题总数，真的很多！
也许我们遇到的问题在于，Contribute > UX 分类的描述不够充分，导致人们把本应属于 Contribute > Bug 或 Contribute > Feature 的内容也发到了这里。以下是我们内部文档中的描述：
#ux::category 分类有点像 #feature::category 和 #bug::category 之间的“过渡地带”。一般来说，轻微的显示问题会归入此类，而不是 #bug::category；同时，它也是用于处理对现有功能进行小幅度修改的地方。这里更多涉及的是“提升生活质量”类的话题，而非重大改动。
通常，处理这类话题的方式会遵循 #feature::category 分类的模式——关于功能分类
标签使用
嗯，这个我会归类为 bug……从纯粹实用的角度来看，但由于 UX 吸引了更多模糊的东西，所以我自己会更频繁地对其进行分类。
在这种情况下，那个徽章问题在我看来就像一个翻译 bug。
实际上，这也感觉像一个 bug，这里没有可以解释的空间，我们的文本明显是错误的，需要更新。
不过，这在我看来非常符合 UX 的主题，这是一个关于痛点的开放式讨论，还没有具体的建议。它给了我们一个故事，以及将来从中提取特定 bug/功能主题的地方。
也许我们这里需要的是更好地澄清规则，将 UX 留给开放的非结构化讨论和用户故事，并将“明显的缺陷”保留在 bug 中……而“明显的愿望清单”保留在功能中。
我知道这个世界里的一切都很模糊，很难挥舞魔杖解决所有问题。
但更清晰地说明我们的期望肯定会有帮助。
7 个赞
你们现在都在绕过用户了。我们无法（也不会）知道公司如何分配或分类事物。这完全是内部的事情。我们所能做的就是猜测某事是 bug、用户体验问题还是其他完全不同的问题。然后，版主和工作人员会像 Discourse 的核心那样，施展他们的魔法。
那么，这个话题是给工作人员和高级用户准备的，我们这些凡人可以停止关注了，还是有人真的认为，比如我，我分不清图像和图像的区别，这取决于文件还是容器级别发生了什么，我有能力去想 CDCK 内部的哪个职位会处理一个问题？
更广泛地说，至少有两个方面（众所周知）：
- 类别不是有严格限制的逻辑盒子
- 类别是为哪些用户制作的，公开的还是内部的
我不知道……我一直遵循的政策是：
- 如果我不知道问题是否出在我身上，就使用支持
- 如果我感觉某件事是计划这样工作的，就使用用户体验
- 如果某件事停止工作或完全破坏了地方，就使用 bug
但我永远不会根据谁处于什么职位来选择类别。这纯粹是一个管理问题。
2 个赞
我喜欢将 UX 作为标签（也许也可以有 dev 标签？），但我同意可能有一些 UX 情况感觉不属于其他类别。
而且有些主题在技术上可能是一个功能，但它们非常小，在功能类别中投票时会显得格格不入，例如：Clickable components instead of just the Edit button
但也许我们不应该在意？任何要求更改某事的问题都属于功能类别，无论大小如何？
或者也许我们应该有一个“建议”类别——用于那些没有损坏、不是全面的功能请求、也不是关于如何做事情的事情。然后我们可以内部标记为 dev 或 ux。
编辑：意识到我们已经有一个 ux 标签了，只是目前利用率不高。
4 个赞
“Suggestions（建议）”分类似乎很重要。我在我的两个社区中都设置了这个分类。
有时某些标签可能会被忽略，或者 Contribute > UX 分类对部分用户来说可能不够清晰，但“Suggestions”分类则能非常明确地表明其用途。
1 个赞
我认为我们不需要对这里的类别做太多改动，它们已经运行了很长时间，而且错误分类确实会发生，但据我所见，其发生率并不高。如果提及、标签和分配无法满足内部分类的需求，那么我觉得有些地方出了问题……因为我们有很多选择。
3 个赞
深入挖掘一下，我不确定@moin 
我认为这里问题的核心在于：
- Sam 将某个帖子从 Contribute > UX 重新分类到 Contribute > Bug
- Sam 知道触碰任何人的帖子可能会让他们感到难过，或者觉得自己犯了错
- Sam 道歉
- 然后用户感到困惑，想要自我纠正，从而陷入一个痛苦的循环。
也许这里问题的根源在于？
Sam 应该可以自由地根据需要重新分类，以更好地满足我们的业务需求，并且每次这样做时都不应该为此道歉？
2 个赞
过去几周，我一直在思考这个话题，期间我参与了讨论，在 #contribute:ux、Contribute > Bug 和 Contribute > Feature 类别下处理相关议题，并创建了自己的主题。
我认为确实如此。Sam 和团队成员可以自由地对主题进行分类和标记，以便更好地回应主题并推动问题解决。如果成员对这些决定感到困惑，可以联系 @moderators。
这是一个非常典型的应归入 Contribute > UX 类别的主题。它规模较小，专门针对界面改进。这也是社区成员与团队之间理想协作的范例，这种协作能带来非常切实的生活质量提升。
继续 Charlie 提到的例子，我们团队需要改进的一个方面是，将此类主题推进到底并最终关闭。即使像这样出色的协作，也留下了一些未竟事宜。这在讨论和协作的起伏中是自然现象，我们的工程师和设计师也很忙碌。因此，无论建议多好、请求多小，用户体验增强有时仍会被遗漏。过一段时间后，@moderators 可以帮助识别这些问题并引导它们得到解决。
我已更新 Contribute > UX 类别的描述，将我们对该类别的内部处理方式公开。我希望这能帮助每个人更好地理解哪些内容应归入 Contribute > UX，哪些应归入其他类别（如 Contribute > Feature 和 Contribute > Bug）。
讨论 Discourse 用户界面中的次要显示问题和小幅改动，以及功能的呈现方式（包括语言和界面元素）。这类主题更多关乎“生活质量”的改进，而非重大功能。
如果以上内容仍不够清晰，或您能提出进一步的改进建议，请随时告知。我也希望为 Contribute > Bug 和 Contribute > Feature 做同样的处理，但目前会先暂缓。
我认为我们也应该更多地使用‘ux’标签。就我看来，这有助于分类处理：有些话题可能是支持或 bug 类型，但涉及用户体验（UX）。这样也能解决“这是一个 bug，但属于视觉问题，应该放在 Contribute > Bug 还是 Contribute > UX”的疑问。
=> 将其标记为 bug，但加上 ux 标签
我认为 Contribute > UX 类别应主要用于提出改进建议或指出不明确之处，而不是报告已损坏的功能。
至少在我看来，这种区分是有意义的。
3 个赞
同意在三个类别中更多地使用 ux 标签！这样，那些非常关注用户体验的人就可以关注该标签。
不过，我们似乎尚未完全达成共识——在我看来，Contribute > UX 可以包含错误报告和功能请求，但它们必须是小型的“生活质量”改进，不能涉及大型项目。如果 UI 存在严重问题，则应归入 #contribute:bug。如果是大型项目（例如允许编辑标签的元描述），则应归入 #contribute:feature。
您会如何改进 Contribute > UX 类别的描述，以符合您对这一问题的理解？
{“content”:“[quote="tobiaseigen, post:15, topic:378121"]\n您将如何根据您的理解来改进#ux::category类别描述？\n\n[/quote]\n\n好问题。我会说类似这样的话……\n\n当产品技术上按预期工作，但设计、交互或流程给用户带来不必要的摩擦、困惑或效率低下时，就会使用UX主题。\n\n我也赞同它包含：\n\n[quote="tobiaseigen, post:15, topic:378121"]\n功能请求，但它们必须是小的“生活质量”改进，而不是大的东西\n\n[/quote]\n\n但我认为，任何实际损坏的东西，即使很小，也应该只是一个带有UX标签的错误。”,“target_locale”:“zh_CN”}
3 个赞
这作为新的 UX 描述怎么样？感觉有点生硬但更精炼。我认为它可行？（我发布了一个关于我自己的 UX 主题，报告标签在类别横幅中显示不正确）
原文：
讨论 Discourse 的用户界面以及功能的呈现方式（包括语言和 UI 元素）。
当前：
讨论 Discourse 用户界面中细微的显示问题和现有功能的微小更改，以及功能的呈现方式（包括语言和 UI 元素）。与其说是重大问题，不如说是“生活质量”方面的话题。
建议新版本：
UX 主题用于 Discourse 技术上按预期工作，但设计、交互或流程给用户带来不必要的摩擦、混淆或效率低下。也用于小的“生活质量”改进。completed 或 fixed 标签会根据主题的性质应用。
1 个赞
好的，对我来说听起来不错 
太棒了！我已经做了更改。
（题外话：描述的更改需要几分钟才能在类别横幅中显示，这真是太奇怪了。即使是强制刷新也无法做到。）
2 个赞