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:
Subcategory filter disappears on /none 에는 좋아요가 없는데, 해당 토론은 이미 닫혀 있습니다. 이 보고가 배지 수여 조건에 해당하는지 확인해 주시겠습니까? 당연히 해당한다고 생각합니다. 그렇지 않다면 "상세한 보고에 감사드립니다
정말 감사합니다, Moin! 잘 짚어주셨네요. 실제로 버그 보고자에게 보상을 주는 시스템에 문제가 있는 것 같습니다.
버그를 평가할 때 원포스트(OP)에 하트를 추가하도록 팀원들에게 내부적으로 공지하겠습니다.
최근 사례:
이로 인해, 이 (또는 아마도 이 주제)를 체크할 수 있도록 https://meta.discourse.org/t/missing-images-at-meta-discourse-org/302963과 같은 것이 있어야 하지 않을까 궁금해집니다.
특정 시간대에 닫힌 모든 토픽을 반환하되, 사용자가 배지를 받지 못했거나(또는 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 (
-- 팀원이 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
-- 팀원이 해당 토픽에 github.com/discourse 링크를 게시함
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 (
-- 팀원이 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
-- 팀원이 해당 토픽에 github.com/discourse 링크를 게시함
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 -- 또는 "gold"의 경우 25
그렇다면, 팀 멤버가 3주 전에 수정되었다며 PR 링크를 공유할 때, 사용자들은 배지를 받을 수 있을까요?
그 누군가가 @team 멤버라면, 네.
해당 쿼리는 @team 멤버 중 아무거나에서 %github.com/discourse/% 링크가 포함된 좋아요와/또는 게시물을 확인합니다.
그보다 “더” 하는 것은 SQL 쿼리만으로는 어렵습니다.
다른 점이 더 있을지 궁금합니다. 전체적으로 보고서를 생성한 직후에 배지를 받는 것이 훨씬 나을 것 같고, 너무 늦게 받는 것은 피하는 것이 좋습니다. 배지를 받는 날짜는 트리거(좋아요 또는 PR로 답변)를 가리키는 것이 아니라, 주제를 생성한 시점을 가리킵니다. 그리고 배지 알림에는 실제로 받은 배지가 표시되지 않고 날짜순으로 정렬된 목록만 표시되므로, 새 배지를 찾기가 어려워져 결국 어떤 보고서에 대해 배지를 받았는지 파악하기가 힘들어집니다.
물론 이 문제는 완전히 새로운 것이 아닙니다. 하지만 누군가가 버그를 볼 때 좋아요가 적게 주어질수록 이 문제가 더 자주 발생하게 됩니다.
또한, 좋아요는 해당 주제가 읽혔다는 느낌을 줍니다. 팀이 모든 것을 읽는다고 항상 말씀하시지만, 때로는 좋아요가 실제로 그렇게 되고 있다는 느낌을 뒷받침하는 데 도움이 될 수 있습니다. 답변이나 좋아요가 없는 주제는 때때로 무시당하는 것처럼 느껴집니다.
제 생각에, 좋아요를 받지 못한 주제들을 주기적으로 강조하는 보고서는 링크 공유만으로도 충분하다는 변경 사항보다 좋아요를 더 잘 부여하도록 장려하고 모두에게 이를 상기시키는 데 더 효과적일 것입니다. 이 변경 사항은 오히려 좋아요가 더 적게 주어지는 결과를 초래할 가능성이 큽니다.