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 see, thanks for clarifying!
I will let you know if this happens again 
.
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 
and I received the badge is:
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.
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.
Recent examples:
This makes me wonder, should there be something like Missing images at Meta.discourse.org to tick off this (or maybe this topic)?
I think this is something that is much easier to track with a data explorer query that returns all topics closed in a specific time frame but where the user didn’t receive a badge (or all topics that are fixed, but no badge was granted; that would exclude issues that were closed because no one could repro, but fails if the tag isn’t added). Then, an automation script could report that to a topic or group inbox.
Checking that manually is not that easy. You cannot just check the reactions on the post; you need to check when the likes happened and if the users were in the @team group when they liked it. Or, you need to check the authors’ badges.
And who looks at the first post just because there is a new reply that says the bug was fixed, apart from the team member who adds the fixed tag?
Just changed the (bronze) Bug Reporter query from
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
to this
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)
)
)
and the silver and gold queries from
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"
to
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"
So, when a team member shares that something was fixed 3 weeks ago with a link to the PR, do the users get a badge?
If that someone is a @team member, then yes.
The query checks for a like and/or a post with a link to %github.com/discourse/% from any @team member.
Doing “more” than that will be hard to do with just an SQL query I’m afraid.
I’m just wondering if I can think of anything else. Overall, it would be nicer if you received the badge shortly after creating the reports, and not much later. The date when you receive the badge does not refer to the trigger (like or reply with PR), but to when you created the topic. And since badge notifications don’t show you the actual badge you’ve received, but rather a list sorted by date, the new badge can be difficult to find, which makes it hard to find out for which report you actually got the badge for now.
Of course, this problem isn’t entirely new, but the fewer likes are given when someone looks at a bug, the more often this will occur.
Also, a like makes you feel that a topic was read. I know you always say the team reads everything, but sometimes a like can help to support the feeling that this really happens. Topics without a reply or like sometimes feel overlooked.
A report that periodically highlights which topics have not received likes could, in my opinion, better encourage the giving of likes and remind everyone to do so than the change that sharing a link is also sufficient. This will probably lead to even fewer likes.