更改用于Bug Reporter徽章的系统?

在 Meta,有时我们会报告错误,然后由工作人员进行回复,并提供 PR 来修复我们报告的错误。

但是,如果工作人员不喜欢该主题帖子,即使它已被确认并相应修复,也不会授予徽章。

也许可以更改 SQL 查询?例如,如果工作人员回复了 AND 主题已关闭 AND 发送了 Github PR 链接(例如,通过查找工作人员发送的链接中包含“github.com/discourse/discourse/pull”来查找)?

1 个赞

我对这里的历史不太熟悉,但我认为“bug 报告者”徽章应该在 bug 报告被团队确认为 bug 时颁发。是否已修复并不重要。

确实,查询只识别点赞,而不识别反应。因此,当 @lilly 在你的一个主题中添加 :eyes: 时,它并没有授予徽章。可以说,这是符合预期的。如果她确认了 bug,她可以回来添加 :heart: 点赞。但如果她使用了 :clap: 或其他更积极的对你的 bug 报告的认可,那就不完全公平了。

也可能是处理 bug 报告的人认为它不值得获得徽章?如果这种情况再次发生,请随时给我发私信,我会查看。

1 个赞

好的,谢谢您的澄清!
如果再次发生这种情况,我会通知您 :slight_smile:

1 个赞

我认为这在 Changes to which reactions 👍 are counted as likes ❤ 之后已经改变了。所有被计为点赞的反应也会触发徽章。

一个莉莉用 :eyes: 反应而我获得了徽章的例子是:

image

2 个赞

我注意到 Subcategory filter disappears on /none - #2 by sam 上没有点赞,但该主题已经关闭。您能否检查一下该报告是否符合徽章的资格?我认为符合;否则,“感谢您提供详细的报告”就没有多大意义了。

Ruby hash syntax being displayed in emails sent to deleted users 也未收到点赞。

我最近还在 On some forums, NaN instead of a number on badge pages - #10 by MoinGroup search issue on admin panel - #8 by Moin 上请求点赞。在第二个链接中,我还提到了 Reason in the email sent to moderators when a user is automatically silenced not always correct

目前有相当多的主题/用户不幸未获得徽章形式的赞赏。

1 个赞

非常感谢你,Moin!你发现得真及时。我们的奖励报告 bug 系统的确似乎出现了故障。

我会在内部传达,提醒大家在评估 bug 时给 OP 点赞。

最近的例子:

1 个赞

这让我好奇,是否应该有一个类似 Missing images at Meta.discourse.org 的东西来勾选这个(或者也许是这个主题)?

我认为使用数据浏览器查询来跟踪在特定时间范围内关闭的所有主题,但用户未获得徽章(或者所有被标记为 fixed 但未授予徽章的主题;这将排除因无人能重现而关闭的问题,但如果未添加标签则会失败)会更容易。然后,自动化脚本可以将该信息报告给主题或群组收件箱。

手动检查这一点并不那么容易。您不能只检查帖子上的反应;您需要检查点赞发生的时间以及用户在点赞时是否在 @team 群组中。或者,您需要检查作者的徽章。

除了添加 fixed 标签的团队成员之外,谁还会仅仅因为有新的回复说错误已修复而查看第一篇帖子呢?

3 个赞

刚刚将(青铜)Bug Reporter 查询从

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

更改为

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
WHERE t.category_id = 1 -- bug
AND p.post_number = 1
AND (
    -- team member liked the OP
    EXISTS (
        SELECT 1 
        FROM post_actions pa
        WHERE pa.post_id = p.id
        AND pa.post_action_type_id = 2 -- like
        AND pa.user_id IN (SELECT gu.user_id FROM group_users gu WHERE gu.group_id = 47)
    )
    OR
    -- team member posted a github.com/discourse link in the topic
    EXISTS (
        SELECT 1 
        FROM topic_links tl
        WHERE tl.topic_id = t.id
        AND tl.url LIKE '%github.com/discourse/%'
        AND NOT tl.reflection
        AND tl.user_id IN (SELECT gu.user_id FROM group_users gu WHERE gu.group_id = 47)
    )
)

并将银牌和金牌查询从

SELECT p.user_id
     , min(p.created_at) granted_at
  FROM posts p
  JOIN topics t ON t.id = p.topic_id
 WHERE t.category_id = (SELECT id FROM categories WHERE name ILIKE 'bug')
   AND p.post_number = 1
   AND EXISTS (
         SELECT 1
           FROM post_actions pa
          WHERE pa.post_id = p.id 
            AND pa.post_action_type_id = (SELECT id FROM post_action_types WHERE name_key = 'like') 
            AND pa.user_id IN (SELECT user_id FROM group_users WHERE group_id = (SELECT id FROM groups WHERE name ILIKE 'team'))
       )
 GROUP BY p.user_id
HAVING COUNT(*) >= 10 -- OR 25 for "gold"

更改为

SELECT p.user_id, MIN(p.created_at) granted_at
FROM badge_posts p
JOIN topics t ON t.id = p.topic_id
WHERE t.category_id = 1 -- bug
 AND p.post_number = 1
 AND (
     -- team member liked the OP
     EXISTS (
         SELECT 1
           FROM post_actions pa
          WHERE pa.post_id = p.id
            AND pa.post_action_type_id = 2 -- like
            AND pa.user_id IN (SELECT gu.user_id FROM group_users gu WHERE gu.group_id = 47)
     )
     OR
     -- team member posted a github.com/discourse link in the topic
     EXISTS (
         SELECT 1
           FROM topic_links tl
          WHERE tl.topic_id = t.id
            AND tl.url LIKE '%github.com/discourse/%'
            AND NOT tl.reflection
            AND tl.user_id IN (SELECT gu.user_id FROM group_users gu WHERE gu.group_id = 47)
     )
 )
GROUP BY p.user_id
HAVING COUNT(*) >= 10 -- or 25 for "gold"
1 个赞

那么,当团队成员分享说某项内容已在 3 周前修复,并附上拉取请求(PR)链接时,用户会获得徽章吗?

如果该用户是 @team 成员,那么是的。

该查询会检查来自任何 @team 成员的包含指向 %github.com/discourse/% 的链接的点赞和/或帖子。

恐怕仅使用 SQL 查询很难做到“更多”了。

1 个赞

我只是想知道我是否还能想到其他什么。总的来说,如果你在创建报告后不久而不是很久之后收到徽章会更好。收到徽章的日期并不指触发条件(如点赞或回复 PR),而是指你创建主题的日期。由于徽章通知不会向你显示收到的实际徽章,而是按日期排序的列表,因此新徽章可能很难找到,这使得现在很难弄清楚你究竟是为哪个报告获得了徽章。
当然,这个问题并非全新,但当有人查看错误报告时获得的赞数越少,这种情况就越常发生。

此外,一个赞会让你感觉主题已被阅读。我知道你们总是说团队会阅读所有内容,但有时一个赞可以帮助巩固这种感觉确实发生过。没有回复或赞的主题有时会让人感觉被忽视了。

在我看来,一个定期突出显示哪些主题尚未获得点赞的报告,比将分享链接也视为足够的方式更能鼓励大家点赞并提醒所有人这样做。这可能会导致点赞数更少。

1 个赞