مرحباً ليندسي،
أتفهم وجهة نظرك، ولكن دعني أشرح لماذا أعتقد أن تعطيل هذه الميزة (أو أي ميزة أخرى) يمكن أن يكون مفيدًا على الأقل حتى يتم اختبارها لفترة كافية لمعرفة ما إذا كانت مستقرة ويتم الإبلاغ عن عدد قليل جدًا من المشكلات إن وجدت.
هذه الميزة لا تؤثر فقط على المستخدم الذي يكتب رسالته، على الرغم من أنه يمكنه بالفعل إصلاح أي مشكلة قبل نشر رسالته بافتراض أنه يجد حلاً لنشرها بشكل صحيح.
أعتقد أن بعض المستخدمين لا يلاحظون حتى أنهم في وضع النص الغني. لم ألاحظ ذلك عندما بدأت في كتابة تقرير الخطأ السابق الخاص بي هنا. لا أقول إنه غير ملحوظ، ولكن عندما لا تحتاج إلى الكثير من التنسيق، يمكن أن يبدو كأي نص. يمكن الخلط بين حرف النجمة (*) كنقطة تعداد في HTML المعروض على بعض الشاشات، لذلك يعمل المستخدمون على منشور طويل، ويدركون أن شيئًا ما قد تعطل، وينتقلون إلى Markdown وقد يجعلون الأمر أسوأ (كما لاحظت بالأمس وذكرت في Rich Text editor in topics breaks white-space characters in multiple ways).
ثم لا يريدون قضاء الكثير من الوقت في إصلاح منشورهم، لذا يرسلونه على أمل أن يكون مفهومًا.
ثم يعمل المشرفون والمساعدون بشكل أكبر لفهم السؤال، ويطلبون من المستخدمين إصلاح منشوراتهم، ويشرحون لهم أنه لا ينبغي عليهم استخدام وضع النص الغني عند مشاركة التعليمات البرمجية. هذا يعني الكثير من الاتصالات والوقت الإضافي بدلاً من المساعدة، بينما ننتظر كتل التعليمات البرمجية الثابتة. هذا مهم في منتدى حيث تحتوي معظم المشاركات على نوع من كتل التعليمات البرمجية أو إذا لم يكن الأمر كذلك، فيجب أن تحتوي عليها، ولكن المستخدمين لم يكونوا على دراية بـ Markdown (وهو ما فاجأني، ولكن هذه هي الحقيقة 
). لذلك يمكن أن يكون محرر النص الغني إضافة رائعة بالفعل، وهذا هو كيف نظرنا إليه في البداية على الرغم من أنني ما زلت أفضل Markdown، ولكن لماذا لا نسمح للمستخدمين الآخرين باختيار ما يحبونه. لذا نعم، أنا أتفق.
ولكن في بعض الحالات، يتعين على المشرفين أو المسؤولين تحديد ما إذا كانت الميزة تسبب مشاكل أكثر مما تحل، لذلك أعتقد أنه يجب أن يكونوا قادرين على تعطيلها مؤقتًا حتى تصبح الميزة مستقرة بما يكفي لتفعيلها مرة أخرى. لن يعرف المستخدمون الذين يأتون للمساعدة بالضرورة أي وضع محرر هو الأفضل لهم، عندما لا يعرفون عن الأخطاء.
الآن لن أفكر في محاولة تعطيل أزرار “غامق” أو “اقتباس” لأن هذه الأزرار تفعل القليل جدًا ومن السهل جدًا ملاحظة ما إذا كان هناك خطأ ما. لكنني أرى أنه كانت هناك تقارير متعددة حول محرر النص الغني. إنها ميزة رائعة محتملة، ولكنها يمكن أن تسبب الكثير من المشاكل أيضًا. واجه الأشخاص أيضًا مشاكل مع MarkDown، ولكن هذا لا بأس، فنحن نعرف بالفعل ويمكننا التعامل معها كما فعلنا من قبل.
في بعض الحالات، يحاول المشرفون المساعدة في التنسيق وليس فقط ربط دليل التنسيق، ولكن أيضًا إصلاح الرسالة لهم. يمكن أن يكون هذا مفيدًا خاصة عندما لا يكون لديهم وقت لإصلاح منشورهم الخاص كمستخدمين جدد أو عندما مر يوم واحد منذ إرسالهم للرسالة. إذا لم يكن وضع النص الغني مستقرًا، يمكنني أن أتخيل تعديل منشورهم وكسره بدلاً من المساعدة.
لذلك أنا أتفهم تمامًا نية السماح للمستخدمين بتحديد ما يريدون استخدامه لكتابة منشورهم، ولكن هناك جانب آخر لذلك. حقيقة أن المستخدمين قد لا يعرفون أي محرر يريدون أو ما هي المشاكل التي سيسببونها، وأنهم ببساطة يضعون المزيد من العمل على المشرفين ويحصلون أيضًا على تجربة سيئة في المنتدى كان يمكن حلها عن طريق تعطيل الميزة مؤقتًا.
قرأت عن الحل القائم على CSS. المشكلة هي أنه على الرغم من أننا نستخدم CSS للتخصيص، إلا أنني أعرف أيضًا أن CSS يمكن أن يسبب مشاكل أيضًا لذلك أحاول عدم استخدام CSS إلا عند الضرورة القصوى. بهذه الطريقة يمكنني تجنب ظهور الميزة مرة أخرى بعد ترقية Discourse أو عندما يضيف شخص ما CSS إضافيًا لشيء غير ذي صلة دون ملاحظة أنه يكسر تعطيل ميزة.
آمل أن أكون قد وصفت ذلك بوضوح كافٍ
تحديث:
عندما عدت بعد إشعار، أدركت أنني لم أكتب عن نفس الشيء بالضبط مثل OP، ولكنني أعتقد أن النقطة الرئيسية لا تزال كما هي: يمكنني أن أتخيل أن مسؤولي المنتدى يريدون تعطيل بعض الميزات إذا كانت تسبب الكثير من المشاكل. سواء كان MarkDown أو Rich Text أو القدرة على التبديل بينهما بعد بدء منشور أقل أهمية.