Изменить систему для значка Bug Reporter?

On Meta, sometimes we report bugs, and they get responded to by staff, with PRs to fix the bug we reported.

However, if the staff member didn’t like the topic post, no badge is awarded, even though it has been acknowledged and fixed accordingly.

Perhaps a change in the SQL query? Like if a staff member replies AND the topic is closed AND a Github PR link is sent (e.g. find it from having ‘Pull requests · discourse/discourse · GitHub’ in the link that was sent by a staff member)?

1 лайк

I am not so familiar with the history here, but I believe the bug reporter badge is intended to be awarded when a bug report has been confirmed as a bug by the team. Doesn’t matter whether it’s been fixed yet or not.

It is true that the query only recognizes likes, not reactions. So when @lilly added :eyes: to one of your topics it did not grant the badge. Arguably, that’s as intended. If she had confirmed the bug then she could have come back to add the :heart: like. But if she had used :clap: or some other more enthusiastic endorsement of your bug report then that’s not entirely fair.

Could also be that the person who handled the bug report didn’t think it was badge worthy? If this happens to you again feel free to DM me and I will take a look.

1 лайк

I see, thanks for clarifying!
I will let you know if this happens again :slight_smile:.

1 лайк

I think this has changed after Changes to which reactions 👍 are counted as likes ❤. Every reaction that counts as a like also triggers the badge.

An example where Lilly reacted with :eyes: and I received the badge is:

image

2 лайка

I noticed that there is no like on Subcategory filter disappears on /none but the topic is already closed. Would you check if the report qualifies for a badge? I’d think so; otherwise, saying “Thanks for the detailed report” doesn’t make much sense.

Ruby hash syntax being displayed in emails sent to deleted users also didn’t receive a like.

I recently asked for likes on On some forums, NaN instead of a number on badge pages - #10 by Moin and Group search issue on admin panel - #8 by Moin too. In the second one, I also mentioned Reason in the email sent to moderators when a user is automatically silenced not always correct.

There are currently quite a few topics/users that unfortunately do not receive appreciation in the form of a badge.

1 лайк

Thanks so much, Moin! Well spotted. There does indeed seem to be a breakdown in our system to reward bug reporters.

I will spread the word internally to remind folks to add the heart to the OP when they are evaluating bugs.

Последние примеры:

1 лайк

Это заставляет меня задуматься: не стоит ли создать что-то вроде Missing images at Meta.discourse.org, чтобы отмечать эту (или, возможно, эту тему)?

Я думаю, что отслеживать это гораздо проще с помощью запроса в Data Explorer, который возвращает все темы, закрытые в определённый период времени, но по которым пользователь не получил бейдж (или все темы с меткой 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, то да.

Запрос проверяет наличие лайка и/или публикации со ссылкой на %github.com/discourse/% от любого участника @team.

Сделать что-то «больше» с помощью только SQL-запроса, боюсь, будет сложно.

1 лайк

Просто задумываюсь, не упускаю ли я что-то ещё. В целом было бы приятнее, если бы значок выдавался вскоре после создания отчёта, а не значительно позже. Дата получения значка относится не к триггеру (лайк или ответ с PR), а к моменту создания темы. Поскольку уведомления о значках показывают не сам полученный значок, а список, отсортированный по дате, новый значок бывает трудно найти, из-за чего сложно понять, за какой именно отчёт он был получен.

Конечно, эта проблема не нова, но чем меньше лайков получают темы, когда кто-то изучает баг, тем чаще это будет происходить.

Кроме того, лайк создаёт ощущение, что тему прочитали. Я знаю, что вы всегда говорите, будто команда читает всё, но иногда лайк помогает укрепить веру в то, что это действительно так. Темы без ответа или лайка иногда кажутся проигнорированными.

Отчёт, который периодически подчёркивает, какие темы не получили лайков, по моему мнению, мог бы лучше стимулировать получение лайков и напоминать всем об этом, чем изменение, согласно которому достаточно просто поделиться ссылкой. Это, вероятно, приведёт к ещё меньшему количеству лайков.

1 лайк