메타(Meta)에서는 버그를 보고하면 스태프가 응답하고, 우리가 보고한 버그를 수정하기 위한 PR이 올라오기도 합니다.
하지만 스태프가 해당 토픽 게시물을 마음에 들어하지 않는 경우, 버그가 확인되고 실제로 수정되었음에도 불구하고 배지가 부여되지 않습니다.
SQL 쿼리를 변경하는 것은 어떨까요? 예를 들어, 스태프가 답변을 남기고 AND 토픽이 닫히고 AND GitHub PR 링크가 전송된 경우(예: 스태프가 보낸 링크에 'github.com/discourse/discourse/pull’이 포함되어 있는지 확인)와 같이 말입니다.
여기서 말하는 역사적인 배경에 대해 그렇게 잘 알고 있지는 않지만, 버그 리포터 배지는 버그 리포트가 팀에 의해 실제로 버그로 확인되었을 때 수여되는 것이라고 생각합니다. 아직 수정되었든 아니든 상관없습니다.
쿼리가 좋아요(Likes)만 인식하고 리액션은 인식하지 않는다는 말씀은 맞습니다. 그래서 @lilly님이 토픽 중 하나에 
를 추가했을 때 배지가 부여되지 않았습니다. 이는 의도된 동작이라고 볼 수도 있습니다. 만약 그녀가 버그를 확인했다면, 나중에 돌아와서 
좋아요를 추가할 수 있었을 것입니다. 하지만 
나 다른 더 열정적인 지지 표현을 사용했다면, 그것은 다소 불공평할 수 있습니다.
버그 리포트를 처리한 사람이 배지를 받을 가치가 없다고 판단했을 수도 있습니다. 만약 이런 상황이 다시 발생한다면, 편하게 DM으로 연락해 주세요. 제가 확인해 보겠습니다.
아, 그렇군요! 설명해 주셔서 감사합니다!
다시 이런 일이 생기면 알려드릴게요 
.
Changes to which reactions 👍 are counted as likes ❤ 이후로 이 부분이 변경되었다고 생각합니다. 좋아요로 계산되는 모든 리액션은 배지도 함께 트리거합니다.
Lilly 님이 로 리액션했고 제가 배지를 받은 예시는 다음과 같습니다:
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로 답변)를 가리키는 것이 아니라, 주제를 생성한 시점을 가리킵니다. 그리고 배지 알림에는 실제로 받은 배지가 표시되지 않고 날짜순으로 정렬된 목록만 표시되므로, 새 배지를 찾기가 어려워져 결국 어떤 보고서에 대해 배지를 받았는지 파악하기가 힘들어집니다.
물론 이 문제는 완전히 새로운 것이 아닙니다. 하지만 누군가가 버그를 볼 때 좋아요가 적게 주어질수록 이 문제가 더 자주 발생하게 됩니다.
또한, 좋아요는 해당 주제가 읽혔다는 느낌을 줍니다. 팀이 모든 것을 읽는다고 항상 말씀하시지만, 때로는 좋아요가 실제로 그렇게 되고 있다는 느낌을 뒷받침하는 데 도움이 될 수 있습니다. 답변이나 좋아요가 없는 주제는 때때로 무시당하는 것처럼 느껴집니다.
제 생각에, 좋아요를 받지 못한 주제들을 주기적으로 강조하는 보고서는 링크 공유만으로도 충분하다는 변경 사항보다 좋아요를 더 잘 부여하도록 장려하고 모두에게 이를 상기시키는 데 더 효과적일 것입니다. 이 변경 사항은 오히려 좋아요가 더 적게 주어지는 결과를 초래할 가능성이 큽니다.