أرى كيف أنه مشابه، ومع ذلك هناك قضايا في المناقشة الأخرى تتعلق بالقضية هنا:
باستثناء أنه عندما تكون مسؤولاً، ليس لديك طريقة لمعرفة أن رابطًا لمحادثة سرية لا يمكنك الوصول إليها عادةً هو في الواقع محظور. هذه حالة واحدة فقط (حدثت لنا بالأمس ودعتني لبدء هذا الموضوع) حيث يمكن أن يكون عدم الفصل بين المسؤول والمشارك مشكلة.
علاوة على ذلك، أرى أن فريق Discourse لديه عادة أن يكون جميعهم مسؤولين، مما يجعل قوة أفقية، ولا يساعد، كثقافة، على التمييز بين الاستخدام العادي والاستخدام المميز. ليست كل المجتمعات أفقية، في بعض الأحيان لا ينبغي الوثوق بالأشخاص التقنيين الذين لديهم امتيازات المسؤول بكل شيء في المنتدى، وهذا ليس حالة هامشية: لقد تم بناؤه في أنظمة الكمبيوتر منذ البداية أن root يمكنه رؤية وفعل كل شيء. بالتأكيد تأتي الامتيازات مع المسؤولية، ولكن في بعض الأحيان لا يكفي الإحسان خاصة عندما لا يمكن للمرء التمييز بين ما هو مقبول وما هو محظور.
على الرغم من أن حل “استخدام ملف تعريف متصفح آخر” للتعامل مع حساب عادي وحساب مسؤول ليس عمليًا جدًا، خاصة وأننا جميعًا اعتدنا على امتلاك الأدوات في متناول اليد. يمكن أن يكون تشغيل متصفح جديد في كل مرة تكون فيها ميزة المسؤول مطلوبة مزعجًا للغاية (لا يحب الجميع ولا يمكنهم تحمل تخصيص موارد خاملة على أجهزتهم). كما أنه لا يمنع حدوث موقف “العين المتطفلة” الخاص بـ BOFH.
تتغير الأوقات. هنا، لدينا مسؤول وصل عن طريق الخطأ إلى معلومات سرية أثرت على حياة أشخاص آخرين، ولم يكن من المفترض أن يصل إليها. هذا خرق للخصوصية. إنها مشكلة أمنية.
أتفهم التعقيد المحتمل، لكن القضية الأساسية لا تزال قائمة ويجب حلها بطريقة أو بأخرى. في رأيي، سيكون من المفيد إعادة النظر في السؤال الآن بعد أن نضجت قاعدة الكود، وتقييم ما إذا كان النهج المقترح سيكون قابلاً للتنفيذ.
نعم! وجود تحذيرات وحراس حول هذه الأنواع من المشكلات (التعدي) سيكون مفيدًا.
حول الإضافات الحالية:
- قد يكون discourse-anonymous-moderators مفيدًا، ولكن تغييرًا حديثًا يتعامل مع البريد الإلكتروني (Enabling e-mail normalization by default) قد يغير ذلك - الاعتماد على عدم وجود إعدادات افتراضية قد يكون مشكلة.
- discourse-staff-alias يقتصر فقط على النشر.
أفضل فصلًا نظيفًا حقًا بين المشارك والمسؤول باستخدام استعارة sudo الكلاسيكية والمعروفة، لجميع الأسباب المذكورة أعلاه.