لست متأكدًا تمامًا من مصدر هذا الرقم 1٪، ولكن مع 14 مليون مستخدم، لا يزال هذا يعني حظر 14000 مستخدم من Discourse. فقط لإضافة بعض تعديلات CSS والأداء؟
بالنسبة لـ “ما هو عدد المستخدمين الذين يجب أن يكونوا قادرين على منع النسبة المتبقية من الاستفادة من برامجهم المحدثة؟” … لماذا لا يمكن أن يكون هذا الرقم أقل بكثير من 1٪، أقرب إلى 0٪ منه إلى 1٪؟ أجادل بأن Discourse يجب أن يتبع نهجًا معاكسًا، وليس إجراء تغييرات غير متوافقة مع الإصدارات السابقة دون داعٍ إلا إذا كان هناك إصلاح حرج قاهر أو ميزة رئيسية تتطلب ذلك بشكل مطلق، وهناك طلب واسع النطاق من المستخدمين عليه.
العكس من هذا السؤال هو “كم عدد المستخدمين الذين نحن على استعداد لقطعهم لمطاردة بعض وسائل الراحة البسيطة ذات التأثير المنخفض أو المعدوم على واجهة المستخدم؟” هل زيادة أداء صغيرة بالكاد يمكن ملاحظتها على أي شيء سوى الاختبارات المعيارية الدقيقة تستحق قطع 14000 شخص من مجتمعاتهم؟
ما نوع “البرامج المحدثة” التي يطالب بها مستخدمو المنتدى …؟ إنه منتدى. يقرأ الناس النصوص ويردون على المنشورات النصية. من المخيف أن المطورين يواصلون القول “علينا أن نستمر في التقدم” بينما عملاؤكم الفعليون يقولون، انتظروا، لماذا، لا تعني أي من هذه الميزات شيئًا وأنتم تقطعون أشخاصًا حقيقيين.
أشعر أن هذا هو النهج المعاكس تمامًا لما تتوقعه من برنامج منتدى مستقر وقديم مثل Discourse. إذا كنت ترغب في تجربة ميزات جديدة، فيجب أن يحدث ذلك على فرع تجريبي غير مستقر يجب على الأشخاص الاشتراك فيه صراحةً، ويجب أن يكون الفرع الرئيسي LTS افتراضيًا. لا تقدم فقط تحسينات تقدمية، بل لا تقدم أيضًا تدهورًا لطيفًا. هذا اختيار، وليس جزءًا لا يتجزأ من تطوير البرمجيات. أنت تختار التحرك أسرع مما يمكن لمستخدميك مواكبته.
ومجتمعاتك المستضافة ليس لديها خيار على الإطلاق. أولئك الذين يدفعون لك مقابل مجتمعهم، وليس ليكونوا عرضًا تقنيًا وملعبًا لـ JavaScript.
هذا هو سبب كونها مشكلة ثقافية وليست مشكلة تقنية. شكراً لك على استعدادك لقول ذلك بصوت عالٍ. لقد قمت بتقييم تكاليف هذا بالساعات التطويرية مقابل التأثيرات المقدرة للمستخدمين، وفي حساباتك، المستخدمون لا يستحقون التكلفة التي ستستغرقها لإنشاء إصدار نشر أساسي. لا توجد طريقة أخرى لقول ذلك: أنت لا تقدر المستخدمين والمجتمعات الحقيقية بقدر اختصارات المطورين 
آسف لأخذ هذا الاقتباس خارج السياق قليلاً، ولكن … إذا توقفت عن التفكير من حيث النسب المئوية وفكرت في التأثيرات على الأفراد الحقيقيين في مجتمعاتهم، فربما تبدو الحسابات مختلفة؟
كل هذا الأمر يشبه إلى حد ما الحقبة الستالينية، حيث تخبر الناس أنهم في الأساس إحصائية يمكن التخلص منها لأنهم فقراء جدًا لترقية الأجهزة أو أن الخطأ خطأهم لعدم رغبتهم والقدرة على القفز عبر الحلقات لتثبيت نظام تشغيل آخر أو طبقة توافق أو متصفح شوكي … فقط حتى يتمكنوا من الاستمرار في نشر رسائل نصية على منتدى كانوا جزءًا منه لسنوات عديدة؟
هذا هو نوع التكلفة والفائدة الذي أتوقع رؤيته من إصدار جديد رئيسي، مثل إعادة كتابة كاملة، وليس من بعض الميزات الثانوية غير المرئية التي يواجهها المطور والتي قد يكون لها فوائد أداء صغيرة = / من المؤسف حقًا أن شركتك تتخذ هذا الموقف، في رأيي، ولكن لا يزال … أنا أقدر الشفافية حقًا.
حسنًا. على أي حال، يكفي التذمر. لدي سؤال بناء محتمل / على الأرجح …
إذا افترضنا أن وضع HTML أساسي سيكون مفيدًا لعدد صغير من المستخدمين، ولكنه ليس شيئًا يريد Discourse إنفاق الموارد عليه بنفسه … هل هذا شيء ممكن للمجتمع مفتوح المصدر للقيام به؟ يبدو أنه كبير جدًا ليكون شيئًا مثل المكون الإضافي، بينما لا يزال صغيرًا جدًا لمشروع منفصل بالكامل (مثل Discorkie).
هل سيكون من الممكن محاولة تحديد نطاق هذا كواجهة أمامية مفتوحة بديلة تعمل مع واجهات برمجة التطبيقات الحالية، وإذا كان الأمر كذلك، فهل ستكون هناك فرصة للحصول على مثل هذا الشيء (إذا تم بناؤه واختباره على الإطلاق) ليتم قبوله / دمجه “رسميًا” في البرنامج الرئيسي بحيث يمكن استخدامه أيضًا على مثيلات Discourse المستضافة (وهو المكان الذي يوجد فيه أحد مجتمعاتي المتأثرة)؟
على طول هذه الخطوط، هل لديك أي نوع من نظام إصدار / استقرار لواجهات برمجة التطبيقات يمكن لواجهة أمامية بديلة تتبعها؟
ربما الإجابة لا تزال مجموعة متنوعة من “لا” لأسباب مختلفة، وإذا كان الأمر كذلك، فلا بأس، ولكن إذا كان الأمر ممكنًا على الإطلاق … قد يكون من المثير للاهتمام التفكير فيه؟ لا أطلب دراسة جدوى على نطاق واسع، ربما مجرد بعض المشاعر؟
لست متأكدًا مما إذا كان مثل هذا الشيء يمكن أن ينجح أو تتم صيانته. لا يحب العديد من المطورين العمل على البرامج القديمة باستخدام HTML والحد الأدنى من JavaScript (ولكن لا يزال هناك البعض، مثل HTMX ،) مجرد فكرة.