في ميتا، نقوم أحيانًا بالإبلاغ عن الأخطاء، ويستجيب لها الموظفون، مع تقديم طلبات سحب لإصلاح الخطأ الذي أبلغنا عنه.
ومع ذلك، إذا لم يعجب الموظف بمنشور الموضوع، فلن يتم منح أي شارة، على الرغم من الاعتراف به وإصلاحه وفقًا لذلك.
ربما تغيير في استعلام SQL؟ مثل إذا رد موظف وتم إغلاق الموضوع وتم إرسال رابط طلب سحب على GitHub (على سبيل المثال، العثور عليه من خلال وجود ‘Pull requests · discourse/discourse · GitHub’ في الرابط الذي أرسله موظف)؟
لستُ على دراية كبيرة بالتاريخ هنا، لكنني أعتقد أن شارة مُبلّغ الأخطاء مُخصصة للمنح عندما يتم تأكيد تقرير خطأ كخطأ من قبل الفريق. لا يهم ما إذا كان قد تم إصلاحه بعد أم لا.
صحيح أن الاستعلام يتعرف فقط على الإعجابات، وليس ردود الفعل. لذلك عندما أضاف @lilly إلى أحد مواضيعك، لم يتم منح الشارة. يمكن القول إن هذا هو المقصود. لو كانت قد أكدت الخطأ، لكانت قد عادت لإضافة إعجاب . ولكن إذا كانت قد استخدمت أو أي تأييد آخر أكثر حماسًا لتقرير الخطأ الخاص بك، فهذا ليس عادلاً تمامًا.
قد يكون أيضًا أن الشخص الذي تعامل مع تقرير الخطأ لم يعتقد أنه يستحق الشارة؟ إذا حدث هذا لك مرة أخرى، فلا تتردد في مراسلتي وسألقي نظرة.
لاحظت أنه لا يوجد إعجاب على Subcategory filter disappears on /none - #2 by sam ولكن الموضوع مغلق بالفعل. هل يمكنك التحقق مما إذا كان التقرير مؤهلاً للشارة؟ أعتقد ذلك؛ وإلا، فإن قول “شكرًا على التقرير المفصل” لا معنى له.
أعتقد أن هذا شيء يسهل تتبعه باستخدام استعلام مستكشف البيانات الذي يُرجع جميع المواضيع المغلقة في إطار زمني محدد ولكن لم يحصل فيها المستخدم على شارة (أو جميع المواضيع التي تحمل وسم #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)، بل إلى وقت إنشاء الموضوع. وبما أن إشعارات الشارات لا تعرض لك الشارة الفعلية التي تلقيتها، بل قائمة مرتبة حسب التاريخ، فقد يكون من الصعب العثور على الشارة الجديدة، مما يجعل من الصعب معرفة التقرير الذي حصلت على الشارة بسببه بالفعل الآن.
بالطبع، هذه المشكلة ليست جديدة تمامًا، ولكن كلما قل عدد الإعجابات التي تُمنح عندما ينظر شخص ما إلى خطأ، زاد تكرار حدوث ذلك.
أيضًا، الإعجاب يجعلك تشعر بأن الموضوع قد تمت قراءته. أعلم أنك تقول دائمًا إن الفريق يقرأ كل شيء، ولكن في بعض الأحيان يمكن أن يساعد الإعجاب في دعم الشعور بأن هذا يحدث بالفعل. المواضيع التي لا تحتوي على رد أو إعجاب تبدو أحيانًا مهملة.
أعتقد أن تقريرًا يسلط الضوء بشكل دوري على المواضيع التي لم تحصل على إعجابات يمكن أن يشجع بشكل أفضل على منح الإعجابات ويذكر الجميع بالقيام بذلك أكثر من التغيير الذي يكفي فيه مشاركة الرابط. من المحتمل أن يؤدي هذا إلى عدد أقل من الإعجابات.