وضع بطيء أكثر نعومة: مطبات بطيئة؟

أعجبني حقًا النية الكامنة وراء الوضع البطيء، لكنه لا يعالج تمامًا الدافع الأكثر شيوعًا للخلافات الحادة على منصتنا:

  • يدخل شخص ما “بغضب” — وغالبًا ما يكون جديدًا أو قادمًا من مجتمع آخر — ويذكر قائمة من الشكاوى.
  • يستجيب العديد من الأعضاء الحاليين للتحدث إلى أو مع المنشئ الأصلي بدوافع متفاوتة (لكن متلازمة “أعتقد أن شخصًا ما مخطئ على الإنترنت” تحتل مرتبة عالية).
  • يريد المنشئ الأصلي الرد على الجميع.
  • حتى في أفضل المناقشات، تتفاقم الأمور بسرعة.

الوضع البطيء لا يساعد هنا، لأن المشكلة هي من العديد إلى واحد. وغالبًا ما يؤدي فقط إلى مزيد من تهميش العضو الجديد، حيث إنه هو من يشعر بالحد الأقصى من القيود: يمكن للعديد من الأشخاص الرد عليه بينما ينفد مؤقت التبريد، ثم يحصل على منشور واحد فقط للرد.

أداة أتمنى أن أمتلكها في ترسانتي لمواقف مثل هذه هي إبطاء رفع المواضيع. فالقوائم الافتراضية (كل من الأحدث والأعلى) تعطي أولوية لهذه المواضيع “الحارة”. وأود أن أتمكن من الحد من الرفع إلى مرة كل 12 ساعة أو ما شابه. إذن لن يكون ذلك حذفًا كاملًا من القائمة، بل تقليلًا كبيرًا في التأكيد قد يساعد في الحد من عدد المشاركين الجدد في المناقشة (إلا إذا كانوا يبحثون عنها بنشاط، وهو أمر مقبول تمامًا).

16 إعجابًا

يمكن للمستخدم المحفّز كتابة رد واحد وكثير من المشاركات الأخرى، أليس كذلك؟ … لا يزال ذلك ممكنًا في وضع البطء.

لكنني أتفق أيضًا على أن تقليل التكرار سيكون مفيدًا في وضع البطء أيضًا. :slight_smile:

إعجابَين (2)

بالتأكيد، لكن مثل هذه المنشورات الضخمة التي ترد على رسائل كثيرة تجعل إدارة الموضوع أكثر صعوبة. تصبح عمليات التقسيم مستحيلة، وتميل إلى جعل الناشر أكثر غضبًا (أو على الأقل، تُعطي مظهرًا للتفاقم فقط بسبب جدار النص الضخم).

5 إعجابات

في الواقع، هذا نتيجة غير مقصودة أخرى لوضع ‘السرعة البطيئة’ التي لاحظناها في منتدى جوليا، وهو استضافة مدفوعة ونشطة للغاية: حيث يتم تفعيل وضع السرعة البطيئة، فيبدأ بعض الأشخاص في تعديل منشوراتهم بدلاً من كتابة منشورات جديدة. توجد مشكلة مماثلة عند تعيين شخص يسبب مشاكل إلى مستوى TL0: فلا يمكنه إنشاء منشورات جديدة، لكنه لا يزال قادرًا على تعديل منشوراته القديمة، فيقوم بذلك، وهو أمر سيء بشكل خاص إذا كان قد كتب محتوى استفزازيًا رد عليه الآخرون ثم قام بتعديله، مما يجعل الردود تبدو غير متناسبة.

ولكن نعم، أؤيد بشدة اقتراح @mbauman—فقدرة منع موضوع ساخن من الصعود بشكل متكرر ستكون مفيدة جدًا لتهدئة الأجواء.

3 إعجابات

بالإضافة إلى منع رفع الموضوع الساخن، قد تكون فكرة جيدة تأخير الإشعارات. هذا يحل نوعًا من المشكلة حيث يرد شخص ما أو يذكر مستخدمين متعددين.

4 إعجابات

حيلة يمكنك استخدامها اليوم هي جعل المواضيع مثل هذه غير مدرجة في القائمة. نحن نخطط لإضافة مؤقتات يمكنها إعادة إدراجها، لكن يمكنك القيام بذلك يدويًا.

ظهرت فكرة «دفن» الموضوع في الماضي، وهي شيء فكرنا فيه.

5 إعجابات

أنا لا أفهم حقًا ما تقترحه. هل يمكنك أن تريني نموذجًا لواجهة المستخدم لكيفية عمل هذا، وما الذي سيراه المستخدم، وما الذي سيراه الموظف؟

