أعلم أن هذا يحدث عندما يُعجب شخص ما من Discourse بموضوع الخطأ المنشور في قناة Contribute > Bug. هل تستخدمون خدمة ويب لهذا الغرض وتستمعون إلى الإعجاب الأول على منشور جديد، وتتأكدون فقط من عدم إعجابه عدة مرات من قبل شخص في CDCK؟
يسعدني معرفة المزيد عن تطبيقكم!
لدينا شارة مخصصة لذلك. 
(مزيد من المعلومات في Creating triggered custom badge queries و Enable Badge SQL)
هذا هو الكود الخاص بها:
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
(كملاحظة إضافية، لقد أنشأت أيضًا شارات مماثلة للعمل بناءً على رد فعل معين من مجموعة معينة أيضًا 
)
@JammyDodger هذا رائع! لم يكن لدي الوقت بعد للتعمق في استعلامات الشارات المخصصة، ولكن هذا قد يعطيني أخيرًا مدخلاً.
إذا كان من الممكن السؤال، كيف تتعامل مع تقديم الأخطاء داخليًا بخلاف الشارة؟ على الأقل في سياق Meta؟ هل تضيفها يدويًا إلى قائمة الأخطاء الخاصة بك في مكان ما؟ هل تستخدم إضافة لإرسالها إلى قائمة الأخطاء الخاصة بك مباشرة من الموضوع؟
أنا أيضًا مهتم باللوجستيات المتعلقة بالتعامل مع تقارير الأخطاء وطلبات الميزات في Discourse وكيف تربطها بأنظمتك الداخلية/التطويرية.
إنها ممتعة جداً. وهناك العديد من الأمثلة المتاحة إذا كنت بحاجة إلى أي إلهام أو نصائح.
تُعد فئة Contribute > Bug جزءاً كبيراً من قائمة المتابعة الخاصة بنا بالأخطاء. لتجنب التكرار، غالباً ما نتعامل مع المشكلة داخل موضوع “ميتا” نفسه (باستخدام الرسائل الخاصة whispers، والإشارات @mentions، والتعيينات assigns)، ولا ننقل أي مشاكل حقاً إلى منطقة الفريق إلا إذا احتاجت إلى نقاش إضافي كبير أو مدخلات من الآخرين. كما نتلقى تقارير الأخطاء عبر قنوات العملاء أيضاً، والتي غالباً ما تُحل “في الموضوع” ما لم تكن هناك تقارير متعددة أو تقرير عام موجود بالفعل (وعندها يُستخدم واحد منها عادةً كالمركز الرئيسي لتجنب تشتيت النقاش كثيراً، بينما يتم ربط التقارير الأخرى ارتباطاً متقاطعاً). بالنسبة للتقارير التي نكتشفها بأنفسنا، لدينا بعض الموضوعات الداخلية التي يمكننا استخدامها لتدوين ملاحظات حول الأمور الصغيرة استعداداً لشخص ما للدخول وحلها، وللمشكلات الأكبر، نطلق موضوعاً مخصصاً بالطريقة نفسها التي نستخدمها في فئة Contribute > Bug العامة.
بشكل عام، تكون سير العمل كالتالي: تصل التقارير ويحاول أحدنا إعادة إنتاج المشكلة والحصول على أي تفاصيل إضافية مطلوبة. بمجرد التأكيد، سنقوم بإرسال إشارة “الاستغاثة” عبر @mentions إلى المجموعة/الشخص المعني لتحديد الأولوية وتعيين المهمة. يأتي الإصلاح، ويُضاف في منشور لإغلاق الموضوع (مع تأخير مؤقت للموضوع فقط للتأكد من أن كل شيء يعمل كما هو متوقع ).
فئة Contribute > Feature تختلف قليلاً حيث غالباً ما يكون هناك المزيد للنقاش داخلياً. نحاول تقليل الرسائل الخاصة whispers في تلك الموضوعات العامة، ونحتفظ بها للملاحظات القصيرة ولفت الانتباه إلى تلك التي تجذب اهتماماً إضافياً (باستخدام إشارات @mentions مرة أخرى ). بهذه الطريقة لا نتشتت بين أماكن كثيرة جداً. يحب مديرو المنتجات المشاركة علناً أيضاً لاستكشاف حالات استخدام مختلفة واستكشاف الإمكانيات (وكذلك لإعلام الناس بما يدور في أذهانهم بشأن الموضوع، حيث نحب أن نكون شفافين حيثما أمكن ذلك ). إذا أصبح موضوع Contribute > Feature شيئاً نأخذه على محمل الجد، فسيتم إنشاء موضوع داخلي حيث يمكن للمطورين، ومصممي واجهة المستخدم، ومديري المنتجات، ومشرفي المجتمع الفضوليين، وغيرهم، الإضافة بأفكار ونماذج أولية حول كيفية إنجازها بأفضل طريقة (مرتبطة ارتباطاً متقاطعاً بموضوع “ميتا” لربطها ببعضها البعض).
الآن بعد أن كتبت ذلك، لست متأكداً مما إذا كان ذلك مفيداً… لكن أخبرني إذا كنت تريد معرفة أي شيء آخر.