كما هو موضح في المثال المذكور أدناه، سيكون له استخدام هناك:
3 إعجابات
لست متأكدًا مما إذا كانت هذه فكرة جيدة. في النهاية، لا يمكننا نحن كمستخدمين إصلاح الأخطاء. لا يمكن القيام بذلك إلا عن طريق تغيير كود Discourse، وهذا يتطلب مشاركة عضو في الفريق. إذا لم يكن ذلك ضروريًا، فمن المحتمل أن “Bug” ليست الفئة المناسبة.
أنا قلق من أن المستخدمين سيضعون الحلول البديلة كحل. ولكن بعد ذلك لن يتم إصلاح الخطأ. لذلك سيكون الأمر مربكًا أكثر من كونه مفيدًا. في مثالك، لم يتم حل المشكلة أيضًا، لأنه يوجد بالفعل تقرير خطأ. أعتقد أن دمج المواضيع هو الأفضل في هذه الحالة. بهذه الطريقة، سيتم إخطار جميع المستخدمين عند وجود إصلاح، بغض النظر عن الموضوع الذي تابعوه في الأصل. في بعض الأحيان يكون من المنطقي إغلاق موضوع مع الإشارة إلى موضوع آخر، ولكن بعد ذلك تُفقد الإعجابات التي دعمت الموضوع المغلق، وهو أمر محزن عندما يتم تحديد المستخدمين المتأثرين بالإعجابات.
3 إعجابات
في فئة #bug، نعمل فقط مع الوسم fixed بدلاً من ذلك. المنشور الذي يقول إن شيئًا ما مكرر لا يحل أي شيء حقًا، على الرغم من كونه مفيدًا، لذلك لا أعتقد أنه كان سيكون استخدامًا جيدًا هناك أيضًا.
الآن، لماذا نستخدم fixed في بعض الفئات، ومكون solved-plugin في فئات أخرى، أعتقد أن ذلك يرجع على الأرجح إلى ما قاله Moin بالفعل. الوسوم أكثر صرامة قليلاً في الاستخدام، لذلك يمكن للفريق فقط تحديد متى تم إصلاح شيء ما.
5 إعجابات
شكرًا على الاقتراح! من الجيد دائمًا التحقق من صحة طريقة إعداد الفئات، لذا أقدر تفكيرك في الأمر وبدء هذا الموضوع.
كما أشار موين وتشارلي، يعتمد فريقنا على #fixed وإغلاق المواضيع (الإجراءات المتاحة لنا فقط) للتواصل مع المجتمع بأن خطأ ما قد تم إصلاحه بالفعل! يبدو أن هذا يعمل بشكل جيد وهو وسيلة لنا للاحتفاظ بقائمة واضحة إلى حد ما من الأخطاء التي تحتاج إلى إصلاح.
صحيح أنه في فئة الأخطاء، لا يحصل الشخص الذي يمكنه تقديم حل على رصيد له بنفس الطريقة التي يحصل عليها في الفئات التي تم تمكين إضافة الحل فيها، وهذا أمر مؤسف. في فئة الأخطاء، يحصل الشخص الذي يبلغ عن الخطأ على شارة لذلك إذا أعجب بها عضو في فريق Discourse. لكن الآخرين الذين يساعدون على طول الطريق من خلال تقديم خطوات إعادة الإنتاج، والإشارة إلى التكرارات، واقتراح الحلول وما إلى ذلك لن يحصلوا على رصيد. شيء للتفكير فيه.
في هذه الحالة، كان من الجميل أن تكون قادرًا على منح موين الفضل في الإشارة إلى أن التقرير مكرر، ولكن الاحتفاظ بالموضوع يخلق أيضًا بعض الضوضاء الإضافية التي ستجعل تحليل جميع تقارير الأخطاء المفتوحة أكثر صعوبة قليلاً للفريق. لذا آمل ألا تمانع، ولكني قمت بتعيين مؤقت لحذفه.
إعجاب واحد (1)
@tobiaseigen، أليس هذا ما تُستخدم ميزة القفل من أجله؟ حذفه سيجعل بعض عناوين URI الخارجية التي تشير إليه تعود بالخطأ 404، وهذا ليس مثاليًا.
نحن لا نحتفظ بكل شيء! 
لا داعي للقلق كثيرًا بشأن 404.
نحن لا نمارس هذا باستمرار على الإطلاق لأنه عمل إضافي. أعتقد أن هناك فائدة في وضع علامة تلقائية مع “fixed” عند الإغلاق، ثم للحالات الشاذة التي لا نصلحها يمكننا التعديل بوسم خاص.
سيتطلب بعض الأتمتة الجديدة على الرغم من ذلك.
4 إعجابات
لقد واجهت عدة مرات أثناء البحث عن بعض المعلومات، رؤية رابط بدا مثيرًا للاهتمام، ولكنه أدى إلى خطأ 404 عند النقر عليه، وهو أمر كان مزعجًا للغاية.
في هذه الحالة، سأقوم بوضع علامة على المنشور، والذي سيتم تعديله/إزالته بواسطة مشرف.
لمنع حدوث ذلك، قبل حذف موضوع، يجب إلقاء نظرة على قسم الروابط في المنشور الأول:
ثم اتخاذ إجراء وقائي بإزالة تلك الإشارات إلى الروابط سيكون أفضل، ولكنه سيتطلب أيضًا المزيد من العمل.
إعجابَين (2)
اقترحت العكس لـ @tobiaseigen: عند إضافة علامة fixed، قم بالإغلاق التلقائي أيضًا؛ نفس الشيء بالنسبة لـ “تم الحل”.
ربما تكون الإجابة هي “نعم، و؟” هل يمكن للأتمتة إضافة الوسم fixed فورًا إذا تم إغلاقه وإغلاق الموضوع (أو جدولته للإغلاق) إذا كان يحتوي على الوسم #fixed؟ يمكننا فعل الشيء نفسه في UX باستخدام الوسمين fixed و completed.
هل هناك أي حالات يتم فيها إغلاق مواضيع Bug دون الرغبة في إضافة الوسم #fixed؟ أرى أن هناك الكثير من مواضيع الأخطاء التي تم إغلاقها ولكنها لا تحتوي على الوسم. سأقضي بعض الوقت اليوم في الاستكشاف.
أحد الأشياء التي أعجبتني في سلوك المكون الإضافي solved هو أنه عند تحديد حل، يتم جدولة الموضوع ليتم إغلاقه تلقائيًا بعد 30 يومًا من آخر رد. هذا مفيد لأنه مفاجئ ويسمح للناس بالمتابعة إذا كانوا لا يزالون يشعرون بالحاجة إلى القيام بذلك. كما أنه يوفر علينا العمل على الأرجح لأن الناس لن يقوموا بالإبلاغ عن الموضوع لطلب إعادة فتحه.
إعجاب واحد (1)
السبب في أنني لا أحب الإغلاق => إضافة الوسم تلقائيًا هو بسبب حالات الاستخدام التي لم يتم فيها الإصلاح أو أنه لن يتم إصلاحه أبدًا. أعتقد أن القيام بإجراء واحد (“إضافة وسم”) والذي يقوم بعد ذلك تلقائيًا بتعيين مؤقت الموضوع للإغلاق بعد 30 يومًا هو الطريقة المثلى.
إعجابَين (2)
لقد أمضيت بعض الوقت في هذا ورأيت أن لدى @chapoi الفكرة الصحيحة. أعتقد أن ما نريد القيام به هنا هو التعود على وضع علامة fixed على العناصر التي تم إصلاحها، ثم إنشاء أتمتة تقوم بتعيين مؤقت للإغلاق تلقائيًا، مثل المكون الإضافي solved. لا يزال بإمكاننا إغلاق الموضوع فورًا إذا كان ذلك مبررًا، ولكن في بعض الحالات أعتقد أنه من الجيد تركه مفتوحًا لفترة أطول لمنح الأشخاص فرصة للاختبار والإبلاغ عما إذا كانوا لا يزالون يواجهون مشكلة.
هناك مواضيع مثل Rendering 'TypeError' with theme components after update أعتقد أنه لا ينبغي وضع علامة fixed عليها، لأن الخطأ المبلغ عنه في OP لم يتم إصلاحه. في هذا المثال، لم يكن هناك إعادة إنتاج من المهندس الذي حاول إصلاحه.
هناك أيضًا After deleting a topic, the delete button shows up instead of the restore button الذي تم إغلاقه كنسخة مكررة. أعتقد أنه عندما يتم إصلاح Deleting a topic cannot be undone يمكن وضع علامة fixed وإغلاق كليهما؟ ولكن كيف نتأكد من حدوث ذلك؟
هناك الكثير من المواضيع في Bug مغلقة ولكن ليس لديها علامة fixed. سنرغب في مراجعة هذه المواضيع بأثر رجعي.
3 إعجابات
مشكلتي هنا هي سهولة الاستخدام. أريد أن يكون لدى المهندسين حل بنقرة واحدة هنا.
- انقر على “تم الإصلاح” في إجراءات الموضوع أو إجراءات الموضوع الإداري.
- يحدث السحر:
- يتم إنشاء مؤقت للموضوع للإغلاق في يوم عمل واحد
- يتم وضع علامة “تم الإصلاح” على الموضوع
أنا لست من محبي تجربة المستخدم لمجرد “وضع علامة على الموضوع” لأنها تتطلب جهدًا كبيرًا.
- انتقل إلى أعلى الموضوع
- انقر على العنوان
- انقر على مربع العلامات
- ابحث عن “تم الإصلاح”
- أضف “تم الإصلاح”
- انقر على مربع الاختيار
هذا يتطلب الكثير من الجهد.
يسعدني أن نضيف هذه العملية، ولكننا سنحتاج إلى مكون سمة لهذا أو نوع من الأتمتة التي تقدم هذه الواجهة (والتي يمكن أن تكون مفيدة أيضًا).
4 إعجابات
أنا معك! كنت أفكر أيضًا في سهولة الاستخدام عندما اقترحت “نعم، و” أعلاه. حاليًا، لدينا ذاكرة عضلية حول إغلاق مواضيع Bug ببساطة عند إصلاحها. وهذا يطابق أيضًا كيف نتعامل مع المهام المعلقة داخليًا.
أعجبني فكرة زر “تم الإصلاح” بنقرة واحدة.
إعجاب واحد (1)
وقد قدم المجتمع الحل :ضحك:
6 إعجابات
رائع! لقد جربت مكون سمة Nate على موقعي الشخصي، وهو يؤدي ما هو مذكور. عمل رائع جدًا وتم تنفيذه بسرعة أيضًا! 
لكي نتمكن من استخدامه هنا، سنحتاج إلى أن نكون قادرين على تقييده بفئة. إذا قررنا أن هذا النهج يعمل بشكل جيد، فسنرغب أيضًا في أن نكون قادرين على إنشاء أكثر من زر واحد.
للعلم، يعمل Sam أيضًا على تطبيق تجريبي مختلف وأكثر مرونة، باستخدام الأتمتة.
إعجابَين (2)
أعتقد أن هذا التغيير سيساعدنا كثيرًا هنا في ميتا. لقد تابعت داخليًا لمعرفة ما إذا كان يمكن تنفيذه إما باستخدام تطبيق سام التجريبي باستخدام الأتمتة أو عن طريق تشعيب مكون سمة نيت واستخدامه هنا.
يقوم مكون نيت بنفس الشيء بفعالية وهو لطيف جدًا، ولكن سيتعين علينا تشعيبه لأننا لا نقوم بتثبيت مكونات أو إضافات طرف ثالث على ميتا. 
إعجاب واحد (1)
إذا قمت بذلك، فسيكون الشيء المشرف الذي يجب القيام به هو تقديم رمز شكر مالي لـ Nate - كما تفعل للمخاطر الأمنية السيبرانية المحددة عبر HackerOne.
إعجابَين (2)
دعنا نركز هذا الموضوع على ما إذا كان المجتمع سيستفيد من استخدام شيء مثل مكون سمة نيت. إذا كان الأمر كذلك، فسنقوم بترتيب الآليات مع نيت.
يسعدني أن أفتح موضوعًا آخر حول كيفية مكافأة المساهمين مفتوحي المصدر على عملهم بشكل عام إذا كنت ترغب في ذلك.
إعجابَين (2)