В Meta иногда мы сообщаем об ошибках, и сотрудники реагируют на них, предоставляя PR для исправления сообщённой нами ошибки.
Однако, если сотрудник не одобрил тему, значок не присваивается, даже если ошибка была признана и исправлена.
Возможно, стоит изменить SQL-запрос? Например, если сотрудник отвечает, тема закрывается и в сообщении содержится ссылка на PR на GitHub (например, найти ссылку, содержащую ‘Pull requests · discourse/discourse · GitHub’, отправленную сотрудником)?
Я не очень хорошо знаком с историей этого вопроса, но, насколько я понимаю, значок «докладчик об ошибках» должен присваиваться, когда команда подтверждает, что сообщение об ошибке действительно содержит баг. Неважно, исправлен ли он уже или нет.
Действительно, запрос учитывает только лайки, а не реакции. Поэтому, когда @lilly добавила к одной из ваших тем реакцию , значок не был выдан. Можно сказать, что это работает как задумано. Если бы она подтвердила наличие бага, то могла бы позже добавить лайк . Но если бы она использовала или какую-то другую более эмоциональную поддержку вашего сообщения об ошибке, то это было бы не совсем справедливо.
Также возможно, что человек, занимавшийся вашим сообщением об ошибке, не счёл его достойным значка? Если с вами такое случится снова, не стесняйтесь написать мне в личные сообщения, и я разберусь.
Я заметил, что на Subcategory filter disappears on /none нет лайка, хотя тема уже закрыта. Не могли бы вы проверить, соответствует ли этот отчёт требованиям для получения значка? Мне кажется, что да; в противном случае фраза «Спасибо за подробный отчёт» не имеет особого смысла.
Я думаю, что отслеживать это гораздо проще с помощью запроса в Data Explorer, который возвращает все темы, закрытые в определённый период времени, но по которым пользователь не получил бейдж (или все темы с меткой 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"
Просто задумываюсь, не упускаю ли я что-то ещё. В целом было бы приятнее, если бы значок выдавался вскоре после создания отчёта, а не значительно позже. Дата получения значка относится не к триггеру (лайк или ответ с PR), а к моменту создания темы. Поскольку уведомления о значках показывают не сам полученный значок, а список, отсортированный по дате, новый значок бывает трудно найти, из-за чего сложно понять, за какой именно отчёт он был получен.
Конечно, эта проблема не нова, но чем меньше лайков получают темы, когда кто-то изучает баг, тем чаще это будет происходить.
Кроме того, лайк создаёт ощущение, что тему прочитали. Я знаю, что вы всегда говорите, будто команда читает всё, но иногда лайк помогает укрепить веру в то, что это действительно так. Темы без ответа или лайка иногда кажутся проигнорированными.
Отчёт, который периодически подчёркивает, какие темы не получили лайков, по моему мнению, мог бы лучше стимулировать получение лайков и напоминать всем об этом, чем изменение, согласно которому достаточно просто поделиться ссылкой. Это, вероятно, приведёт к ещё меньшему количеству лайков.