Meta 是如何处理 bug reporter badge 的？

数据与报告
1

我知道当 Discourse 的某人点赞了在 Bug 频道中发布的 bug 主题时，就会发生这种情况。你们是使用网络服务来监听新帖子的第一个点赞，并确保它不是被 CDCK 的某人多次点赞吗？

我很想了解更多关于你们的实现方式！

4 个赞
2

我们为此有一个自定义徽章。:+1: (更多信息请参阅 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

(另外，我还创建了类似的徽章，可以根据特定群组的特定反应来工作 :slight_smile:)

5 个赞
3

@JammyDodger 这太棒了！我还没有时间深入研究自定义徽章查询，但这可能终于给了我一个切入点。

如果可以问的话，除了徽章之外，你们内部是如何处理 Bug 提交的？至少在 Meta 的背景下？你们是手动将其添加到某个 Bug 队列中吗？还是使用插件直接从主题发送到 Bug 队列？

我也对在 Discourse 中处理 Bug 报告和功能请求的后勤工作以及如何将其与你们的开发/内部系统联系起来感到好奇。

5 个赞
4

它们很有趣。 :slight_smile: 如果你需要任何灵感或技巧，有很多例子可以参考。 :+1:

Bug 类别是我们 bug 队列的重要组成部分。 :slight_smile: 为避免重复，我们通常在 Meta 主题本身内处理问题（使用私信、@提及和分配），只有在需要大量额外讨论或他人输入时，我们才会将其分离到 Team 区域。我们还通过客户渠道收到 bug 报告，这些报告通常也在“主题内”解决，除非有多个报告或已存在公开报告（在这种情况下，通常会使用其中一个作为主要报告，以免过度分散对话，其他报告会交叉链接）。对于我们自己发现的问题，我们有几个内部主题可以用来记录一些小问题，以便有人可以介入解决，对于较大的问题，我们以与公开的 Bug 类别相同的方式创建一个专门的主题。

一般来说，流程是：收到报告，我们中的一个人会尝试重现它并获取任何额外的必要细节。确认后，我们会向相关组/人员发出 @提及信号，让他们确定优先级并分配。修复完成后，会发布一个帖子来关闭该主题（带有主题计时器延迟，以便我们可以先确认一切正常 :slight_smile:）。

Feature 则有些不同，因为内部通常需要更多的讨论。我们尽量在这些公开主题中尽量少用私信，只用于简短的笔记和引起对那些获得额外关注的主题的注意（再次是可信赖的 @提及 :slight_smile:）。这样我们就不会将对话分散到太多的地方。产品经理也喜欢公开参与这些讨论，以探索不同的用例并了解可能性（同时也让我们能够尽可能透明地告知人们我们的想法 :slight_smile:）。如果一个 Feature 成为我们认真考虑的对象，它将获得一个内部主题，开发人员、设计师、产品经理、好奇的社区版主等都可以就他们认为如何最好地实现它提出想法和模型（并与 Meta 主题交叉链接以将它们连接起来）。

现在我写完了，我不确定这是否有帮助……但如果你想知道其他任何事情，请告诉我。 :slight_smile:

4 个赞