نحن نستخدم Discourse في مكتب صغير. كما ذكر أعلاه، توجد مشكلة المسودات. ربما تعلم أن هناك عادة إنشاء مجلد جديد بسرعة، ثم مجلد جديد (2)، ومستند نصي جديد، ومستند نصي جديد (2)، وملء هذه الملفات بمعلومات مختلفة وعدم إعادة تسميتها أبدًا بعد ذلك.
لاحقًا يتضح أن كتل النص ليس لها مرجع زمني، ولا إصدارات، ولا صور، وأحيانًا لا يتم حفظ بعض الأشياء بسبب عدم وجود حفظ تلقائي.
المعلومات الموجودة في الملفات النصية مختلطة وغير منظمة بشكل سيء. بعد فترة طويلة، هناك فرصة ضئيلة جدًا للعثور على أي شيء في مثل هذه المجلدات. يمكن أن يساعد فهرسة المحتوى أو الذكاء الاصطناعي قليلاً في هذه الحالة، ويؤدي Discourse هذه الوظيفة.
لقد ذكرت العمل الجماعي المكتبي. وهذا يعني أن مسودات الموظفين المحلية الخاصة مقفلة خلف حسابات المستخدمين. بالحديث عن الموظفين الذين يعملون في مهمة تعاونية، لا حاجة لإخفاء مسوداتهم عن بعضهم البعض. على العكس من ذلك، سيكون من الأفضل لو كانت المسودات متاحة للجميع على الفور. تذكر كيف يعمل مطورو البرامج؟ يضعون الكود (وغالباً ما تكون الوثائق ككود) في مستودع مشترك مع التحكم في الإصدارات. وبمجرد أن يقوم كبير المهندسين بفحص التغييرات، تصبح متاحة للجميع في الفرع الرئيسي. في حالة المسودات، لا حاجة لمثل هذا المشرف. لذا هنا يتفوق Discourse.
مشكلة المسودات مع الصور المرتبطة يتم حلها بسهولة بواسطة محررات Markdown (لقد بقيت مع Typora، خاصة عند تحرير الجداول وتحويل الصور base64 بشكل عكسي - لا يقوم أي محرر بإدراج هذا النص من الحافظة). يعتبر Discourse مناسبًا تمامًا كمنصة عمل متزامنة. يمكن تحويل مناقشات الدردشة بسهولة إلى مواضيع أو منشورات. يمكن لنموذج OpenAI أن يلعب دورًا مهمًا في معالجة البيانات، ولكن الخوارزميات المضمنة كافية أيضًا لجعل سلاسل المنتدى تبدو ذات صلة.
نحن نستخدم ميزة البريد الوارد لإرسال النص بسرعة كبريد إلكتروني إلى المنتدى. بهذه الطريقة لا نفقد الأفكار الثمينة دون تشتيت الانتباه بفتح المنتدى نفسه. ثم نستخدم هذه الأفكار في العصف الذهني.
باستخدام الأذونات، من السهل نقل المواضيع من صندوق الرمل إلى الجمهور عندما تكون جاهزة. تسمح مستويات الثقة المرنة لنا بتنظيم الوصول للإدارات المختلفة.
@Ivan_Rapekas إذا كنت أفهم بشكل صحيح، فأنت تستخدم بالفعل Discourse داخل مؤسستك كتطبيق لتدوين الملاحظات التعاونية. هل هذا صحيح؟ أم أنني أسأت الفهم؟
هل هناك أي تحديات ترغب في الإشارة إليها عند استخدام Discourse بهذه الطريقة حاليًا؟ هل هناك أي تغييرات تفكر فيها من شأنها المساعدة في معالجة تلك التحديات؟
ربما هذه هي المشكلة الرئيسية التي تواجهها حاليًا؟
هل فكرت في إنشاء فئة للمسودات حيث يُفهم أن ما هو موجود هناك هو عمل قيد التقدم غير مصقول؟
نعم، لقد استخدمنا Discourse لمدة 3 سنوات. في البداية، كنت الشخص الوحيد الذي يشارك الملاحظات في Discourse. أدركت أنني لا أحتاج إلى استخدام محرر نصوص لإعداد المقالة قبل نشرها. كنت أجيب على نفس الأسئلة من فريق الدعم كل يوم. وأنشأت قاعدة معرفة شخصية.
بعد عام، وظفنا شخصًا استلهم من مقالات Discourse. أصبح أول محرر. كرائد، وسّع التأثير ليشمل الزملاء المجاورين. الآن، يعمل 1/5 من 150 موظفًا بنشاط في Discourse كتابةً وتحريرًا. المواضيع هي من نوع الويكي افتراضيًا مع عدم وجود حد للتعديلات.
في المرة الأولى، كان الفريق مرتبكًا بشأن جداول markdown وعدم القدرة على فهرسة المرفقات.
ثم أدركوا أن النص القابل للتحرير أقوى من ملف PDF المجمّع، على سبيل المثال. لا حاجة للبحث عن الكود المصدري، وطلب الموافقة، وإنشاء ملف ثنائي، وتحميله، وأخيرًا إبلاغ عن التحديث.
أنت تسأل المشكلة الرئيسية هي مشاركة المسودات، أليس كذلك؟ نعم، هذا صحيح. لكنني أعتقد أن المشكلة الجذرية هي اللامبالاة والمسؤولية. في بعض الأحيان يخشون عرض عملهم، لكنهم دائمًا لا يهتمون بكيفية تمكن الآخرين من استخدام ما أنتجوه.
أيضًا، لا يتم تحفيز الأشخاص على فعل شيء علنًا، لأنهم يصبحون شخصًا يُسأل. نقطة أخرى، يناقش أعضاء المنتدى في هذه الحالة خارج المنتدى. يفضلون المراسلة في Skype بدلاً من اقتباس المنشور الأصلي والتحدث في نفس المكان. في رأيي، يفضل الناس دائمًا “المسار السريع” لحل مشاكلهم.
تحديث: نحن لا نقسم الفئات للمسودات والجاهزة للنشر. في بعض الأحيان ننقل مسودة إلى الإعلانات. دعها تكون مقالة نهائية
صوتت بنعم، لأنني أعتقد أن Discourse يجب أن يفعل شيئًا في هذا المجال. تفضيلي سيكون لتطبيق تدوين ملاحظات محلي يتزامن مع نسخة Discourse مشتركة.
لأغراضي، يجب حفظ الملاحظات محليًا كملفات markdown، قابلة للتعديل باستخدام Vim، ومتزامنة بسهولة مع كل من Github و Discourse.
لقد قمت بصياغة تطبيق Obsidian/Discourse CLI العام الماضي. إنه يعمل بشكل جيد بما يكفي كمحاولة أولى. أحب استخدام Obsidian لنظام الملفات كمصدر للحقيقة، ولكن إذا كنت سأفعل ذلك مرة أخرى، فسأترك Obsidian خارج المعادلة وأستخدم قاعدة بيانات SQLite لحفظ الملاحظات المحلية. (سأستخدم أيضًا Go بدلاً من Ruby للتطبيق، فقط لتسهيل تثبيته على الأشخاص.)
حسنًا، إنهم شركة صغيرة، شفافة جدًا، وتقدم خدمات بأسعار معقولة (المزامنة، النشر)، ولديها مجتمع قوي من مطوري المكونات الإضافية والمستخدمين. وبما أن كل شيء يعتمد على ملفات markdown محلية، فلا داعي للقلق بشأن الارتباط بمنصة معينة. أنا أحب المصادر المفتوحة، ولكن هناك مجال للشركات بينها وبين شركات التكنولوجيا الكبرى.
