我知道，当有人从 Discourse 给 Contribute > Bug 中发布的 bug 主题点赞时就会发生这种情况。你们是用网络服务来实现的吗？只是监听新帖子的第一个点赞，并检查确保 CDCK 的某人没有多次点赞？
很想了解更多关于你们实现方式的细节！
我们为此有一个自定义徽章。
(更多信息请参阅 Creating triggered custom badge queries 和 Enable Badge SQL)
这是代码：
SELECT distinct p.user_id, p.created_at granted_at, p.id post_id
FROM badge_posts p
JOIN topics t ON t.id = p.topic_id
JOIN post_actions pa ON pa.post_id = p.id AND
post_action_type_id = (
SELECT id FROM post_action_types WHERE name_key = 'like'
) AND
pa.user_id IN (
SELECT gu.user_id
FROM group_users gu
WHERE gu.group_id = ( SELECT id FROM groups WHERE name ilike 'team' )
)
WHERE category_id = (
SELECT id FROM categories WHERE name ilike 'bug'
) AND p.post_number = 1
(另外，我还创建了类似的徽章，可以根据特定群组的特定反应来工作 
)
@JammyDodger 这太棒了！我还没有时间深入研究自定义徽章查询，但这可能终于给了我一个切入点。
如果可以问的话，除了徽章之外，你们内部是如何处理 Bug 提交的？至少在 Meta 的背景下？你们是手动将其添加到某个 Bug 队列中吗？还是使用插件直接从主题发送到 Bug 队列？
我也对在 Discourse 中处理 Bug 报告和功能请求的后勤工作以及如何将其与你们的开发/内部系统联系起来感到好奇。
它们非常有趣。 如果你需要灵感或建议，有很多现成的例子可以参考。
Contribute > Bug 类别是我们错误队列的重要组成部分。 为了避免重复，我们经常直接在 Meta 帖子中处理问题（使用私信、@提及和指派），只有当问题需要额外的深入讨论或他人输入时，才会将其拆分到团队区域。我们也通过客户渠道接收错误报告，这些报告通常也在帖子内解决，除非存在多个报告或已有公开报告（在这种情况下，通常会选择一个作为主帖，以避免对话过于分散，其他报告则进行交叉链接）。对于我们自己发现的问题，我们有一些内部帖子，可以用来记录较小的问题，以便有人随时介入解决；对于较大的问题，我们会像 Contribute > Bug 类别那样创建专门的帖子。
通常的流程是：收到报告后，我们会尝试复现并收集所需的其他详细信息。确认后，我们会发出 @提及 信号，通知相关团队/人员，以确定优先级并指派任务。修复完成后，我们会发布一条帖子来关闭该帖子（设置帖子计时器延迟，以便我们首先确认一切正常运行 ）。
Contribute > Feature 则略有不同，因为内部通常需要更多的讨论。我们尽量在这些公开帖子中减少私信的使用，仅将其用于简短备注或引起对那些受到额外关注的帖子的注意（再次使用 @提及 ）。这样我们可以避免对话分散到太多地方。产品经理也喜欢公开参与这些讨论，以探索不同的用例并试探可能性（同时也为了让人们了解我们的想法，因为我们尽可能保持透明 ）。如果某个 Contribute > Feature 成为我们认真考虑的功能，我们会创建一个内部帖子，让开发人员、设计师、产品经理、好奇的社区管理员等都可以参与进来，提出想法和原型，讨论如何最好地实现它（与 Meta 帖子交叉链接，以便将各方连接起来）。
现在我已经写完了，不确定这是否有帮助……但如果你想知道其他任何内容，请告诉我。