Metaでは、バグを報告すると、スタッフから返信があり、報告したバグを修正するためのPRが提供されることがあります。
しかし、スタッフがトピック投稿を気に入らなかった場合、認識され、それに応じて修正されたとしても、バッジは付与されません。
SQLクエリの変更が必要かもしれません。例えば、スタッフが返信し、トピックがクローズされ、GithubのPRリンクが送信された場合（例えば、スタッフが送信したリンクに「github.com/discourse/discourse/pull」が含まれているかを探す）などです。
この履歴についてはあまり詳しくありませんが、バグ報告バッジは、バグ報告がチームによってバグとして確認された場合に付与されるものだと認識しています。修正されたかどうかは関係ありません。
確かに、クエリは「いいね」のみを認識し、リアクションは認識しません。そのため、@lilly があなたのトピックの 1 つに 
を追加しても、バッジは付与されませんでした。それは意図された通りと言えるでしょう。もし彼女がバグを確認していれば、戻ってきて 
のような「いいね」を追加できたはずです。しかし、もし彼女があなたのバグ報告に対して 
やその他のより熱狂的な支持を使用したとしたら、それは必ずしも公平ではありません。
バグ報告を担当した人が、バッジに値しないと考えた可能性もあります。もしこれが再び起こった場合は、DM を送ってください。確認します。
承知いたしました。また発生するようでしたらお知らせします 
.
これは Changes to which reactions 👍 are counted as likes ❤ の後に変更されたと思います。いいねとしてカウントされるすべてのリアクションは、バッジもトリガーします。
リリーが でリアクションし、私がバッジを受け取った例は次のとおりです。
Subcategory filter disappears on /none - #2 by sam には「いいね」がありませんが、トピックはすでに閉じられています。この報告はバッジの対象となるか確認していただけますか？そうでなければ、「詳細な報告ありがとうございます」というコメントはあまり意味をなさないと思います。
Ruby hash syntax being displayed in emails sent to deleted users も「いいね」がありませんでした。
最近、On some forums, NaN instead of a number on badge pages - #10 by Moin と Group search issue on admin panel - #8 by Moin でも「いいね」をお願いしました。2つ目のトピックでは、Reason in the email sent to moderators when a user is automatically silenced not always correct にも言及しました。
現在、残念ながらバッジという形での評価を受けていないトピックやユーザーがかなりあります。
モインさん、本当にありがとうございます！よく見つけましたね。バグ報告者への報酬システムに確かに不具合があるようです。
バグを評価する際に、OPにハートを追加するように皆に周知します。
最近の例：
これにより、Missing images at Meta.discourse.org のようなものを作成して、これを（あるいはたぶんこのトピックを）チェックすべきではないかと思いました。
データエクスプローラーのクエリを使用して、特定の期間内にクローズされたすべてのトピックを返しますが、ユーザーがバッジを受け取っていないもの（または #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"
チームメンバーが3週間前に修正されたと共有し、PRへのリンクを提供した場合、ユーザーはバッジを受け取りますか？
もしその誰かが@teamのメンバーであれば、その通りです。
このクエリは、%github.com/discourse/%へのリンクを含む「いいね」や投稿を、@teamメンバーの誰かから探します。
残念ながら、それ以上のことをSQLクエリだけで行うのは難しいでしょう。
他に何か思いつくことはないかと思っています。全体的に、レポート作成後すぐにバッジを受け取れた方が、それよりもずっと後になるよりも良いでしょう。バッジを受け取る日付は、トリガー（いいねやPRでの返信など）ではなく、トピックを作成した日付を参照します。また、バッジの通知では実際に受け取ったバッジではなく日付順にソートされたリストが表示されるため、新しいバッジを見つけるのが難しくなり、どのレポートで実際にバッジを獲得したのかを把握するのが困難になります。
もちろん、この問題は全く新しいものではありませんが、誰かがバグを見たときに与えられる「いいね」の数が少なければ少ないほど、この問題は頻繁に発生するでしょう。
また、「いいね」はトピックが読まれたという感覚を与えてくれます。チームがすべてを読んでいるといつもおっしゃっていることは承知していますが、時には「いいね」が、それが本当に起こっているという感覚をサポートするのに役立ちます。返信や「いいね」がないトピックは、見過ごされているように感じられることがあります。
定期的に「いいね」がついていないトピックを強調表示するレポートは、リンクの共有も十分であるという変更よりも、「いいね」を促し、皆にそうするように思い出させるのに役立つと私は思います。これはおそらく、「いいね」がさらに少なくなることにつながるでしょう。