لهذا السبب يتم تحديد التعديل افتراضيًا في الوضع البطيء. يمكنك إيقاف حدود التعديل إذا كنت تثق في مجتمعك بعدم القيام بذلك.

وفكر فيما قاله @sam. اجعل الموضوع غير مدرج. يرجى الاستفادة الكاملة من الأدوات الموجودة في مجموعة الأدوات الخاصة بك قبل اقتراح المزيد.

الفكرة الأساسية بسيطة جدًا: سأسميها شيئًا مثل “الحد من ارتفاع المواضيع…” في قائمة مواضيع المسؤول (من المحتمل أن تكون بجوار عنصر “:anchor: إعادة تعيين تاريخ الارتفاع”). ستظهر مربع حوار يطالبك بإدخال الفترة الزمنية. سيكون النص شيئًا مثل: “الحد من تكرار ظهور هذا الموضوع في أعلى قوائم أحدث المواضيع والفئات الأخرى بحد أقصى مرة كل X ساعات”, مع قيمة افتراضية تبلغ حوالي 8 ساعات.

لا أشعر بقوة تجاه كيفية تنفيذ ذلك؛ يمكن أن يكون له حالة (يتتبع آخر مشاركة قامت بتحديث وقت ارتفاع الموضوع، ويقوم بتحديثه فقط إذا كان وقت مشاركة جديدة يزيد عن X ساعات في المستقبل) أو يمكن أن يكون بلا حالة (يقوم دائمًا بتعيين وقت تحديث الموضوع ليكون الجزء الصحيح من مضاعفات X ساعات من حقبة يونكس أو أول مشاركة). أو شيء آخر، مهما كان.

بالنسبة لما يتم عرضه للمستخدم، لست مقتنعًا بنسبة 100٪ بأنه يحتاج إلى إبلاغه، ولكنه يمكن أن يظهر كعنصر مشاركة “غير مدرج”، يذكر ببساطة: “سيظهر هذا الموضوع في أعلى قوائم المواضيع مرة كل X ساعات فقط”.


بالنسبة للأدوات الأخرى، نستخدم أحيانًا إلغاء إدراج المواضيع، ولكن هذا كله يتعلق بالمستخدمين الجدد العدوانيين - غالبًا من النوع الذي قد يشعر بالاستياء الشديد من أي تلميح للرقابة. وأنا حقًا لا أريد فرض رقابة / إخفاء / حذف الأشياء. الهدف هو تدخل أكثر لطفًا نأمل أن يكون أقل احتمالًا للتسبب في المزيد من الإزعاج بحد ذاته ولكنه سيساعد في الحفاظ على درجة الحرارة أقل قليلاً.

هذا مستوحى إلى حد ما من الطريقة التي تعاقب بها Hacker News المواضيع التي تحتوي على تعليقات أكثر بكثير من الإعجابات.

إعجابَين (2)

ما هي مشاعرك تجاه هذا @sam @eviltrout؟ يمكننا أن يكون لدينا عدد صحيح هنا يمثل الوقت، حيث يعني 0 “لا تسمح أبدًا بإعادة دفعه” و 1-6000 يمكن أن يعني “السماح بإعادة دفعه مرة واحدة كل {x} دقيقة” أو شيء من هذا القبيل.

إعجاب واحد (1)

إنها فكرة مثيرة للاهتمام - شيء مثل إلغاء الارتداد للارتطامات.

يبدو كأداة قوية ولكني أرى أنها قد تكون مفيدة. لا أعتقد أنه من السهل إضافتها - ربما شيء يتطلب مستوى متوسطًا من الجهد.

إعجاب واحد (1)

أعتقد أنه يمكن أن يكون مفيدًا في بعض السيناريوهات لمنع موضوع ما من اكتساب الكثير من الزخم في المقام الأول إذا تم اكتشافه مبكرًا بواسطة الإشراف. خاصة في الحالات التي تضم عددًا كبيرًا من المستخدمين.

إذا كان الموضوع ساخنًا بالفعل والنقاش مستدامًا ذاتيًا، فمن المحتمل أن يقوم وضع الإبطاء بعمل أفضل نظرًا لأن الإشعارات التي يتلقاها المستخدمون من التفاعلات في الموضوع (على الأرجح) ستبقيه مستمرًا.

كنت أتحقق من الكود المصدري وبصرف النظر عن تغيير النماذج، هل سيكون تغيير bypass_bump? كافيًا لمنعها من الارتداد؟

ربما إضافة حقل في Topic، مثل min_seconds_between_bumps على سبيل المثال وشرط آخر في bypass_bump?:

