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

ميزة
1

I really like the intention behind slow mode, but it doesn’t quite address the most common driver for flamewars on our discourse:

  • Someone comes in “hot” — often someone new, often someone from another community — and lists a bunch of grievances
  • Lots of existing members respond to talk to/at the original poster with varying motivations (but with the “I think someone is wrong on the internet” syndrome ranking high)
  • The original poster wants to respond to/at everyone
  • Even in the best of discussions, things snowball rapidly.

Slow mode doesn’t help here, because there’s a many-to-one problem. It often just further alienates the new member as they’re the one that feels the brunt of the limitation: many can respond to them while their cool down timer is burning and then they only get one post to respond.

One tool I wish I had in my toolbox for situations like these is to slow down the bumping of the topic. The default listings (both latest and top) prioritize these “hot” topics. I’d love to be able to limit the bumps to once-every-12-hours or some such. Then it’s not a complete de-listing, but it’s a significant de-emphasizing that could help limit the number of new entrants to the discussion (unless they actively seek it out, which is just fine).

16 إعجابًا
2

A motivated user could write a single reply and quite many other posters though, right? ….that still would be possible in slow mode.

But I do agree that a reduced-bumping would also be useful in slow-mode. :slight_smile:

إعجابَين (2)
3

Absolutely, but such monster posts that reply to many messages make the topic even harder to manage. Splits become impossible, and they tend to put the poster even more on a war-path (or at the very least, give the appearance of aggravation just by virtue of the large wall of text).

5 إعجابات
4

That’s actually another unintended consequence of slow mode that we’ve seen on Julia discourse, which is a paid hosted instance that’s quite active: slow mode gets turned on and some people start editing their posts instead of writing new ones. Similar problem with setting someone who’s being problematic to TL0: they can’t make new posts but they can still edit their old ones, so they’ll do that, which is especially bad if they’re written inflammatory stuff which people reply to and they then edit, making the response look out of line.

But yes, I definitely second @mbauman’s suggestion—being able to prevent a hot topic from getting bumped so often would be very helpful for cooling things down.

3 إعجابات
5

In addition to preventing the hot topic from getting bumped, it might be an idea to delay the notifications. That kind of solves the issue where someone replies to or mentions multiple users.

4 إعجابات
6

A trick you can use today is to make topics like this unlisted, we do plan to add timers that can relist, but you could do that by hand

“Bury” topic has popped up in the past, and something we have thought about

5 إعجابات
7

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

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

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

8

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

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

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

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

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

إعجابَين (2)
9

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

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

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

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

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

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

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

كنت أتحقق من الكود المصدري وبصرف النظر عن تغيير النماذج، هل سيكون تغيير 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 إعجابات
12

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

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

إعجابَين (2)
13

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

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

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

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

إعجابَين (2)
14

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

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

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

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

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

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

6 إعجابات
15

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

16

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

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

17

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