أعجبني حقًا النية الكامنة وراء الوضع البطيء، لكنه لا يعالج تمامًا الدافع الأكثر شيوعًا للخلافات الحادة على منصتنا:
يدخل شخص ما “بغضب” — وغالبًا ما يكون جديدًا أو قادمًا من مجتمع آخر — ويذكر قائمة من الشكاوى.
يستجيب العديد من الأعضاء الحاليين للتحدث إلى أو مع المنشئ الأصلي بدوافع متفاوتة (لكن متلازمة “أعتقد أن شخصًا ما مخطئ على الإنترنت” تحتل مرتبة عالية).
يريد المنشئ الأصلي الرد على الجميع.
حتى في أفضل المناقشات، تتفاقم الأمور بسرعة.
الوضع البطيء لا يساعد هنا، لأن المشكلة هي من العديد إلى واحد. وغالبًا ما يؤدي فقط إلى مزيد من تهميش العضو الجديد، حيث إنه هو من يشعر بالحد الأقصى من القيود: يمكن للعديد من الأشخاص الرد عليه بينما ينفد مؤقت التبريد، ثم يحصل على منشور واحد فقط للرد.
أداة أتمنى أن أمتلكها في ترسانتي لمواقف مثل هذه هي إبطاء رفع المواضيع. فالقوائم الافتراضية (كل من الأحدث والأعلى) تعطي أولوية لهذه المواضيع “الحارة”. وأود أن أتمكن من الحد من الرفع إلى مرة كل 12 ساعة أو ما شابه. إذن لن يكون ذلك حذفًا كاملًا من القائمة، بل تقليلًا كبيرًا في التأكيد قد يساعد في الحد من عدد المشاركين الجدد في المناقشة (إلا إذا كانوا يبحثون عنها بنشاط، وهو أمر مقبول تمامًا).
بالتأكيد، لكن مثل هذه المنشورات الضخمة التي ترد على رسائل كثيرة تجعل إدارة الموضوع أكثر صعوبة. تصبح عمليات التقسيم مستحيلة، وتميل إلى جعل الناشر أكثر غضبًا (أو على الأقل، تُعطي مظهرًا للتفاقم فقط بسبب جدار النص الضخم).
في الواقع، هذا نتيجة غير مقصودة أخرى لوضع ‘السرعة البطيئة’ التي لاحظناها في منتدى جوليا، وهو استضافة مدفوعة ونشطة للغاية: حيث يتم تفعيل وضع السرعة البطيئة، فيبدأ بعض الأشخاص في تعديل منشوراتهم بدلاً من كتابة منشورات جديدة. توجد مشكلة مماثلة عند تعيين شخص يسبب مشاكل إلى مستوى TL0: فلا يمكنه إنشاء منشورات جديدة، لكنه لا يزال قادرًا على تعديل منشوراته القديمة، فيقوم بذلك، وهو أمر سيء بشكل خاص إذا كان قد كتب محتوى استفزازيًا رد عليه الآخرون ثم قام بتعديله، مما يجعل الردود تبدو غير متناسبة.
ولكن نعم، أؤيد بشدة اقتراح @mbauman—فقدرة منع موضوع ساخن من الصعود بشكل متكرر ستكون مفيدة جدًا لتهدئة الأجواء.
الفكرة الأساسية بسيطة جدًا: سأسميها شيئًا مثل “الحد من ارتفاع المواضيع…” في قائمة مواضيع المسؤول (من المحتمل أن تكون بجوار عنصر “ إعادة تعيين تاريخ الارتفاع”). ستظهر مربع حوار يطالبك بإدخال الفترة الزمنية. سيكون النص شيئًا مثل: “الحد من تكرار ظهور هذا الموضوع في أعلى قوائم أحدث المواضيع والفئات الأخرى بحد أقصى مرة كل X ساعات”, مع قيمة افتراضية تبلغ حوالي 8 ساعات.
لا أشعر بقوة تجاه كيفية تنفيذ ذلك؛ يمكن أن يكون له حالة (يتتبع آخر مشاركة قامت بتحديث وقت ارتفاع الموضوع، ويقوم بتحديثه فقط إذا كان وقت مشاركة جديدة يزيد عن X ساعات في المستقبل) أو يمكن أن يكون بلا حالة (يقوم دائمًا بتعيين وقت تحديث الموضوع ليكون الجزء الصحيح من مضاعفات X ساعات من حقبة يونكس أو أول مشاركة). أو شيء آخر، مهما كان.
بالنسبة لما يتم عرضه للمستخدم، لست مقتنعًا بنسبة 100٪ بأنه يحتاج إلى إبلاغه، ولكنه يمكن أن يظهر كعنصر مشاركة “غير مدرج”، يذكر ببساطة: “سيظهر هذا الموضوع في أعلى قوائم المواضيع مرة كل X ساعات فقط”.
بالنسبة للأدوات الأخرى، نستخدم أحيانًا إلغاء إدراج المواضيع، ولكن هذا كله يتعلق بالمستخدمين الجدد العدوانيين - غالبًا من النوع الذي قد يشعر بالاستياء الشديد من أي تلميح للرقابة. وأنا حقًا لا أريد فرض رقابة / إخفاء / حذف الأشياء. الهدف هو تدخل أكثر لطفًا نأمل أن يكون أقل احتمالًا للتسبب في المزيد من الإزعاج بحد ذاته ولكنه سيساعد في الحفاظ على درجة الحرارة أقل قليلاً.
هذا مستوحى إلى حد ما من الطريقة التي تعاقب بها Hacker News المواضيع التي تحتوي على تعليقات أكثر بكثير من الإعجابات.
ما هي مشاعرك تجاه هذا @sam@eviltrout؟ يمكننا أن يكون لدينا عدد صحيح هنا يمثل الوقت، حيث يعني 0 “لا تسمح أبدًا بإعادة دفعه” و 1-6000 يمكن أن يعني “السماح بإعادة دفعه مرة واحدة كل {x} دقيقة” أو شيء من هذا القبيل.
أعتقد أنه يمكن أن يكون مفيدًا في بعض السيناريوهات لمنع موضوع ما من اكتساب الكثير من الزخم في المقام الأول إذا تم اكتشافه مبكرًا بواسطة الإشراف. خاصة في الحالات التي تضم عددًا كبيرًا من المستخدمين.
إذا كان الموضوع ساخنًا بالفعل والنقاش مستدامًا ذاتيًا، فمن المحتمل أن يقوم وضع الإبطاء بعمل أفضل نظرًا لأن الإشعارات التي يتلقاها المستخدمون من التفاعلات في الموضوع (على الأرجح) ستبقيه مستمرًا.
كنت أتحقق من الكود المصدري وبصرف النظر عن تغيير النماذج، هل سيكون تغيير bypass_bump? كافيًا لمنعها من الارتداد؟
ربما إضافة حقل في Topic، مثل min_seconds_between_bumps على سبيل المثال وشرط آخر في bypass_bump?:
لست متأكدًا من القيمة 0 التي تشير إلى أنه لا ينبغي ترقية الموضوع على الإطلاق. يمكن أن يربك بعض المستخدمين. إذا تم القيام بذلك بهذه الطريقة، أعتقد أنه سيكون تجربة مستخدم أفضل إذا لم يكشف تطبيق الويب عن الصفر مباشرة للمستخدم.
إذا كنت أفسر هذا بشكل صحيح، فإن القرار بشأن ما إذا كان سيتم الرفع سيحدث في وقت نشر الرد ولكن إذا لم يتم نشر أي ردود لاحقة بعد فترة عدم الرفع، فلن يتم رفع الموضوع أبدًا.
هل سيكون هذا هو السلوك المرغوب فيه أم يجب أن يتم رفع الموضوع دائمًا في نهاية فترة عدم الرفع إذا تم نشر رد خلال الفترة؟ إذا كان يجب رفعه دائمًا، فهل يجب رفعه إلى “الآن” أم وقت أحدث رد؟
نعم، في هذا النهج، سيتم اتخاذ القرار عند نشر الرد، وبدون ردود لاحقة، لن يتم رفع الموضوع مرة أخرى. إذا كنت على صواب، نظرًا لأنني لست خبيرًا في كود مصدر Discourse بأي حال من الأحوال، فسيكون هذا هو الطريق السهل لتنفيذ ذلك.
السلوك الآخر المحتمل، الرفع بعد فترة التهدئة، سيتطلب على الأرجح المزيد من العمل كما قال @eviltrout، لأنه سيتطلب من التطبيق تخزين الرفع التالي المتوقع وأن يكون لديه نوع من المجدول أو وظيفة sidekiq لأداء عمليات الرفع المعلقة بشكل دوري.
كلا النهجين صالحان، وإذا تم تنفيذ هذا على الإطلاق، فلا أعرف أيهما سيتم اختياره.
أنا شخصياً لا أمانع إذا لم يتم رفع موضوع إشكالي مرة أخرى إذا لم تكن هناك ردود لاحقة. ولكن هذا مجرد رأيي.
الموضوع له إعداد، “يمكن دفعه مرة واحدة كل {x} دقيقة” حيث عدد الدقائق هو إعداد قابل للتعديل، يتراوح من صفر (الافتراضي، يمكن دفعه عدة مرات حسب عدد الردود) إلى ~ 10000 (يمكن دفعه مرة واحدة في الأسبوع). لنفترض أن شخصًا ما أدخل 60 دقيقة، يمكن دفع الموضوع مرة واحدة كل 60 دقيقة كحد أقصى.
عند نشر رد، تحقق من تاريخ آخر دفعة:
إذا كان تاريخ آخر دفعة قبل أكثر من 60 دقيقة، اسمح بدفع الموضوع بواسطة هذا الرد الجديد.
إذا كان تاريخ آخر دفعة قبل أقل من 60 دقيقة، لا تدفع الموضوع عند نشر هذا الرد الجديد.
نعم، يبدو هذا بسيطًا وقابلًا للتطبيق.. لنضفه إلى الإصدار القادم @sam@eviltrout؟
هل يمكن أن يكون -1 (لا يمكن زيادتها إلى أجل غير مسمى) ذا قيمة أيضًا؟ أعتقد أنني أميل إلى لا، سيكون من الصعب العثور على مثل هذه المواضيع لاحقًا (بدون عمل إضافي) وإذا أراد مسؤول حقًا ألا يتم زيادة موضوع ما مرة أخرى أبدًا، فمن المنطقي إغلاقه.
هل تم تطبيق ميزة كهذه على الإطلاق؟ لدينا سلسلة أخرى من هذا النوع دفعت @mbauman إلى طلبها في الأصل، وإذا كانت هذه الميزة موجودة الآن، فسيكون من الرائع أن نتمكن من استخدامها.