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