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