如以下示例所示，它在那里会有用：
3 个赞
我不确定那是否是个好主意。归根结底，我们作为用户无法修复错误。这只能通过更改 Discourse 代码来完成，这需要团队成员的参与。如果那不是必需的，那么“Bug”可能就不是正确的类别。
我担心用户会将变通方法标记为解决方案。但那样的话，bug 仍然没有被修复。所以这会比有帮助更令人困惑。在你的例子中，问题也没有解决，因为已经有一个 bug 报告了。我认为在这种情况下合并主题是最好的。这样，无论用户最初关注哪个主题，当有修复时，所有用户都会收到通知。有时关闭一个主题并引用另一个主题是有意义的，但那样的话，支持已关闭主题的点赞就会丢失，这对于受影响的用户来说是很遗憾的，因为他们是由点赞决定的。
3 个赞
在 Bug 类别中，我们只使用 fixed 标签。帖子说明某内容是重复的并不能真正解决任何问题，尽管它很有用，所以我认为它在那里也不是一个好的用途。
现在，我们为什么在某些类别中使用 fixed，而在其他类别中使用 solved-plugin，我认为这可能是由于 Moin 已经说过的原因。标签的使用有点严格，所以只有团队才能决定何时修复某项内容。
5 个赞
感谢您的建议！检查类别的设置方式总是有益的，因此感谢您对此进行思考并开启此话题。
正如 Moin 和 Charlie 所指出的，我们的团队依赖于 fixed 和关闭话题（只有我们才能执行的操作）来与社区沟通一个 bug 已经，嗯，被修复了！这似乎运作得相当好，也是我们保持一个相当明显的待修复 bug 积压的方式。
确实，在 bug 类别中，能够提供解决方案的人无法像在启用了已解决插件的类别中那样获得积分，这很可惜。在 bug 类别中，报告 bug 的人如果受到 Discourse 团队成员的喜爱，会获得一个徽章。但其他通过提供重现步骤、指出重复项、提出解决方案等方式提供帮助的人将不会获得积分。这是需要考虑的事情。
在这种情况下，如果您能够感谢 Moin 指出该报告是重复项，那就好了，但保留该话题也会产生一些额外的噪音，使团队更难解析所有打开的 bug 报告。所以希望您不介意，我设置了一个定时器来删除它。
1 个赞
@tobiaseigen，难道这就是锁定功能的作用吗？删除它将导致一些指向它的外部 URI 返回 404，这并不理想。
我们并非什么都保留！ 
我不会太担心 404。
但我们并没有完全一致地实践这一点，因为这会增加额外的工作量。我认为在关闭时自动标记“已修复”是有价值的，然后对于我们未修复的异常情况，我们可以使用特殊标签进行编辑。
但这需要一些新的自动化。
4 个赞
我曾多次遇到这种情况：在查找信息时看到一个看似有趣的链接，但点击后却返回 404，这非常令人不快。
在这种情况下，我会标记该帖子，然后由版主进行编辑/删除。
为了避免这种情况，在删除主题之前，可以查看第一个帖子的链接部分：
然后采取预防措施删除那些链接引用将是最好的，但这也会需要更多的工作。
2 个赞
我向 @tobiaseigen 提出了相反的建议：在添加 fixed 标签时，也自动关闭；与 solved 相同。
也许答案是“是，而且？” 自动化功能可以在主题被关闭时立即添加“fixed”标签，或者在主题带有“fixed”标签时关闭该主题（或安排其关闭）？我们也可以在“UX”中对“fixed”和“completed”标签做同样的事情。
我们是否曾有过在不添加“fixed”标签的情况下关闭“Bug”主题的情况？我看到有很多已关闭的 bug 主题但没有该标签。我今天会花点时间研究一下。
我喜欢“solved”插件的一个行为是，当选择了一个解决方案时，该主题会在最后回复后 30 天自动安排关闭。这很方便，因为它很直接，并且允许人们在仍有需要时进行跟进。它还可能为我们节省工作量，因为人们不会标记主题要求重新打开它。
1 个赞
我不喜欢自动关闭主题 =\u003e 添加标签的原因是，在某些用例中，问题并未修复，或者“永远不会修复”。我认为执行一个操作（“添加标签”），然后该操作自动将主题计时器设置为 30 天后关闭，这是最佳方式。
2 个赞
我花了一些时间研究这个问题，发现 @chapoi 的想法是正确的。我认为我们应该养成一个习惯，为已修复的项目打上 fixed 的标签，然后创建一个自动化程序，设置一个计时器来自动关闭，就像 solved 插件一样。如果情况允许，我们仍然可以立即关闭主题，但在某些情况下，我认为最好将其保持开放一段时间，让人们有机会进行测试并报告他们是否仍然遇到问题。
像 Rendering 'TypeError' with theme components after update 这样的主题，我认为不应该打上 fixed 的标签，因为 OP 中报告的错误没有得到修复。在这个例子中，尝试修复它的工程师没有重现问题。
还有 After deleting a topic, the delete button shows up instead of the restore button Deleting a topic cannot be undone 修复后，两者都可以被打上 fixed 的标签并关闭？但我们如何确保这种情况发生呢？
3 个赞
我的问题在于可用性。我希望工程师能在这里有一个一键式解决方案。
- 在“主题操作”或“管理员主题操作”中点击“已修复”。
- 魔法发生：
- 创建主题计时器，在 1 个工作日后关闭
- 主题标记为“已修复”
我不喜欢仅仅“标记主题”的用户体验，因为它摩擦成本很高。
- 导航到主题顶部
- 点击标题
- 点击标签框
- 搜索“已修复”
- 添加“已修复”
- 点击复选框
这摩擦成本太高了。
我很乐意我们添加这个流程，但我们需要一个主题组件来实现它，或者某种可以引入这种用户界面的自动化（这也可能很有用）。
4 个赞
我同意你的看法！当我提出上面的“是，而且”时，我也在考虑可用性。目前，我们已经习惯了在修复 Bug 主题后直接关闭它们。这同样也符合我们处理内部待办事项的方式。
我喜欢“一键修复”按钮的想法。
1 个赞
社区已经实现了 
6 个赞
太棒了！我在我的个人网站上试用了 Nate 的主题组件，它的功能正如其名。做得非常好，而且实现得很快！
要在这里使用它，我们需要能够将其限制在某个类别。如果我们认为这种方法效果很好，我们还希望能够创建多个按钮。
供参考，Sam 也在使用自动化进行一项不同的、更灵活的实验性实现。
2 个赞
我认为这个更改对我们在元（meta）上会有很大帮助。我已经跟进内部，看看是否可以使用 Sam 的实验性自动化实现或通过分叉 Nate 的主题组件并在元（meta）上使用它来实现。
Nate 的组件实际上做了同样的事情，而且相当不错，但我们必须分叉它，因为我们不在元（meta）上安装第三方组件或插件。 
1 个赞
如果你这样做，应该做出的光荣之举是向 Nate 提供经济上的感谢——就像你通过 HackerOne 感谢已识别的网络安全风险一样。
2 个赞
让我们将此主题集中在社区是否会从使用类似 Nate 的主题组件中受益。如果会，我们将与 Nate 一起解决具体机制。
如果您愿意，我很乐意另开一个主题，讨论开源贡献者如何获得对其工作的奖励。
2 个赞