Su Meta, a volte segnaliamo bug, e questi vengono gestiti dallo staff, con PR per correggere il bug che abbiamo segnalato.
Tuttavia, se allo staff non piace il post dell’argomento, non viene assegnato alcun badge, anche se è stato riconosciuto e corretto di conseguenza.
Forse una modifica alla query SQL? Come se un membro dello staff rispondesse E l’argomento fosse chiuso E venisse inviato un link a una PR di Github (ad esempio, trovarlo avendo ‘Pull requests · discourse/discourse · GitHub’ nel link inviato da un membro dello staff)?
Non ho molta familiarità con la storia qui, ma credo che il badge “segnalatore di bug” sia destinato ad essere assegnato quando un bug report è stato confermato come bug dal team. Non importa se è stato corretto o meno.
È vero che la query riconosce solo i “mi piace”, non le reazioni. Quindi, quando @lilly ha aggiunto a uno dei tuoi argomenti, non ti ha concesso il badge. Probabilmente, è come previsto. Se avesse confermato il bug, avrebbe potuto tornare ad aggiungere il “mi piace” . Ma se avesse usato o qualche altro tipo di approvazione più entusiasta del tuo bug report, allora non sarebbe del tutto corretto.
Potrebbe anche essere che la persona che ha gestito il bug report non pensasse che fosse degno di un badge? Se ti ricapita, sentiti libero di inviarmi un messaggio privato e darò un’occhiata.
Ho notato che non c’è un like su Subcategory filter disappears on /none - #2 by sam ma l’argomento è già chiuso. Potresti verificare se il report è idoneo per un badge? Lo riterrei tale; altrimenti, dire “Grazie per il report dettagliato” non avrebbe molto senso.
Penso che questo sia qualcosa di molto più facile da tracciare con una query dell’esploratore di dati che restituisca tutti gli argomenti chiusi in un intervallo di tempo specifico ma in cui l’utente non ha ricevuto un badge (o tutti gli argomenti che sono fixed, ma non è stato concesso alcun badge; questo escluderebbe i problemi chiusi perché nessuno è riuscito a riprodurli, ma fallisce se il tag non viene aggiunto). Quindi, uno script di automazione potrebbe segnalarlo a una casella di posta di argomenti o di gruppo.
Controllare manualmente non è così facile. Non puoi semplicemente controllare le reazioni al post; devi controllare quando sono avvenuti i “mi piace” e se gli utenti erano nel gruppo @team quando hanno messo “mi piace”. Oppure, devi controllare i badge degli autori.
E chi guarda il primo post solo perché c’è una nuova risposta che dice che il bug è stato risolto, a parte il membro del team che aggiunge il tag fixed?
Ho appena modificato la query Bug Reporter (bronzo) da
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
a questa
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)
)
)
e le query argento e oro da
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"
a
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"
Mi chiedo solo se riesco a pensare a qualcos’altro. Nel complesso, sarebbe più bello se si ricevesse il badge poco dopo aver creato i report, e non molto più tardi. La data in cui si riceve il badge non si riferisce al trigger (come o risposta con PR), ma a quando si è creato l’argomento. E poiché le notifiche dei badge non mostrano il badge effettivo ricevuto, ma piuttosto un elenco ordinato per data, il nuovo badge può essere difficile da trovare, il che rende difficile capire per quale report si è effettivamente ottenuto il badge in quel momento.
Naturalmente, questo problema non è del tutto nuovo, ma meno “mi piace” vengono dati quando qualcuno guarda un bug, più spesso si verificherà.
Inoltre, un “mi piace” fa sentire che un argomento è stato letto. So che dite sempre che il team legge tutto, ma a volte un “mi piace” può aiutare a sostenere la sensazione che ciò accada davvero. Gli argomenti senza risposta o “mi piace” a volte sembrano trascurati.
Un report che evidenzia periodicamente quali argomenti non hanno ricevuto “mi piace” potrebbe, a mio avviso, incoraggiare meglio a dare “mi piace” e ricordare a tutti di farlo, rispetto alla modifica per cui anche la condivisione di un link è sufficiente. Questo probabilmente porterà a ancora meno “mi piace”.