def bypass_bump?
  !@post_successfully_saved ||
    @topic_changes.errored? ||
    @opts[:bypass_bump] == true ||
    @post.whisper? ||
    only_hidden_tags_changed? ||
    @topic.min_seconds_between_bumps == 0 ||
    (@topic.min_seconds_between_bumps > 0 &&
      (Time.now - @topic.bumped_at) / 60 < @topic.min_seconds_between_bumps)
end

لست متأكدًا من القيمة 0 التي تشير إلى أنه لا ينبغي ترقية الموضوع على الإطلاق. يمكن أن يربك بعض المستخدمين. إذا تم القيام بذلك بهذه الطريقة، أعتقد أنه سيكون تجربة مستخدم أفضل إذا لم يكشف تطبيق الويب عن الصفر مباشرة للمستخدم.

3 إعجابات

إذا كنت أفسر هذا بشكل صحيح، فإن القرار بشأن ما إذا كان سيتم الرفع سيحدث في وقت نشر الرد ولكن إذا لم يتم نشر أي ردود لاحقة بعد فترة عدم الرفع، فلن يتم رفع الموضوع أبدًا.

هل سيكون هذا هو السلوك المرغوب فيه أم يجب أن يتم رفع الموضوع دائمًا في نهاية فترة عدم الرفع إذا تم نشر رد خلال الفترة؟ إذا كان يجب رفعه دائمًا، فهل يجب رفعه إلى “الآن” أم وقت أحدث رد؟

إعجابَين (2)

نعم، في هذا النهج، سيتم اتخاذ القرار عند نشر الرد، وبدون ردود لاحقة، لن يتم رفع الموضوع مرة أخرى. إذا كنت على صواب، نظرًا لأنني لست خبيرًا في كود مصدر Discourse بأي حال من الأحوال، فسيكون هذا هو الطريق السهل لتنفيذ ذلك.

السلوك الآخر المحتمل، الرفع بعد فترة التهدئة، سيتطلب على الأرجح المزيد من العمل كما قال @eviltrout، لأنه سيتطلب من التطبيق تخزين الرفع التالي المتوقع وأن يكون لديه نوع من المجدول أو وظيفة sidekiq لأداء عمليات الرفع المعلقة بشكل دوري.

كلا النهجين صالحان، وإذا تم تنفيذ هذا على الإطلاق، فلا أعرف أيهما سيتم اختياره.

أنا شخصياً لا أمانع إذا لم يتم رفع موضوع إشكالي مرة أخرى إذا لم تكن هناك ردود لاحقة. ولكن هذا مجرد رأيي.

إعجابَين (2)

أعتقد أن أبسط منطق هو هذا:

  • الموضوع له إعداد، “يمكن دفعه مرة واحدة كل {x} دقيقة” حيث عدد الدقائق هو إعداد قابل للتعديل، يتراوح من صفر (الافتراضي، يمكن دفعه عدة مرات حسب عدد الردود) إلى ~ 10000 (يمكن دفعه مرة واحدة في الأسبوع). لنفترض أن شخصًا ما أدخل 60 دقيقة، يمكن دفع الموضوع مرة واحدة كل 60 دقيقة كحد أقصى.

  • عند نشر رد، تحقق من تاريخ آخر دفعة:

    • إذا كان تاريخ آخر دفعة قبل أكثر من 60 دقيقة، اسمح بدفع الموضوع بواسطة هذا الرد الجديد.

    • إذا كان تاريخ آخر دفعة قبل أقل من 60 دقيقة، لا تدفع الموضوع عند نشر هذا الرد الجديد.

نعم، يبدو هذا بسيطًا وقابلًا للتطبيق.. لنضفه إلى الإصدار القادم @sam @eviltrout؟

6 إعجابات

هل يمكن أن يكون -1 (لا يمكن زيادتها إلى أجل غير مسمى) ذا قيمة أيضًا؟ أعتقد أنني أميل إلى لا، سيكون من الصعب العثور على مثل هذه المواضيع لاحقًا (بدون عمل إضافي) وإذا أراد مسؤول حقًا ألا يتم زيادة موضوع ما مرة أخرى أبدًا، فمن المنطقي إغلاقه.

أعتقد في الواقع أنه يجب أن يكون الحد الأقصى للوقت المحدد إعدادًا قابلاً للتكوين في صفحة المسؤول. شيء مثل max_slowbump_time أو شيء من هذا القبيل.

أيضًا، بينما نحن في صدد ذلك. هل يمكن تطبيق عمليات الترقية البطيئة على مستوى الفئة أيضًا؟

هل تم تطبيق ميزة كهذه على الإطلاق؟ لدينا سلسلة أخرى من هذا النوع دفعت @mbauman إلى طلبها في الأصل، وإذا كانت هذه الميزة موجودة الآن، فسيكون من الرائع أن نتمكن من استخدامها.