بناءً على قلة الاستجابة لهذه المنشورات، فإن شكي هو أنه لا يوجد الكثير من الاهتمام من فريق Discourse أو المجتمع لمتابعة استخدام Discourse كمنصة للتعليقات. هذا لا بأس به من وجهة نظري، ولكني أود أن أبذل محاولة لتوضيح حجتي.
ستكون المشكلة مع X/Twitter واضحة لأي شخص يستخدم هذا النظام الأساسي. لقد غيّر التغيير الأخير في الملكية نبرة الموقع بالكامل - يتم غمر أي منشورات إعلامية رئيسية بتعليقات من نوع “lol”. أشك في أن المنشورات تولد بعض التفاعل، ولكن الردود يجب أن تكون محبطة للصحفيين الذين يكتبون المقالات.
يبدو من الواضح بالنسبة لي أن Discourse يمكن أن يقدم حلاً محتملاً لهذه المشكلة.
أقرب منافس يمكنني رؤيته في هذا المجال هو Coral (مشروع مفتوح المصدر تموله Vox Media.) يتم تلخيص فلسفة Coral هنا: https://coralproject.net/blog/five-myths-of-community-design-day-one/. أرى القليل جدًا مما يفعله Coral والذي لا يمكن تحقيقه ببضع تحسينات على وظيفة تضمين التعليقات في Discourse. على الواجهة الخلفية، فيما يتعلق بالإشراف على المحادثات وتنظيمها حول المقالات، أعتقد أن Discourse يمكن أن يحسن بسهولة ما يقدمه Coral.
لست متأكدًا من أن الترويج لاستخدام Discourse كنظام تعليقات سيولد قدرًا كبيرًا من الإيرادات لفريق Discourse، أو لمجموعة أخرى ترغب في تولي الأمر. أعتقد أنه يمكن أن يساعد في تحسين الصحافة عبر الإنترنت والديمقراطية.
للتوضيح الكامل، في وقت فراغي، أعمل حاليًا على إضافة WordPress لتحسين التعليقات التي تبني على بعض الأفكار التي ذكرتها هنا: Active moderation mode - a slow mode alternative. حتى لو تمكنت من تحقيق ذلك، فلن يكون له نفس التأثير الذي يمكن أن يحدثه نظام تعليقات Discourse - قد تستخدمه المدونات، ولكن من غير المرجح أن تستخدمه مواقع الأخبار الرئيسية.
إن بناء نظام تعليقات مناسب للقراءة والكتابة هو مهمة ضخمة. يمكن أن تملأ دورة كاملة (6 أشهر) لفريق مكون من 5 أشخاص بسهولة.
أنا ببساطة لا أرى أن لدينا النطاق الترددي لهذا في الوقت الحالي، بالإضافة إلى قدر كبير من عمل تحديث JavaScript الذي لا يزال قيد التغيير.
نظرًا لأن هذا من غير المرجح أن يتم تبنيه من قبل فريق Discourse في الـ 12 شهرًا القادمة، أعتقد أن المسار الوحيد الممكن إلى الأمام سيكون لطرف ثالث لإنشاء نموذج أولي / بناء حل. مع النطاق الصحيح والفريق المناسب، سأنظر في رعاية جزء من هذا على الأقل.
لكن الشيء الصعب هنا هو نقص الاهتمام، وهذا سيكون تخمينيًا للغاية.
لا أعتقد أنه يجب أن يكون نظام قراءة/كتابة. يجب إنشاء التعليقات على المنتدى، تمامًا كما هي الآن.
الحجج المؤيدة تفشل في ملاحظة أن هذا يأتي في الوقت المناسب بسبب التغييرات الأخيرة في فيسبوك و X/تويتر. هناك حاليًا الكثير من النقاش، على الأقل في كندا، حول كيفية بقاء المؤسسات الإخبارية على قيد الحياة في العصر الرقمي.
أعتقد أن الحجج المعارضة تبالغ في تقدير الصعوبة التقنية. ربما ستكون هناك حاجة لإضافة نقطة نهاية oEmbed للمواقع التي لا ترغب في عرض التعليقات في إطار iframe. (يوفر Coral خيار عرض التعليقات في إطار iframe، أو سحبها من نقطة نهاية واجهة برمجة تطبيقات oEmbed.) بخلاف ذلك، يجب أن يكون الأمر مجرد مسألة تحسين وظيفة تضمين التعليقات الحالية.
بعض الاحتكاك جيد. فهو يقلل من احتمالية التعليقات ذات الجهد المنخفض.
أنظمة التعليقات الحالية التي تسمح للمستخدمين بالتعليق مباشرة على المقال قد تُدخل الاحتكاك من خلال عملية الإشراف على أي حال. على سبيل المثال، يقوم نظام تعليقات CBC بالإشراف على جميع التعليقات وقد يحتفظ بالتعليق لمدة 30 دقيقة أو أكثر قبل الموافقة عليه أو رفضه. يمكن لنظام تعليقات مدعوم بـ Discourse أن يسمح بإجراء محادثة طبيعية وفي الوقت الفعلي على المنتدى، مع إدخال فارق زمني بين وقت نشر التعليقات على المنتدى وظهورها على الموقع. سيعطي هذا المشرفين فرصة للعمل مع المعلقين لتوضيح ما يحاولون قوله، والنظر في وجهات نظر أخرى، والنظر فيما إذا كان ما ينشرونه هو حقًا شيء يريدون مشاركته مع الإنترنت بأكمله، وما إلى ذلك. في الأساس، سيتم نشر أفضل المشاركات التي تم إنشاؤها على المنتدى على الموقع.
يحل نشر التعليقات أولاً على المنتدى أيضًا مشاكل تحسين محركات البحث المحتملة التي يمكن أن تنشأ من نشر الكثير من التعليقات غير ذات الصلة مباشرة على موقع ويب.
الأمر يتعلق أكثر بتحسين الميزات الحالية. وأيضًا، ربما إضافة بعض ميزات الإشراف، وتطوير وإعلان طريقة يمكن استخدامها لأنظمة التعليقات المدعومة بـ Discourse.
تحسينات الميزات:
إصلاح المشكلات المتعلقة بتضمين المشاركات الخارجية على Discourse. هذا صعب للغاية حاليًا في الإعداد.
للمواضيع التي تم إنشاؤها من المشاركات المضمنة، اسمح للموظفين بتحديد المشاركات التي سيتم سحبها إلى الموقع.
تحسين قالب التعليقات الحالي
إضافة علامات تبويب إلى القالب للسماح بالاختيار بين “المميزة”، و"الكل" (نسخة مُنظفة من جميع التعليقات بترتيب زمني)، وربما “ذات الصلة” (السماح للمشرفين والمستخدمين الموثوق بهم بتفرع المناقشة إلى موضوع ذي صلة).
إضافة زر “إظهار المزيد” إلى قالب التعليقات للسماح بسحب التعليقات إلى الموقع على دفعات.
السماح بسحب التعليقات من فئة مقيدة إلى موقع ويب. سيعطي هذا خيارًا لوجود تعليقات من مناقشات خاصة على Discourse مضمنة في موقع ويب.
التأكد من تخزين التعليقات مؤقتًا على Discourse لضمان أن المستخدمين المجهولين الذين يزورون الموقع لا يضعون عبئًا كبيرًا على Discourse.
الميزات الجديدة المحتملة:
السماح للمشرفين (وربما المستخدمين الموثوق بهم) بإنشاء مواضيع حيث يمكنهم تقييد من يمكنه الرد على المستخدمين المذكورين في المشاركة الأصلية. إليك حالة استخدام: يجادل فريد وبيل بلا نهاية حول السيطرة على الأسلحة في المناقشة الرئيسية. اسمح للمشرف بإنشاء موضوع منفصل لفريد وبيل يكلفهما بمهمة، على سبيل المثال، جعلهما يتبعان قواعد Dennett للتعليق النقدي لمناقشة القضية. إذا تمكنوا من تحقيق ذلك، اسمح لهم بالعودة إلى المناقشة الرئيسية. ربما حتى تحديد أجزاء من مناقشتهم ذات الصلة ليتم نشرها على الموقع تحت علامة التبويب “ذات الصلة” في قالب التعليقات.
السماح للمشرفين باستبعاد مستخدمين معينين بسهولة من المناقشة، دون الحاجة إلى تعليقهم من الموقع ككل. على سبيل المثال، يمكن استبعاد فريد وبيل في مثالي أعلاه مؤقتًا من المناقشة الرئيسية حتى يحلوا خلافاتهم.
إنشاء مكون إضافي لـ AMA (اسألني أي شيء) بطريقة التنقيط البطيء إذا لم يكن موجودًا بالفعل. على سبيل المثال، بدلاً من إجراء AMA دفعة واحدة، اسمح للمستخدمين بتقديم الأسئلة أو التعليقات إلى خبير والسماح بنشر الأسئلة والإجابات على Discourse (والموقع ذي الصلة) على مدار أسبوع تقريبًا. (بالنسبة للكنديين، فكرتي هنا هي Cross Country Checkup مدعوم بـ Discourse.)
إضافة نقطة نهاية API لـ oEmbed لاسترداد التعليقات.
تطوير وإعلان طريقة لأنظمة التعليقات المدعومة بـ Discourse:
يبدو هذا الجزء الأصعب من المهمة بالنسبة لي. اكتشف كيف يمكن تكوين التعليقات المضمنة، وميزات الإشراف في Discourse، والمكون الإضافي Perspective API، والمكون الإضافي Subscriptions، وما إلى ذلك، بأفضل شكل لتلبية احتياجات منظمة إخبارية رئيسية. تحدث مع الصحفيين والناشرين وقراء الأخبار لمعرفة كيفية تلبية احتياجاتهم على أفضل وجه. حاول معالجة المشكلات الحالية المتعلقة بالاستقطاب، ونقص الإجماع، ونقص الثقة بطريقة حساسة وفعالة. ضع دائمًا في الاعتبار فكرة أن الصحافة ركيزة أساسية للديمقراطية.
بعد القيام بما سبق، قم بالترويج لـ Discourse كمنصة للتعليقات والمجتمع للمنظمات الإخبارية.
الجوانب التقنية لما أشرت إليه أعلاه لا تبدو تقنية بشكل مفرط بالنسبة لي. ما لم أكن أفتقد شيئًا ما، فإن كل شيء يقع ضمن نطاق ما يمكنني إنجازه بنفسي.
أنا مشارك في موقع إخباري قام بتجربة استخدام Discourse للتعليقات.
لدينا نسخة Discourse راسخة ونشطة (لكن مغلقة)، لذلك كنا متحمسين جدًا لدمج الاثنين عبر التعليقات.
بينما كانت هناك فوائد عديدة (خاصة من خلال جذب أعضاء المجتمع لتقديم تعليقات عالية القيمة على المقالات الإخبارية)، يؤسفني أن أقول إننا تخلينا عنها بعد تجربة جادة. القضايا الرئيسية بالنسبة لنا:
كان الإعداد صعبًا (ليس مفاجئًا مع وجود منصتين معقدتين متضمنتين!)
احتكاك المستخدمين الذين اضطروا لمغادرة الموقع الإخباري للتعليق
قمنا بتبسيط عملية الانضمام لدينا لتسهيل ذلك، لكنها كانت لا تزال احتكاكًا كبيرًا
أدوات غير كافية لتسليط الضوء على المناقشة داخل WordPress
أظهرت تعليقات WP الأصلية الضعيفة فقاعة كلام وعددًا في صفحات الاكتشاف؛ وقد افتقدنا هذا بشدة
كان المظهر الواضح للمشاركة النشطة في أكبر عدد ممكن من المواضيع مهمًا جدًا للفريق الإخباري
صعوبة إقناع الفريق الإخباري بالمشاركة فعليًا في Discourse
أتساءل عما إذا كانت هذه ستكون مشكلة كبيرة لموقع أخبار رئيسي مزدحم للغاية. على سبيل المثال، موقع متردد في عرض التعليقات لأنه يتلقى الكثير من التعليقات من المتصيدين والكارهين.
أتساءل عما إذا كان يمكن إجراء أي تغييرات على واجهة المستخدم تجعل من الواضح أن التعليقات المعروضة على الموقع كانت مقتطفات من مناقشة أكبر كانت تجري في المنتدى. بهذه الطريقة، لن يتوقع القراء أن يتمكنوا من التعليق على الموقع، ثم يصابون بخيبة أمل لرؤية أنهم بحاجة لزيارة المنتدى. في كلتا الحالتين (التعليق على الموقع مقابل التعليق في المنتدى)، سيحتاج المستخدمون إلى إنشاء حساب وتسجيل الدخول قبل ترك تعليق، لذا يبدو الاحتكاك متصورًا أكثر منه حقيقيًا من وجهة نظري.
هذه نقطة جيدة، خاصة فيما يتعلق بالتعليقات المضمنة التي لا تضيف أي بيانات إلى قاعدة بيانات موقع الأخبار. يمكنني التفكير في حل خاص بووردبريس لهذا. سيكون إعداده معقدًا إلى حد ما. (يمكنني مساعدتك في هذا إذا كنت ترغب في تجربته مرة أخرى.)
نعم، أعتقد أن فريق الأخبار سيحتاج إلى المشاركة لجعل هذا الأمر يستحق المتابعة. قد يكون هذا أيضًا حلاً لمشكلة الاحتكاك. إذا عرف المعلقون المحتملون أن لديهم فرصة للتفاعل مع مؤلف المقال على Discourse، فقد يكونون أكثر عرضة لزيارة المنتدى.
أنا مرتبك بهذا، هل أسقط WP-discourse عدد التعليقات مؤخرًا؟ لقد طبقت تعليقات Discourse على مواقع Wordpress وكانت بالتأكيد شيئًا ما ما لم يتجاوز قالب Wordpress المعني الطريقة المدعومة للحصول عليها.
في منشور إخباري محلي مقره الولايات المتحدة يخطط لاستخدام Discourse في صحافته، أود أن أعرب عن دعمي لهذا الاتجاه العام.
إذا كان الهدف هو تحسين الخطاب حول القضايا المدنية التي تغطيها وسائل الإعلام، وكانت العقبات الرئيسية المحددة هي إدماج الموظفين واحتكاك المستخدم: أفضل التفكير في الحل على أنه استخدام Discourse كنظام إدارة محتوى (CMS)، حيث يمكن لفئة أن تنشر على نطاق منفصل لـ “المنشور الإخباري”.
الجوانب التقنية التي تمت مناقشتها هنا حول تضمين التعليقات، والواجهة، والمصادقة، واحتكاك المستخدم بين موقعين تبدو على الأقل مدعومة هيكليًا بالاستخدام الأصلي لنظام واحد لكل من النشر والمجتمع/التعليقات.
كأداة تعاون داخلية لغرفة الأخبار، فإن Discourse مذهل. كأداة للنقاش الصحي، فإن Discourse مذهل. ولكن إنشاء منشور مميز بمحتوى من Discourse أمر صعب وهو ما أراه أكبر نقطة ضعف لدينا.
أدرك أن هذا ليس ما تم تصميم Discourse من أجله. أشارك بعض الأفكار بشكل أساسي لأنني أقدر أي تفكير في صناعة الأخبار هنا.
مع العلم أن هذا ليس جذابًا على الإطلاق لـ CDCK، أعتقد أنه يمكن التعامل مع هذا من خلال تحسين إضافات Wordpress أو WooCommerce، والتي تنشر المقالات على Discourse وتضمن الردود على مقالات Wordpress. أعتقد أن @simon كان سيذكر ذلك إذا كان ذا صلة.
هذا سيكون تفضيلي. على وجه التحديد، النشر ثنائي الاتجاه وتحسين مسارات مصادقة المستخدم.
يبدو أن إدماج الموظفين ليس مشكلة Discourse، ولكنه سيحظى بفرصة أكبر للنجاح إذا كان الموظفون يستخدمون نفس النظام لنظام إدارة المحتوى الخاص بهم بدلاً من الاضطرار إلى استخدام نظامين منفصلين. كما ذكرنا، إذا كان الموظفون أكثر انخراطًا، فقد يكون المستخدمون الذين يعلقون كذلك.
كملاحظة منفصلة، أعتقد أنه من المهم الإشارة إلى أن هناك مخاوف قانونية ومخاوف تتعلق بالموارد لدى غرف الأخبار فيما يتعلق بالمحتوى الذي ينشئه المستخدمون.
العديد من غرف الأخبار تعاني من نقص التمويل وطبيعة تغطيتها (عامة، مثيرة للجدل، ذات اهتمام عام) تعني أن المناقشات حولها من المرجح أن تتحول إلى مناطق سامة. قد لا يتمكن موظفو الإشراف من مواكبة ذلك. أعتقد أن نسبة الإشارة إلى الضوضاء مختلفة عما تراه مع معظم استخدامات Discourse. يبدو لي أن المجتمعات الصحية تحتاج إلى درجة معينة من الحصرية وأن وسائل الإعلام التي تفكر فيها ربما لا تكون حصرية في الموضوعات التي تغطيها.
كل هذا يعني أن غرف الأخبار قد تتردد في التعمق في أي نظام تعليقات بسبب المخاطر القانونية لعدم القيام بذلك بشكل صحيح. إذا نشرت تعليقًا غير صحيح على مقال صحيفة، فقد يُعتبر معلومات مضللة، بينما قد يبدو الرد غير الصحيح على meta مجرد رد هاوٍ. سيقول محامٍ أننا يجب أن نراجع ونحرر كل تعليق قبل نشره بالفعل. أساسًا: Write a Letter to The Atlantic - The Atlantic
في رأيي، المقارنات مع وسائل التواصل الاجتماعي محفوفة بالمخاطر، لكن بناء مجتمع حول الصحافة هو شيء أنا متحمس جدًا له.
ومن المثير للاهتمام، أنني كنت أتساءل مؤخرًا عن تقليص نطاق هذا المشروع إلى جعل Discourse نظام تعليقات صالحًا لمواقع الأخبار المستندة إلى WordPress. مع هذا النهج، يمكن معالجة معظم الاعتراضات الفنية التي أثيرت في هذا الموضوع بسهولة - بما في ذلك إضافة وظيفة للسماح للمستخدمين بالتعليق مباشرة على المقال الرئيسي. يمكن أن تكون إضافة WordPress الحالية نقطة انطلاق للمشروع. في غضون الأيام القليلة القادمة، سأقوم بتحديث هذا الموضوع بتفاصيل إضافية حول كيفية تنفيذه.
هل لديك أي فكرة عما إذا كانت المخاوف القانونية ستكون أقل إذا سُمح للمحتوى الذي ينشئه المستخدمون والذي يحتوي على معلومات مضللة محتملة بالوجود ومناقشته في موضوع Discourse خاص، ولكنه لم يتم عرضه في قسم التعليقات الخاص بالمقال المواجه للجمهور؟
نعم أعتقد ذلك، لكن ألا يتعارض ذلك مع اقتراحك؟ ألا تتطلع إلى عرض التعليقات على موقع النشر، مع المقالة؟
أنا لست محامياً، ولكن إشارتي كانت إلى حد كبير إلى القسم 230. يدرك الناشرون أنهم قد يُقاضون بتهمة التشهير إذا قاموا بتحرير المحتوى الذي ينشئه المستخدمون. إذا لم يلمسوه، فهم غير مسؤولين. في الوقت نفسه، فإن مبادئهم الأساسية - إعلام الجماهير الكبيرة، والدقة الصارمة - تثبطهم عن عرض أي معلومات غير دقيقة لقرائهم، حتى لو لم ينشئوها. هذا هو السبب في أنني أقول إنهم يختلفون عن وسائل التواصل الاجتماعي.
إذا أراد منشور ما اتباع نهج “عدم اللمس” للتعليقات، فيجب أن أتخيل أن استضافتها على نطاق منفصل سيكون النصيحة القانونية.
لا أعتقد أن التمييز بين العام والخاص ذو صلة كبيرة. الأمر يتعلق أكثر بما إذا كان محتوى طرف ثالث، وهو أمر يصبح غامضًا إذا تم عرضه كجزء من المنشور.
أريد أن أدرس جميع الخيارات. كان تفكيري الأولي هو أن المحادثات يجب أن تتم على Discourse وأن يتم دفع “أفضل” جوانب المحادثات إلى الموقع الرئيسي. هذا يعني أن المشرفين سيقومون بفحص التعليقات. قد يعرضهم ذلك للمسؤولية، لكنني أعتقد أن فحص التعليقات هو بالفعل ممارسة شائعة لمعظم المواقع الإخبارية الرئيسية. (أنا أستخدم موقع cbc.ca كمثال لي إلى حد كبير.)
التركيز على استخدام تعليقات Discourse على مواقع WordPress يفتح خيار السماح للمستخدمين بإنشاء تعليق مباشرة على المقال. لا يزال لدي بعض الأسئلة حول أفضل طريقة لتنفيذ ذلك. على سبيل المثال، هل يُسمح للمستخدمين بالرد مباشرة على تعليق مستخدم آخر مباشرة على صفحة المقال، أم يجب أن يقتصروا على التعليق مباشرة على المقال من تلك الصفحة؟ بقصد أن التعليقات ذات المستوى الأعلى فقط يمكن إنشاؤها من صفحة المقال. سيتم منع المستخدمين من الرد على منشور مستخدم آخر أو اقتباسه من تلك الصفحة.
يقدم نظام مستويات الثقة أو المجموعات في Discourse بعض الإمكانيات لتبسيط عملية الفحص لتعليقات الصفحة الرئيسية. على سبيل المثال، يمكن إضافة المستخدمين إلى مجموعة “المستخدمين الموثوق بهم” بناءً على بعض المعايير. يمكن لأعضاء هذه المجموعة أن تظهر تعليقاتهم فورًا على الصفحة الرئيسية. أنا أستبق الأحداث رغم ذلك.
أول فكرة تخطر ببالي هي أن كل هذه أفكار جيدة حقًا.
أنت تتحدث عن الترويج للتعليقات، على حد فهمي. يبدو تنسيق التعليقات المعروضة على موقع النشر أداة مناسبة وقوية للمشرف.
لست متأكدًا من تداعيات الردود المتداخلة مقابل الردود المباشرة. أفترض أن الردود المباشرة يمكن أن تقلل من خطر الجدالات.
أحد الاحتمالات هو أن إبقائها كردود مباشرة سيجعل من الواضح أن موقع Discourse هو المكان المناسب للنقاش والتفاعل مع المستخدمين الآخرين. إذا كانت واجهتهم الرئيسية هي التعليقات المنسقة، فقد لا يرون أبدًا تعليقهم يظهر ويصابون بالإحباط.
مع الردود المباشرة والتنسيق، يبدأ الأمر ليبدو أشبه بقسم الرسائل.
إذا كان يمكن استخدام حسابات البريد العشوائي التي تعمل بالذكاء الاصطناعي لكسب مستويات الثقة، فسأكون حذرًا.
يجب حل إمكانية استخدام المنصة للتعليقات ليس من جانب المنصة، ولكن من جانب إضافات تكامل أنظمة إدارة المحتوى (حيث يكون تسجيل الدخول الموحد عنصرًا إلزاميًا). على سبيل المثال، إذا قمت بتكملة إضافة تكامل ووردبريس الحالية بالقدرة على إضافة تعليقات من جانب ووردبريس، فسيتم حل المشكلة بالكامل.
سيكون من الممكن تقنيًا عرض جميع تعليقات Discourse على ووردبريس، لكن هذا يبدو عكسيًا بعض الشيء. إذا كنت سأقوم ببناء إضافة جديدة لهذا الغرض، فربما أستخدم نموذج تعليقات ووردبريس بدلاً من نشر التعليقات مباشرة إلى Discourse عبر واجهة برمجة التطبيقات. بعد نشر تعليق ووردبريس، يمكن نشره في Discourse كمنشور. بهذه الطريقة سيكون هناك علاقة 1 إلى 1 بين تعليقات ووردبريس ومنشورات Discourse. هذا النهج سيحل مشكلة كيفية عرض التعليقات على ووردبريس. كما أنه سيفتح إمكانية استخدام قائمة مراجعة Discourse لتعليقات ووردبريس.
لست متأكدًا من أن العديد من المواقع ستستفيد من هذه الوظيفة. أعتقد أنه سيكون من المفيد لـ Discourse التركيز على تحسين نصوص التضمين الحالية الخاصة بهم.
أنا مهتم أكثر بالسؤال العام حول ما إذا كان Discourse يمكن أن يكون أداة مفيدة لمواقع الإعلام التقليدية.