يا إلهي. لقد جعلت الأمر يبدو معقداً. 
ظاهرياً، تقوم بإضافة وسم fixed للأخطاء التي تم إصلاحها، ووسم completed لطلبات الميزات التي تم تنفيذها. [1]. وهو جزء من عملية إغلاق المواضيع (وإبقاء الأطراف المهتمة على اطلاع بالمعلومات ذات الصلة). تم تطبيقهما في البداية لإعطاء مؤشر بصري على أن “شيئاً جيداً قد حدث” مقارنةً برمز القفل الخاص بالموضوع المغلق. وعند تطبيق هذه الوسوم بشكل متسق، تحصل على موجة جميلة من اللون الأخضر عند التمرير لأسفل في قوائم مواضيع الفئات.
(وكان delivered وسم منفصلاً وشبيهاً به، لكنه لم يكن خاضعاً لسيطرة الفريق، لذا كان يمكن استخدامه في Marketplace)
بالنسبة لـ Solved، هناك العديد من الفئات النشطة وليس فقط الفئة العامة Support. تقريباً أي فئة حيث تكون الغالبية العظمى من المواضيع عبارة عن أسئلة يمكن الحصول على حل لها. #support، #installation، #dev، #data-reporting، Support > SSO
من الناحية المثالية، فإن أفضل ممارسة هي أن يحدد صاحب الموضوع الأصلي (OP) الحل، لكننا نعلم أن هذا لا يحدث أحياناً (لأسباب متنوعة)، لذا كنت غالباً أتصفح قوائم المواضيع وأقوم بتنظيف بعضها المتبقي بعد أسبوعين أو نحو ذلك (بمجرد اعتبارها “مهجورة”)
للمعلومة فقط، موضوع Customization > Theme component الخاص بذلك هو https://meta.discourse.org/t/reader-mode/307916، لذا فإن موضوع feedback الذي أشرت إليه لا ينبغي أن يكون في Customization > Theme component (لأنه ليس موضوعاً يتعلق بمكون سمة). من المرجح أن يكون في Contribute > Feature أو Contribute > UX لأنني أعتقد أن هذه هي الأماكن التي أصبحت تعيش فيها هذه المواضيع الآن مع وجود المزيد منها.
(أعتقد أنه كان في Contribute > Site feedback لأنه كان تجربة هنا على الموقع)
وحيث أن Contribute > UX يمثل مرحلة انتقالية بين الاثنين، يمكن استخدام أي منهما اعتماداً على “طابع” الموضوع المحدد ↩︎