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)?
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 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 like. But if she had used 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.
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.
Я думаю, что отслеживать это гораздо проще с помощью запроса в Data Explorer, который возвращает все темы, закрытые в определённый период времени, но по которым пользователь не получил бейдж (или все темы с меткой fixed, но без выданного бейджа; это исключило бы проблемы, закрытые из-за невозможности воспроизведения, но не сработает, если метка не добавлена). Затем скрипт автоматизации мог бы отправлять эту информацию в почтовый ящик темы или группы.
Проверка вручную — задача непростая. Недостаточно просто посмотреть реакции на пост; нужно проверить, когда были поставлены лайки, и состояли ли пользователи в группе @team в момент лайка. Или же нужно проверить бейджи авторов.
И кто вообще смотрит на первый пост только потому, что там появился новый ответ о том, что баг исправлен, кроме участника команды, который добавляет метку fixed?
Только что изменил запрос (бронзовый) 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"
Просто задумываюсь, не упускаю ли я что-то ещё. В целом было бы приятнее, если бы значок выдавался вскоре после создания отчёта, а не значительно позже. Дата получения значка относится не к триггеру (лайк или ответ с PR), а к моменту создания темы. Поскольку уведомления о значках показывают не сам полученный значок, а список, отсортированный по дате, новый значок бывает трудно найти, из-за чего сложно понять, за какой именно отчёт он был получен.
Конечно, эта проблема не нова, но чем меньше лайков получают темы, когда кто-то изучает баг, тем чаще это будет происходить.
Кроме того, лайк создаёт ощущение, что тему прочитали. Я знаю, что вы всегда говорите, будто команда читает всё, но иногда лайк помогает укрепить веру в то, что это действительно так. Темы без ответа или лайка иногда кажутся проигнорированными.
Отчёт, который периодически подчёркивает, какие темы не получили лайков, по моему мнению, мог бы лучше стимулировать получение лайков и напоминать всем об этом, чем изменение, согласно которому достаточно просто поделиться ссылкой. Это, вероятно, приведёт к ещё меньшему количеству лайков.