لا، لم يكن الأمر كذلك، وقد رأينا هذه النقطة تتكرر مرارًا وتكرارًا داخليًا وخارجيًا، وفي كل مكان في قاعدة الكود.
لم نصل إلى الفئات بعد، لم يتغير شيء هنا.
كان الناس يستخدمون TL0 بشكل ساحق ليعني «جميع المستخدمين المسجلين» لأننا لم نكن نملك طريقة أفضل لتمثيل هذا. على الأقل، مجموعة logged_in_users واضحة تمامًا فيما تتضمنه، ولا يوجد شيء يمنعك من مواصلة استخدام TL0/TL1 وما إلى ذلك. المجموعة الوحيدة التي يتم حذفها هي everyone.
نعم، بالتأكيد أنا أقوم بكل هذا من أجل «التغيير من أجل التغيير» من فضلك، فكّر لحظة في كلماتك، لسنا من العادة أن نفعل أشياء غير ضرورية تمامًا دون سبب هنا. هذا العمل مستمر منذ أشهر الآن وهو لا يغير اتجاهه.
في النهاية، فإن ذلك لا معنى له بالنسبة لي، لأن everyone جزء من مجموعة من المجموعات الآلية التي تمثل عتبات الوصول، والتي تشمل أيضًا:
trust_level_0
trust_leve_1
وغيرها.
فجميعها تمثل عتبات للوصول، بما في ذلك everyone.
مجموعة everyone تُعرف أيضًا باسم “trust_level_none”
إنها طريقة موجزة للتعبير عن الوصول العام.
أقدّر أنك لا تقترح إزالتها حاليًا لأغراض أذونات الفئات (: +1:)، لكنني شخصيًا أودّ رؤية التزام بالحفاظ على هذه المجموعة الآلية، لأنها على الأقل تجعل الأمور منطقية بالنسبة لي.
ولماذا لا نسمح باستخدامها في أماكن أخرى تمامًا كما تفعل مع أي مجموعة مستوى ثقة آلية؟
إلا في هذه الحالة، فكل مكان تحتاج فيه إلى التعبير عن شيء ما لامتلاك “وصول عام” ستحتاج إلى إضافة مجموعتين، مما يبدو تعقيدًا بلا طائل؟
لماذا تتعب نفسك بإضافة منطق “لإخفاء” everyone؟
ربما يكون نهج بديل آخر هو إعادة النظر في اسم “everyone” إذا كان هناك اسم أفضل، مع الحفاظ على معناه ووظيفته وتوفره عبر المنصة، ثم يكون الجميع (تأفف) سعداء؟
أعتقد أن التمييز هنا يكمن بين الاحتفاظ بطريقة مريحة لاختيار “الوصول العام”، وبين الاحتفاظ بمجموعة everyone الحالية. أوافق على أن الحاجة إلى اختيار مجموعتين كل مرة تريد فيها الوصول العام أمر أكثر إزعاجًا، ويمكننا تحسين ذلك من خلال الواجهة.
على سبيل المثال، يمكننا إضافة اختصار “عام” إلى منتقي المجموعات الذي يختار كلًا من anonymous_users وlogged_in_users في إجراء واحد. ثم ستظهر لك المجموعتان معًا مختارتين، ويمكنك إزالة أي منهما. يمنحك هذا الراحة التي تصفها، مع الحفاظ على صلاحيات أساسية واضحة. لن نعرض هذا الاختصار إلا حيث يُسمح بالمجموعتين معًا.
المشكلة مع الاحتفاظ بمجموعة everyone الحالية هي أنها لم تعني باستمرار “الوصول العام”. فهي تعنيه فيما يتعلق بظهور الفئات، ولكن لمعظم إعدادات الموقع المعتمدة على المجموعات، كانت تعني فعليًا “جميع المستخدمين المسجلين”. كما أن هناك سkins وإضافات تفسّرها بشكل مختلف، كما أظهرت المناقشة أعلاه.
لذلك، لا يمكننا ببساطة الاحتفاظ بها والقول إنها تشمل المستخدمين غير المسجلين في كل مكان دون منح وصول ربما لم يكن موجودًا من قبل. الاحتفاظ بسلوكها الحالي سيحافظ على عدم الاتساق، وإعادة تسميتها لن تحل هذه المشكلة أيضًا.
من الممكن إنشاء مجموعة عالمية معرّفة بشكل متسق، لكنها ستحتاج لا يزال إلى الترحيل والتدقيق الذي نقوم به حاليًا. كما ستحتاج إلى أن تكون ممنوعة في أي مكان لا يُدعم فيه الوصول غير المسجل، وإلا سنعود إلى حالة تعني فيها “everyone” “المستخدمين المسجلين فقط” في تلك الأماكن. هناك الكثير من الإعدادات التي اضطررت لإضافة anonymous_users كقيمة لـ disallowed_groups حيث لم تكن كذلك من قبل، وقبل أن يُسمح بـ everyone في تلك الإعدادات. على سبيل المثال:
أفضّل توفير هذه الراحة في الواجهة، باستخدام المجموعتين الصريحتين في الخلفية، حتى نحقق الاتساق في كل مكان للمشرفين والمطورين.
نعم، أتفق معك على أن عدم الاتساق في إعدادات الموقع هو جزء من المشكلة. لكن إصلاح ذلك لا يعني بالضرورة مواصلة استخدام مجموعة everyone الحالية في إعدادات الموقع.
لا أعتقد أن الحجة المطروحة في عام 2013 تخبرنا بالكثير سوى مدة وجود everyone في صلاحيات الفئات. لقد تغير الكثير في Discourse منذ عام 2013؛ على سبيل المثال، كانت العديد من إعدادات الموقع تعتمد على مستوى الثقة (trust level)، أما الآن فتعتمد على المجموعات. لا أحد يجادل في أن هذا منطقي في ذلك السياق، وصلاحيات الفئات لم تتأثر بهذا العمل (على الأقل، في الوقت الحالي). عمرها لا يثبت أنها تحمل معنى متسقًا في بقية أجزاء Discourse، أو أننا يجب أن نستمر في استخدامها إلى الأبد.
حتى لو اتفقنا على أن كل انحراف عن المعنى الأصلي كان خطأً، لا يزال علينا التعامل مع كيفية عمل هذه الإعدادات فعليًا على المواقع الموجودة. لا يمكننا تغيير تفسيرها بأمان ليشمل المستخدمين المجهولين فقط لأن ذلك سيكون أكثر توافقًا مع سلوك الفئات الأصلي. كما شرحت أعلاه، فإن الاحتفاظ بمجموعة عالمية ذات معنى متسق سيظل يتطلب تدقيقًا وهجرة لاستخدامات تلك الإعدادات. إنها تصميم بديل، لكنها لا تتجنب الجزء الصعب من هذا العمل.
بالنسبة لنقطة RFC، فإن وجود RFC مجتمعي قبل إجراء تغييرات كهذه سيكون بطيئًا ومكلفًا، على الرغم من أن الملاحظات مرحب بها، فهذا هو الغرض من نظام التغييرات القادم. لقد أدى هذا الموضوع بالفعل إلى عدة تحسينات من أمثلة Moin، وقد اعترفت بحالات القوالب/المكونات التي فاتتني في البداية وأصلحتها أيضًا.
أنا سعيد بمواصلة العمل على حل المشكلات المحددة المتعلقة بالتغيير، لكنني سأمضي قدمًا مع المجموعتين الصريحتين. يبدو أن جعل الوصول العام سهل الاختيار في واجهة المستخدم طريقة معقولة للتعامل مع النقرات الإضافية، لكنني لا أعتقد أنه من الضروري تنفيذه في هذه اللحظة بالذات.
من فضلك، فكّر لحظة في كلماتك، لسنا من العادة أن نفعل أشياء غير ضرورية تمامًا دون سبب هنا. هذا العمل مستمر منذ أشهر الآن وهو لا يغير اتجاهه.