بصفتي مشرفًا، أواجه أحيانًا منشورات أعتبرها إشكالية، ولكن لا أرغب في اتخاذ إجراء بشأنها بنفسي، نظرًا لوجود تاريخ سابق من الصراع الشخصي مع الشخص المعني. عادةً، أود فقط الإبلاغ عن المنشور في هذه الحالة، ولكن هذا يخفيه تلقائيًا، مما يبطل الغرض من ذلك.
باستثناء إرسال رسالة إلى زملائي المشرفين يدويًا، هل هناك أي شيء مناسب لهذا الموقف؟
لا أعتقد ذلك. أود أن أقول إن أسهل طريقة للتعامل مع هذا هي استخدام الهمسات (whispers) للإشارة بهدوء إلى المشرفين الآخرين.
إحدى الطرق التي يمكنني التفكير بها هي انتحال شخصية مستخدم اختبار TL0/TL1 للإبلاغ عن المنشور. على الرغم من أن هذا قد يكون طويلاً بعض الشيء.
أتساءل عما إذا كان بإمكانك بعد ذلك استخدام مكون سمة (theme component) لإضافة زر في نافذة الإبلاغ للانتقال إلى صفحة مسؤول المستخدم التجريبي لانتحال شخصيته، باستخدام شيء مثل Custom Components -- add button or text at any plugin outlet.
لا أعتقد أن جميع أنواع الإبلاغات تخفي المشاركات على الفور. أعتقد أنه يمكنك استخدام “شيء آخر” بأمان، أو يمكنك إنشاء إبلاغ مخصص.
إذا كنت تعتقد أنه “إشكالي”، فقم بوضع علامة عليه بنوع العلامة المناسب ودع مشرفًا آخر يحكم بنفسه، ثم اختر إظهاره إذا كانوا لا يوافقون. هذا هو سير العمل الصحيح لطابور المراجعة والإشراف على Discourse بشكل عام. عندما تقول “تاريخ سابق من الصراع الشخصي مع الشخص المعني”، أفترض أنك تعني أن حكمك كمشرف قد يتأثر، وبالتالي يجب أن تتصرف كما سيفعل المستخدم العادي وأن تضع علامة عليه وفقًا لذلك. كما ذكرت، البديل الآخر للاستخدام هو الرسائل الخاصة التي يمكن للموظفين الآخرين رؤيتها، أو بما أنك قلت إن هذا يحدث “أحيانًا” ببساطة:
لقد كنت أحاول هنا وهناك إنشاء كود Theme component للتحقق من العلم مقابل كل من العضو الذي تم الإبلاغ عنه والعضو الذي أبلغ عن المنشور ضد المشرف. إذا كان المشرف هو مالك المنشور الذي تم الإبلاغ عنه أو المستخدم الذي أبلغ عن المنشور. سيؤدي ذلك إلى إخفاء أزرار المراجعة باستثناء قول تأجيل.
لقد حاولت استخدام الذكاء الاصطناعي ولكني أشك في أن التغييرات الأخيرة في قائمة مراجعة العلم قد تسبب بعض المشاكل
سيكون هذا مفيدًا أيضًا مع مشرفي الفئات لضمان النزاهة في إجراءات الإشراف برأيي. كما حدث في الماضي أن مشرفًا قام بالإبلاغ عن منشورات عضو كان لديه خلاف معه ثم وافق على علمه الخاص. بينما قد يقول البعض اختر مشرفيك بشكل أفضل. إن وجود طريقة بسيطة لمنع الإغراء هو الأفضل
قد لا يكون مكون الثيم (TC) آمنًا للغاية، واقترح كود AU أنه يمكن للمكون إنشاء سجل إذا قام شخص ما بالتحايل. ربما في وقت لاحق سأشارك عينة كود في منشور للمطورين.
لا أفهم تمامًا كيف تساعد محاولاتك لإنشاء مكون يخفي شيئًا ما في قائمة مراجعة في منع إخفاء المنشور بسبب علامة من مشرف. غالبًا ما يكون للعلامات من قبل المستخدمين ذوي مستويات الثقة العالية قوة أكبر مما هو مقصود. @Steradiant ليس الأول الذي يرغب في علامة لا تخفي المنشور Trigger Moderator Attention Instead of Auto-hiding Flag
إذًا ربما لم أشرح الأمر بشكل كافٍ لتفهم الغرض
الفكرة بسيطة جدًا إذا كان المشرف الذي يراجع قائمة المراجعة (Review Que) متورطًا بشكل مباشر في المحتوى الذي تم الإبلاغ عنه. عندئذٍ يكون الخيار الوحيد هو تأجيله لمشرف آخر غير متورط لمراجعة المحتوى الذي تم الإبلاغ عنه.
لذا
مشرف_المنشور (mlMod) = مؤلف المنشور الذي تم الإبلاغ عنه. لا يمكنه حل البلاغ لأنه مؤلف المحتوى الذي تم الإبلاغ عنه. ولضمان النزاهة، يحتاج مشرف آخر إلى مراجعته.
المشرف هو المستخدم الذي أبلغ عن المنشور. لا يمكنه حل البلاغ لأنه يعتبر تضاربًا أيضًا لأنه هو من أبلغ عن المنشور. لذا يحتاج مشرف آخر إلى مراجعة البلاغ وحله.
هذا يضمن نزاهة عملية الإشراف من خلال وجود ضمانات ضد الإشراف المتحيز. في حالتي، سيقوم زميل مشرف بالإبلاغ عن القرارات التي اتخذها ضد مستخدمين آخرين خلال اختلافات في الرأي لا علاقة لها بـ “الجدال مع مشرف” وحل هذه البلاغات.
بينما يمكننا تطبيق السياسات والاعتماد على اختيار الأشخاص المناسبين ليكونوا في الفريق. فإن الوقاية كإجراء وقائي هي الأفضل لإزالة الإغراءات. بالإضافة إلى ذلك، مع إضافة الإشراف حسب الفئة، يحمي هذا الإجراء الوقائي أيضًا نزاهة المشرفين المتطوعين.
هذه الفكرة البسيطة تساعد في حيادية الإشراف.