في العمل، نستخدم Slack بكثرة. هناك محتوى يحتاج إلى أن يكون متاحًا على Slack ولكن يجب أن يكون منظمًا وقابلًا للبحث، وكلا الأمرين رأينا أن Discourse يتفوق فيهما. جربنا بعض الخيارات الشبيهة بالويكي، لكنها جميعًا تتوقف عن التحديث، جزئيًا بسبب عدم وجود اتصال بـ Slack. لذا، أنا أقود تقييمًا لـ Discourse ليعمل بالتوازي مع Slack الحالي لدينا ويتصل به، حيث أنني أشغل بالفعل منتدى مجتمع على Discourse.
ومع ذلك، لدينا العديد من القنوات التي تستخدم الخيوط (threads) بشكل مكثف. وهذا يشمل قناة Slack ذات الأولوية القصوى التي تتطلب تكاملًا ثنائي الاتجاه (“المراقبة” و"النشر") بين Discourse و Slack.
هل سيكون ذلك انتهاكًا لإضافة تكامل الدردشة إذا أضفنا وضعًا غير افتراضي ينشئ مواضيع جديدة كرسائل على Slack، ويخزن ارتباط معرف رسالة Slack مع الموضوع، ثم يرسل التعليقات الجديدة على ذلك الموضوع إلى Slack كرسائل ضمن خيوط؟ بالنسبة لحالة الاستخدام الخاصة بي، قد يكون هذا هو العامل الرئيسي الذي يفرق بين النجاح والفشل.
تحديث: لحالة الاستخدام الخاصة بي، سيكون هذا خيارًا لـ “المراقبة” وليس إعدادًا عامًا لموقع الدردشة على Slack، لأن “تفضيل الخيوط” أو “عدم تفضيل الخيوط” هو تفضيل خاص بكل قناة بناءً على الغرض منها (والمشاركون المعتادون فيها).
تبدو هذه فكرة رائعة! إضافة ذلك إلى الإضافة ستكون بالتأكيد موضع ترحيب pr-welcome
فقط للتأكد… هل تقصد بـ “نشر” ميزة نشر النصوص الموجودة؟ أم أنك تحاول جعل خيط Slack يتزامن مع موضوع في Discourse. أعتقد أن الأخير معقد جدًا ليتم تنفيذه بشكل صحيح، وربما لن يناسب إضافة chat-integration.
لا، لم أكن أحاول مزامنة موضوع واحد بشكل ثنائي الاتجاه بحيث يمكنك النشر من أي طرف وانعكاس ذلك على الطرف الآخر. لقد كنت مسؤولاً عن تنفيذ مزامنة ثنائية الاتجاه كاملة للمزامنة النشطة-النشطة عبر نطاقين نشطين للغاية، وأنا مدرك تماماً للفرص التي قد تؤدي إلى أخطاء هناك.
سيناريوهنا هو قناة حيث:
الإجابات المتسلسلة هي القاعدة لأن القناة تميل إلى جمع محادثات متزامنة حول مواضيع غير مرتبطة (القناة مخصصة لغرض تجاري وليس لموضوع معين؛ البديل غير العملي سيكون دعوة نصف قسم الهندسة إلى قنوات مؤقتة جديدة يتم إنشاؤها عشرات المرات يومياً)
العديد من هذه المحادثات المتسلسلة (وليس جميعها) يجب تحديدها على أنها إجابات على أسئلة يود شخص آخر معرفة الإجابة عليها لاحقاً، ويتم استخدام التكامل لتعزيزها كإجابات موثوقة في الفئة المرتبطة في ديسكورد (شخص مثلي يقوم بتدقيق الإجابات المفيدة بنشاط)
يجب أن تؤدي المواضيع الجديدة في تلك الفئة المرتبطة في ديسكورد إلى نشر منشورات على سلاك في قناة سلاك تلك
يجب نشر التعليقات الإضافية على تلك المواضيع الجديدة في سلاك كجزء من سلسلة محادثات تتبع المنشور الأول الجديد على سلاك
يتم توجيه مستخدمينا للبحث في ديسكورد أولاً قبل طرح الأسئلة على سلاك
علاوة على ذلك، فإن سؤالك هذا يجعلني أفكر أنه كميزة ذات صلة، سيكون من الرائع وجود القدرة عند تلخيص سلسلة محادثات على سلاك إلى منشور في ديسكورد، على أن يقوم التكامل بنشر مؤشر إلى الموضوع الجديد في ديسكورد في نهاية سلسلة المحادثات الأصلية على سلاك التي تم تلخيصها للتو. سيكون هذا مفيداً لنا للحفاظ على المحادثة في مكان واحد.
في الواقع، هذا مرتبط بالفكرة الأصلية للميزة لأنه لو توفر كلا الأمرين، فسيكون من المنطقي بدلاً من نشر رسالة سلاك جديدة عند التلخيص، أن يتم نشر الرسالة في سلسلة المحادثات الملخصة، و الإشارة إلى أن تلك السلسلة هي المكان المناسب لنشر تعليقات ديسكورد الإضافية. لن يتم تلخيص تعليقات سلاك الإضافية في تلك السلسلة إلى ديسكورد؛ بل سيكون الهدف إعادة توجيه المحادثة إلى ديسكورد حول ذلك الموضوع. يبدو لي هذا منطقياً:
مَعطَى: يوجد مكان لتخزين معرف رسالة سلاك المرتبط بموضوع معين
وَ: يتم نشر التعليقات الجديدة على الموضوع كتعليقات على رسالة سلاك المخزنة
إذن: قم بتعيين معرف رسالة سلاك للموضوع عند استخدام ميزة تكامل بوت سلاك post thread، مما يؤدي إلى الإعلان عن تعليقات ديسكورد الجديدة على الموضوع في تلك السلسلة، بما في ذلك الروابط العائدة إلى موضوع/تعليق ديسكورد
هذا سيساعد حقاً في ترسيخ مفهوم “ابحث في ديسكورد أولاً قبل السؤال”.
لن يبدو الإعلان تماماً بهذه الطريقة؛ سيتم نشره من جانب watch في التكامل. لن يذكر أنه تم نقله. إليك مثال على الواجهة الحالية (غير المخططة) من تكامل Slack كما قمت بتنفيذه لـ makerforums:
في النموذج المخطط، سيؤدي أول تلك المنشورات إلى بدء موضوع في Slack، بينما سيكون تعليق Nedman بدلاً من ذلك في رد مخطط في Slack. عند استخدام post thread :thread_url، سيتم تخزين :thread_url مع الموضوع الجديد، وسينشر جانب watch من تكامل الدردشة المنشور الأول للموضوع و جميع التعليقات اللاحقة في ذلك الموضوع على Slack، لكن المحتوى سيكون هو نفسه.
يرسل تكامل watch thread إلى Discourse حيث يتعين عليك كتابة العنوان وتتاح لك فرصة تعديل منشور الموضوع الجديد قبل نشره. لذا، فإن الإعلان الذي يُنشر على Slack يُنسب بالفعل إلى الشخص الذي يشغّل post thread كمؤلف، ثم يحتوي على سطر يحتوي على عنوان الموضوع كنص رابط يوجه إلى Discourse، يليه اقتباس مقتطف من بداية المنشور. التغيير الذي أقترحه هنا هو أنه مع إعداد غير افتراضي ومخصص لكل قناة (أي خيار watch، وليس إعدادات إضافة تكامل الدردشة على مستوى الموقع)، سيتم نشر هذا المحتوى في الموضوع بدلاً من القناة. (ليس “إرسالها أيضاً إلى القناة” — لأن ذلك سيقوض الغرض من التغيير بالنسبة لنا.) كما أن التعليقات الإضافية على ذلك الموضوع الجديد في Discourse ستذهب أيضاً إلى نفس الموضوع على Slack.
وإلى جانب ذلك، وبما أنك طلبت تخمينات، فإن عام 2017 هو العام الذي أطلقت فيه Slack المواضيع؟
فقط watch وليس follow لديه القدرة على اختيار الردود ضمن خيوط نقاش، عبر آلية ما لا يزال عليّ تحديدها. بديلًا عن ذلك، ما رأيك يا @david في إضافة مرشح قاعدة جديد باسم thread مع تسلسل أولوية: mute ثم thread ثم watch ثم follow، وربط هذه القاعدة بـ trigger_notification لتمكين سلوك حساس للقواعد؟
إذا تم تكوين watch لاستخدام الخيوط (أو بديلًا، إذا تم تعريف قاعدة thread)، فعند إرسال إشعار منشور جديد إلى قناة Slack، إذا كان موضوع المنشور يحتوي على ts مرتبط به في Slack، فقم بنشره في ذلك الخيط بوضع thread_ts مساويًا لقيمة ts المقدمة من Slack.
عند إرسال إشعار منشور جديد إلى قناة Slack، وإذا كان موضوع المنشور لا يحتوي على ts مرتبط به، فقم بتخزين قيمة ts المسترجعة من الاستجابة للموضوع (حتى يمكن ربط المنشورات المستقبلية في هذا الموضوع ضمن خيط إذا كان watch مهيأً لاستخدام الخيوط).
عند استخدام أمر post thread :thread_url، قم بتخزين ts الخاص بالخيط في الموضوع الذي يتم إنشاؤه، والذي سيُستخدم فقط من قبل قواعد watch المخصصة للخيوط.
إليك أفكاري ومخاوفاتي الحالية:
كيفية تحديد ما إذا كان يجب النشر ضمن خيوط نقاش على أساس كل قاعدة على حدة. يبدو لي حاليًا أن إضافة مرشح جديد هو الأسهل، لكن ربما أغفلتُ شيئًا ما.
تمرير رابط المنشور الأصلي في Slack ومعرف الخيط عبر تدفق transcript هو ما يبدو لي الأكثر غموضًا حاليًا. يبدو أنني بحاجة فعليًا إلى إضافة معرف خيط خاص بكل مزود خدمة في مكان ما والحفاظ عليه حتى حفظ المنشور. سأقوم بتطبيق ذلك فقط لـ ts الخاص بـ Slack، لكن من المفترض أن هذه ليست التكامل الوحيد للدردشة الذي يدعم الخيوط.
بالنسبة للنشر، أعتقد أنني بحاجة إلى تخزين ts الخاص بـ Slack في حقل مخصص خاص بـ Slack على الكائن Topic، وليس في حقل مخصص عام باسم DiscourseChat.
هل يحتاج حقًا عنصر ‘threading’ المنطقي إلى أن يكون لكل قاعدة؟ لماذا لا نضيف إعداد موقع جديد
chat_integration_slack_thread_responses
إذا تم تمكين هذا، ولدينا سجل لمعرف الخيط الخاص بالموضوع، فإننا نرسل الإشعارات اللاحقة إلى خيط Slack.
نعم، أعتقد أن هذا مقبول تمامًا. ما عليك سوى استخدام حقل مخصص للموضوع خاص بـ Slack. إذا شعرنا بالحاجة إلى تنفيذ هذا لمزودين آخرين في وقت لاحق، يمكننا جعل الحل أكثر عمومية.
نعم، هذا أمر معقد للغاية. كإصدار أولي (v1)، سأميل إلى تضمين شيء مثل
<!--SLACK_THREAD_ID=abcdefg-->
في أعلى المنشور. ثم يمكن للإضافة التحقق من المنشورات التي تبدأ بهذه السلسلة، وتعيين الحقل المخصص. هذا ليس مثاليًا، لكنه قد يكون نقطة انطلاق جيدة؟
الليلة الماضية، قمت بتطبيق واختبار بنجاح أول عمليتين مقبولتين (ACs) عبر كامل المكدس (رغم أنني لم أختبرها على البيئة الحية بعد)، باستثناء تدفق المحادثات المنقولة، وذلك باستخدام حقل مخصص في Topic وقاعدة thread. لذا، أحرز تقدمًا جيدًا نحو القدرة على عرض الكود على الأقل في طلب سحب (PR) مسودة.
لدي أيضًا التزام منفصل لإزالة دالة pstore_get غير المستخدمة من مزود Slack. وبما أن هذا هو الاستخدام الوحيد لـ pstore في كامل المكدس، هل تود أن أقوم بإزالة جميع دوال pstore_* من ملف app/initializers/discourse_chat.rb في نفس التزام التنظيف؟
هذا بالضبط ما بدأت به، وكان سيكون بالتأكيد أسهل!
ومع ذلك، على الأقل في حالة الاستخدام الخاصة بي (وقد سمعت هذا من أشخاص في شركات أخرى، نحن لسنا فريدين)، تفضل القنوات المختلفة استخدام الخيوط (threads) بشكل مختلف. فهناك قنوات مخصصة للاستخدام مع الخيوط (لأن معظم الناس يهتمون فقط ببعض المواضيع)، وقنوات أخرى معادية بشدة للخيوط (لأن الخيوط تُدفن المعلومات المهمة).
لقد رأيت جانبين غير مرتبطين في جوهرهما يقودان هذا التفضيل:
العضوية: القنوات التي يتكون معظم أعضائها من مستخدمين نشطين في IRC لعقود معتادون على التمييز الذهني بين خيوط المحادثات المتداخلة في قناة واحدة ولا يريدون النقر داخل الخيوط لرؤية المحتوى المهم، بينما القنوات التي يتكون معظم أعضائها من أشخاص اعتادوا على البريد الإلكتروني يتوقعون أن تكون المحادثات منظمة في خيوط وأن ينقروا داخل المحادثات التي يهتمون بها.
الغرض: القنوات ذات الغرض التجاري للإعلانات تميل إلى أن تكون منظمة في خيوط بشكل عدواني، لكن القنوات ذات أغراض البحث أو التعاون غالبًا ما تكون غير منظمة في خيوط عمدًا لأن الخيوط تخفي المعلومات ما لم تلاحظها وتنقر داخلها.
إذا كنت ترغب في وجود بناء جملة مشترك لخيارات القاعدة، فأعتقد أنه يمكن توسيع Rule بشكل عام بحيث تحتوي على قيمة :options، تشبه :tags، وهي مصفوفة. ربما يكون من المنطقي الاقتباس من أصداف سطر الأوامر، بحيث /discourse [watch|follow|mute] -something -here يحدد :options إلى ['something', 'here'] — مع حجز بادئة - لإدخال خيار. إذن سيكون الأمر /discourse watch my-category-slug #tagged-foo -threaded. لا أعرف كم من العمل الإضافي سيتطلب ذلك مقارنة بما فعلته بالفعل. هل لديك مشاعر قوية في أي اتجاه هنا؟ أستطيع أن أرى حججًا في كلا الاتجاهين: إضافة قيمة أخرى إلى Rule يجعل كتابة مزود دردشة أكثر تعقيدًا؛ وإضافة قيمة تصفية أخرى تجعل ميزة خاصة بـ Slack (مثل نشر محادثة منقولة) أكثر تعقيدًا في الواجهة لمستخدمي غير Slack. بالطبع قد أكون أغفلت شيئًا يجعل الأمر أصعب مما أعتقد؛ على سبيل المثال، إذا كان يمكن أن يبدأ اسم التصنيف بـ - وسيصبح غامضًا فجأة؛ تستخدم الأصداف -- لتعني “كل شيء بعد هذا ليس حجة” لكن ربما يمكننا عكس ذلك بحيث -- يعني “كل شيء بعد هذا هو خيار”. إذا كنت ترغب مني في البحث في هذا، يرجى إعطائي بعض التوجيه حول بناء الجملة الذي ستجده مناسبًا لتحديد خيارات القاعدة. لكن مجرد إضافة thread يبدو لي أبسط، لذا في غياب توجيه محدد لإضافة ميزة “خيارات” عامة، سأنتظر قبل إجراء أي تغيير في هذا الاتجاه.
[تعديل: الانتقال من مرشح قاعدة إلى خيار سيعقد بالتأكيد واجهة المستخدم التي ستضطر للنمو لدعم عام للخيارات العامة، وهذا لا يبدو لي خيارًا رائعًا. لذا الآن، بعد النظر في واجهة المستخدم، أفضل البقاء مع المرشح؛ أعتقد أنه أنظف.]
بخصوص تدفق المحادثات المنقولة في المنشورات، شكرًا لفكرة تعليق HTML. في حالة الاستخدام الخاصة بي، لن تضرني؛ فأنا أتوقع بصراحة أن أكون المستخدم الأساسي على أي حال، على الأقل في البداية. هذه حيلة بسيطة وجميلة.
لدي فكرة منفصلة، لن يتم تضمينها في هذا طلب السحب (PR)، وهي أنه سيكون من الجميل وجود خريطة من القناة التي يُنشر منها الرسالة إلى التصنيف الذي يجب أن يُنشر فيه منشور Discourse الناتج. لكي يحدث ذلك، أعتقد أن المحادثة المنقولة ستستفيد من تغييرها لتشمل غلافًا أو ملحقًا جانبيًا (sidecar)، وعندها يمكن أن يحتوي الغلاف أو الملحق الجانبي على كل من التصنيف ومعرف Slack. يبدو هذا كمية كبيرة من التعلم بالنسبة لي، إذ لا أزال في مرحلة “البحث المتقدم عن المشكلة” في تعلم Ruby on Rails.
ماذا لو أضفنا إعدادًا آخر باسم cross_post_to_channel_after_hours (افتراضيًا 48 ساعة؟) أو ما شابه، بحيث إذا كان الوقت المنقضي منذ آخر رد أكبر من x ساعة، يتم إرسال المنشور إلى الخيط مع تفعيل خيار “إرسال أيضًا إلى القناة”.
لا تأخذ اقتراحي على محمل الجد الآن إذا كنت ترغب فقط في جعل الأمور تعمل بدون هذه الميزة في البداية (وهي استراتيجية أفضل على الأرجح!). مجرد فكرة للتأمل…
فكرة ليست مجنونة على الإطلاق، لكنني لا أخطط لتنفيذها لأنها ستعطل حالة الاستخدام الرئيسية لدي، وليس لدي أي حاجة لها في أي مكان آخر. مع ذلك، أتفهم تمامًا أن أشخاصًا آخرين قد يرغبون في ذلك!
لو كانت إعدادًا عاديًا بدلاً من خيار خاص بكل قناة، لكان اسمها chat_integration_slack_copy_threads_to_channel_after_hours، وكان من المفترض أن يكون قيمتها الافتراضية 0 (عدم الإرسال)، لكن يمكنك تعيين أي قيمة تريدها. المفهوم بسيط إلى حد كبير، لكنه يتطلب جهدًا أكبر لأنك ستحتاج إلى جلب الخيط (باستخدام الكود المكتوب في الأصل للتعليقات الصوتية، ولا أعرف على الفور ما إذا كان سيتطلب إعادة هيكلة) لاتخاذ قرار بشأن تعيين علم بسيط.
ولكن إذا أردت العمل على ذلك، فأنا آمل أن يكون ما أقوم به إطار عمل جيدًا. أطلب منك فقط ألا تجعله مفعلًا افتراضيًا، لأنه إذا تم تفعيله أثناء الترقية و"قُصف" مستخدموني بمحتوى أقوم أنا بتدوينه لـ Discourse، فسأواجه مستخدمين غير سعداء.
@david لدي مسودة طلب سحب (PR) تمر باختبارات الوحدة كما كتبتها. لم أجرب تشغيلها مباشرة على Slack بعد، لذا لا أود دمجها حتى يتم ذلك. لكن على الأقل جميع اختبارات الوحدة تنجح لدي، وحاولت إضافة اختبارات ذات معنى لها.
كما وضعت تعليق المعرف في النهاية بدلاً من بداية المنشور، لأنني شعرت أنه أكثر عرضة للبقاء وأقل عرضة للتشوه هناك، وحاولت أن أكون حذراً في تحليله.
شكراً لجهودك في هذا الإضافة!
أصلحت أخطاء التحليل الأولية، لكن الآن تفشل اختبارات لم أعدلها. أنا أعمل على أحدث نسخة من الفرع الرئيسي (master)، وتنجح الاختبارات محلياً. هل لديك أي insight حول الاختبارات الفاشلة؟
لقد قمت بتنظيف طلب السحب (PR) بشكل كبير، لكنه ليس جاهزًا للإرسال بعد. لديّ حاليًا من اثنين إلى ثلاثة أشياء تسبب لي مشكلة ولا أعرف بعد كيفية إصلاحها.
أحاول استخدام fa-arrow-circle-o-right كأيقونة للموضوع، وهي تظهر فارغة في واجهة المستخدم على موقعي المباشر. (لقد قمت بتشغيل su discourse -c 'bundle exec rake assets:precompile' && sv restart unicorn بعد سحب فرعتي على موقعي المباشر للاختبار على الخادم المباشر.) لقد أضفتها إلى ملف plugin.rb بالإضافة إلى الإشارة إليها، لذا أنا حائر بشأن الخطوات التالية. هل توجد قائمة بأيقونات FontAwesome المعتمدة للاستخدام في Discourse؟ وجدت lib/svg_sprite/svg_sprite.rb، وchevron-right تبدو رائعة لهذا الغرض.
جميع الاختبارات تنجح لدي محليًا، لكن في Travis أحصل على أخطاء متسقة تبدو غير مرتبطة بتغييراتي، وهذا بطبيعته صعب التحقيق أو التحليل بالنسبة لي. 13 فشلًا مع خطأ 404 بدلاً من بعض الأخطاء المتوقعة الأخرى (مثل 200) في ملف spec/lib/discourse_chat/provider/slack/slack_command_controller_spec.rb تم الإصلاح بعدم استخدام isolate_namespace بشكل عشوائي، والآن أصبحت أعرف عن أمر rake routes.
أقدر مراجعاتك المفيدة جداً! قمت بتحديث منشور ويكي التكامل الرسمي كما وعدت. إذا كنت تفضل ذكر التغييرات بطرق أخرى، فأنا موافق على ذلك، لا يوجد أي غرور أو تملك من جانب المؤلف أو ما شابه.
قمنا بالتحديث إلى نسخة 2.6 بيتا1ا الحالية التي نجحت في الاختبارات قبل بضعة أيام، ولكن حسب ما أستطيع ملاحظته، لم يتم تجميع منشورات Slack عبر الروابط (threaded) منذ الترقية. لا نزال نرى منشورات المواضيع والردود معروضة بشكل فردي في قنوات Slack.
