بصفتي مشرفًا، أواجه أحيانًا منشورات أعتبرها إشكالية، ولكن لا أرغب في اتخاذ إجراء بشأنها بنفسي، نظرًا لوجود تاريخ سابق من الصراع الشخصي مع الشخص المعني. عادةً، أود فقط الإبلاغ عن المنشور في هذه الحالة، ولكن هذا يخفيه تلقائيًا، مما يبطل الغرض من ذلك.
باستثناء إرسال رسالة إلى زملائي المشرفين يدويًا، هل هناك أي شيء مناسب لهذا الموقف؟
إذا كنت تعتقد أنه “إشكالي”، فقم بوضع علامة عليه بنوع العلامة المناسب ودع مشرفًا آخر يحكم بنفسه، ثم اختر إظهاره إذا كانوا لا يوافقون. هذا هو سير العمل الصحيح لطابور المراجعة والإشراف على Discourse بشكل عام. عندما تقول “تاريخ سابق من الصراع الشخصي مع الشخص المعني”، أفترض أنك تعني أن حكمك كمشرف قد يتأثر، وبالتالي يجب أن تتصرف كما سيفعل المستخدم العادي وأن تضع علامة عليه وفقًا لذلك. كما ذكرت، البديل الآخر للاستخدام هو الرسائل الخاصة التي يمكن للموظفين الآخرين رؤيتها، أو بما أنك قلت إن هذا يحدث “أحيانًا” ببساطة:
لقد حاولتُ هنا وهناك إنشاء مكون مخصص للسمات (Customization > Theme component) للتحقق من العلم في كلٍ من العضو المُعلَّم والعضو الذي علَّم المنشور، وذلك مقابل المشرف. إذا كان المشرف هو صاحب المنشور المُعلَّم أو المستخدم الذي علَّم المنشور، فسيتم إخفاء أزرار المراجعة باستثناء خيار “تأجيل”.
لقد حاولتُ استخدام الذكاء الاصطناعي، لكنني أشك في أن التغييرات الأخيرة في قائمة مراجعة الأعلام قد تسبب بعض المشكلات.
سيكون هذا مفيدًا أيضًا مع مشرفي الفئات لضمان نزاهة إجراءات المراجعة، كما هو وارد في رأيي. ففي الماضي، كان هناك مشرف كان يُعلِّم منشورات عضو لديه خلاف معه، ثم يوافق على علامته الخاصة. بينما قد يقول البعض “اختر مشرفيك بشكل أفضل”، إلا أن وجود طريقة بسيطة لمنع الإغراء هو الأفضل.
ربما لا تكون هذه الطريقة آمنة تمامًا، لكن الكود المقترح في AU أشار إلى أنه يمكن للمكون إنشاء سجل إذا حاول أحد التحايل. ربما سأشارك لاحقًا عينة من الكود في منشور للمطورين.
لا أفهم تمامًا كيف تساعد محاولاتك لإنشاء مكون يخفي شيئًا ما في قائمة مراجعة في منع إخفاء المنشور بسبب علامة من مشرف. غالبًا ما يكون للعلامات من قبل المستخدمين ذوي مستويات الثقة العالية قوة أكبر مما هو مقصود. @Steradiant ليس الأول الذي يرغب في علامة لا تخفي المنشور Trigger Moderator Attention Instead of Auto-hiding Flag
إذًا ربما لم أشرح الأمر بشكل كافٍ لتفهم الغرض
الفكرة بسيطة جدًا إذا كان المشرف الذي يراجع قائمة المراجعة (Review Que) متورطًا بشكل مباشر في المحتوى الذي تم الإبلاغ عنه. عندئذٍ يكون الخيار الوحيد هو تأجيله لمشرف آخر غير متورط لمراجعة المحتوى الذي تم الإبلاغ عنه.
لذا
مشرف_المنشور (mlMod) = مؤلف المنشور الذي تم الإبلاغ عنه. لا يمكنه حل البلاغ لأنه مؤلف المحتوى الذي تم الإبلاغ عنه. ولضمان النزاهة، يحتاج مشرف آخر إلى مراجعته.
المشرف هو المستخدم الذي أبلغ عن المنشور. لا يمكنه حل البلاغ لأنه يعتبر تضاربًا أيضًا لأنه هو من أبلغ عن المنشور. لذا يحتاج مشرف آخر إلى مراجعة البلاغ وحله.
هذا يضمن نزاهة عملية الإشراف من خلال وجود ضمانات ضد الإشراف المتحيز. في حالتي، سيقوم زميل مشرف بالإبلاغ عن القرارات التي اتخذها ضد مستخدمين آخرين خلال اختلافات في الرأي لا علاقة لها بـ “الجدال مع مشرف” وحل هذه البلاغات.
بينما يمكننا تطبيق السياسات والاعتماد على اختيار الأشخاص المناسبين ليكونوا في الفريق. فإن الوقاية كإجراء وقائي هي الأفضل لإزالة الإغراءات. بالإضافة إلى ذلك، مع إضافة الإشراف حسب الفئة، يحمي هذا الإجراء الوقائي أيضًا نزاهة المشرفين المتطوعين.