Sur Meta, il arrive que nous signalions des bugs, et qu’ils soient traités par le personnel, avec des PRs pour corriger le bug que nous avons signalé.
Cependant, si le membre du personnel n’a pas aimé le sujet du post, aucun badge n’est attribué, même s’il a été reconnu et corrigé en conséquence.
Peut-être un changement dans la requête SQL ? Comme si un membre du personnel répond ET que le sujet est fermé ET qu’un lien PR Github est envoyé (par exemple, le trouver en ayant ‘Pull requests · discourse/discourse · GitHub’ dans le lien qui a été envoyé par un membre du personnel) ?
Je ne connais pas très bien l’historique ici, mais je crois que le badge « Rapporteur de bug » est destiné à être décerné lorsqu’un rapport de bug a été confirmé comme un bug par l’équipe. Peu importe s’il a déjà été corrigé ou non.
Il est vrai que la requête ne reconnaît que les « J’aime », pas les réactions. Donc, lorsque @lilly a ajouté à l’un de vos sujets, cela n’a pas accordé le badge. On pourrait dire que c’est comme prévu. Si elle avait confirmé le bug, elle aurait pu revenir pour ajouter le « J’aime » . Mais si elle avait utilisé ou une autre approbation plus enthousiaste de votre rapport de bug, ce ne serait pas tout à fait juste.
Il se pourrait aussi que la personne qui a traité le rapport de bug n’ait pas pensé qu’il méritait un badge ? Si cela vous arrive à nouveau, n’hésitez pas à m’envoyer un message privé et je jetterai un coup d’œil.
J’ai remarqué qu’il n’y a pas de like sur Subcategory filter disappears on /none - #2 by sam mais que le sujet est déjà fermé. Pourriez-vous vérifier si le rapport est éligible à un badge ? Je le pense ; sinon, dire « Merci pour ce rapport détaillé » n’a pas beaucoup de sens.
Cela me fait me demander, ne devrait-il pas y avoir quelque chose comme Missing images at Meta.discourse.org pour cocher ceci (ou peut-être ce sujet) ?
Je pense que c’est quelque chose de beaucoup plus facile à suivre avec une requête d’explorateur de données qui renvoie tous les sujets fermés dans un laps de temps spécifique mais où l’utilisateur n’a pas reçu de badge (ou tous les sujets qui sont étiquetés fixed, mais aucun badge n’a été attribué ; cela exclurait les problèmes qui ont été fermés parce que personne ne pouvait les reproduire, mais échoue si l’étiquette n’est pas ajoutée). Ensuite, un script d’automatisation pourrait le signaler à une boîte de réception de sujet ou de groupe.
Vérifier cela manuellement n’est pas si facile. Vous ne pouvez pas simplement vérifier les réactions sur la publication ; vous devez vérifier quand les “j’aime” ont eu lieu et si les utilisateurs faisaient partie du groupe @team lorsqu’ils ont aimé. Ou, vous devez vérifier les badges des auteurs.
Et qui consulte la première publication juste parce qu’il y a une nouvelle réponse indiquant que le bogue a été corrigé, à part le membre de l’équipe qui ajoute l’étiquette fixed ?
Je viens de modifier la requête Bug Reporter (bronze) de
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
à celle-ci
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)
)
)
et les requêtes argent et or de
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"
Donc, lorsqu’un membre de l’équipe signale que quelque chose a été corrigé il y a 3 semaines avec un lien vers la Pull Request (PR), les utilisateurs reçoivent-ils un badge ?
Je me demande juste si je peux penser à autre chose. Dans l’ensemble, il serait plus agréable de recevoir le badge peu de temps après avoir créé les rapports, et pas beaucoup plus tard. La date à laquelle vous recevez le badge ne fait pas référence au déclencheur (comme ou réponse avec PR), mais à la date à laquelle vous avez créé le sujet. Et comme les notifications de badge ne vous montrent pas le badge réel que vous avez reçu, mais plutôt une liste triée par date, le nouveau badge peut être difficile à trouver, ce qui rend difficile de savoir pour quel rapport vous avez réellement obtenu le badge pour l’instant.
Bien sûr, ce problème n’est pas entièrement nouveau, mais moins il y a de “j’aime” donnés lorsqu’on examine un bug, plus cela se produira souvent.
De plus, un “j’aime” donne le sentiment qu’un sujet a été lu. Je sais que vous dites toujours que l’équipe lit tout, mais parfois un “j’aime” peut aider à soutenir le sentiment que cela se produit réellement. Les sujets sans réponse ou sans “j’aime” donnent parfois l’impression d’être négligés.
Un rapport qui met en évidence périodiquement les sujets qui n’ont pas reçu de “j’aime” pourrait, à mon avis, mieux encourager à donner des “j’aime” et rappeler à tout le monde de le faire que le changement selon lequel le partage d’un lien est également suffisant. Cela entraînera probablement encore moins de “j’aime”.
à l’un de vos sujets, cela n’a pas accordé le badge. On pourrait dire que c’est comme prévu. Si elle avait confirmé le bug, elle aurait pu revenir pour ajouter le « J’aime » 
. Mais si elle avait utilisé 
ou une autre approbation plus enthousiaste de votre rapport de bug, ce ne serait pas tout à fait juste.
.