根据“谁最有可能修复它”来选择一个类别，感觉有点奇怪。如果一个全局 display: none 导致论坛变为空白，你也会说它不是 bug，因为设计师会修复它吗？
当然，你可以说“没关系，随便选一个，我们可以移动它”，但这只对发帖有帮助。当我尝试查找之前的报告时，我会在 UX 中搜索这两个问题。是否有可能独立于类别来跟踪修复的责任？
10 个赞
我和你一样，这额外地令人困惑，操作员很难知道该怎么做。
@tobiaseigen / @jordan.vidrine 对这个问题有什么看法？
@Moin 对如何能做得更好有什么建议？
我想一种替代方法是简单地将内容无条件地放在 feature/bug 中，并使用标签来表示用户体验。
这确实是个棘手的问题。
4 个赞
这对我来说似乎是一个不错的解决方案。很明显应该发布到哪个类别，而那些关心用户体验的人可以关注该标签。另一个好处是我们可以消除一个类别！
不确定如何区分目前在 UX 中的主题，这些主题可能需要归入 Bug 或 #feature。这可能是一个很好的练习，可以逐一清理所有内容。
4 个赞
我有一些想法：
- 我认为将 3000 多个主题分成 2 个类别是项艰巨的任务，我想知道谁有时间承担这项工作。
- 此外，我认为并非所有 UX 中的主题都能轻松地分为“功能”和“错误”。对我来说，关于无法翻译的文本的报告不算是真正的错误报告[1]。同样，指出难以理解或过时的文本既不是功能请求也不是错误报告[2]。同样，既不包含错误也不包含具体改进建议的用户体验描述也不适合“功能”或“错误”类别[3]。
- 我不知道你们目前是如何处理的，但我有一个印象，即开发人员在必要时也会处理 UX 主题，反之亦然。我想知道是否可以保持现状，让负责监控某个类别的团队在需要时通知另一个团队，而无需移动帖子。不过，我无法完全评估这一点，因为我不知道之前的流程或现在的流程。
5 个赞
谢谢 Moin！你说得很有道理。我也看了 UX 主题的总数，确实很多！
也许我们遇到的问题是 UX 类别描述不充分，导致人们将本应属于 Bug 或 Feature 的内容发布到那里。以下是我们内部文档中的描述。
UX 类别在 Feature 和 Bug 之间，算是一个折衷。通常情况下，小的显示问题会归入此类，而不是 Bug，并且它将用于对现有功能进行的小幅更改。比任何重大事项更偏向于“生活质量”方面的主题。
通常，处理这些主题将遵循 Feature 类别的模式 - 关于功能类别
标签
嗯，这个我会归类为 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 个赞
建议类别似乎很重要。我的两个社区都有这个类别。
有时某个标签可能会被忽略，或者#ux类别对某些用户来说可能不那么清晰，但建议类别清楚地表明了它的用途。
1 个赞
我认为我们不需要对这里的类别做太多改动，它们已经运行了很长时间，而且错误分类确实会发生，但据我所见，其发生率并不高。如果提及、标签和分配无法满足内部分类的需求，那么我觉得有些地方出了问题……因为我们有很多选择。
2 个赞
2 个赞
在过去几周里，我一直在思考这个话题，因为我参与了讨论，处理了 UX Bug Feature 类别中的话题，并创建了自己的话题。
我认为这绝对是正确的。Sam 和团队成员可以根据需要对话题进行分类和标记，以回应话题并达成解决方案。如果成员对这些决定感到困惑，可以联系 @moderators。
这是一个关于 UX 的绝佳话题示例。它很小，并且专门关于改进界面。它也是我们希望看到的社区成员和团队之间合作的一个很好的例子，这种合作带来了非常好的生活质量的改进。
继续以 Charlie 提到的例子，我们团队需要努力的方向是跟进这些话题直到结束，以便可以关闭它们。即使是这种非常出色的合作也留下了一些悬而未决的问题。这是讨论和合作的自然起伏，我们的工程师和设计师都很忙。因此，用户体验的增强有时会从我们手中溜走，无论建议有多好，或者请求有多小。过一段时间后，@moderators 可以帮助识别这些问题并将其引导回家。
我更新了 UX 类别的描述，以便公开我们内部处理该类别的方法。我希望这将有助于大家更好地理解 UX 与其他类别 Feature 和 Bug 的区别。
关于 Discourse 用户界面中小显示问题和小改动的讨论，以及功能呈现（包括语言和 UI 元素）的方式。比任何大事更像是“生活质量”方面的话题。
我认为我们也应该更多地使用“ux”标签。我认为这有助于分类，有些内容可能是支持或 bug 主题，但与用户体验有关。这也将解决“这是一个 bug，但它是视觉上的东西，应该放在 Bug 还是 UX”的疑问。
=> 将其设为 bug，但加上 ux 标签
我认为 UX 类别主要应该是改进建议，以及不清楚的地方。而不是已损坏的东西。
至少这种区分对我来说是有意义的。
3 个赞
同意在所有三个类别中更多地使用 ux 标签！这样关心用户体验的人就可以关注该标签。
看来我们还没有完全达成一致——在我看来，UX 可以包含 bug 和功能请求，但它们必须是小的“生活质量”改进，而不是大的。如果用户界面中有真正的问题，则将其放入 #bug。如果这是一个主要项目（例如，允许编辑标签的元描述），则将其放入 #feature。
您将如何改进 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 个赞