أعتقد أن الوقت قد حان لكي يوفر Discourse طريقة أسرع لإنشاء روابط إلى مواضيع أخرى في منتدى معين. بالطبع، يوجد زر الرابط والاختصار الموجودان في المحرر، وإذا كنت بارعًا حقًا وعرفت عنوان URL الدقيق للموضوع، فيمكنك حتى القيام بذلك دون استخدام نافذة الحوار الخاصة بالروابط. ولكن هناك تطبيقات أخرى تُظهر أنه يمكن أن يكون هناك طريقة أفضل وأسرع وأسهل: استدعاء نافذة حوار بحث وروابط مضمنة.
هناك سابقة لذلك في Discourse مع سلوك الرابط/البحث باستخدام @ للملفات الشخصية، وكذلك سلوك الرابط/البحث باستخدام # للوسوم (#hashtags). لذا، أقترح ببساطة إضافة خاصية البحث والربط للمواضيع. سيكون هذا النهج بسيطًا للغاية، يشبه إلى حد كبير بحث المستخدمين باستخدام @، مع نافذة منبثقة سريعة للبحث في عناوين المواضيع مبنية على النص الذي تكتبه داخل المحرر، ولن يحتوي على أي حقول للعنوان أو أي عناصر تحكم أخرى. سيعمل تمامًا مثل بحث @ ولكن للروابط. ستستخدم لوحة المفاتيح لتأكيد الرابط، وسيتم تمييز الخيار الأول تلقائيًا.
إحدى الصيغ التي أصبحت شائعة مؤخرًا لهذا الغرض هي “روابط الأقواس”، أي [[رابط-إلى-الموضوع]]. عندما تكتب [[، يتم استدعاء بحث في عناوين المواضيع، تمامًا مثل بحث المستخدمين أو الوسوم. ومن النهج الشائعة الأخرى قائمة الشريط / (slash menu)، على الرغم من أنها تُستخدم عادةً لوظائف متعددة. بصرف النظر عن طريقة الاستدعاء، فإن هذا سيجعل إنشاء الروابط بين المواضيع سريعًا وسهلًا للغاية، وهو ما أراه شخصيًا أمرًا إيجابيًا لأنه يشجع الناس على الإشارة إلى محتوى آخر موجود ومرتبط.
المشكلة الرئيسية التي أراها مع هذه الصيغة تحديدًا هي أنها تختلف عن صيغة الويكي المدعومة حاليًا، ولكنها أيضًا مشابهة لها. ومع ذلك، فإن صيغة روابط الويكي تُستخدم فعليًا في أنظمة تدعم أيضًا صيغة القوس المزدوج []]، ولكن تحديدًا للروابط التي تحتاج إلى نص مخصص. لذا، فإن أحد الخيارات هو استخدام نفس التمييز: الأقواس المزدوجة لروابط الموضوع التي تستخدم عنوان الموضوع كنص الرابط، أو رابط ويكي تقليدي لعنوان مخصص. والخيار الآخر هو تغيير صيغة الروابط بشكل عام، وهو أمر أشك في أنه سيكون جذابًا. والخيار الثالث هو اختيار صيغة رابط مضمنة أخرى، أي مجموعة مختلفة من الأحرف تستدعي بحث الروابط.
لا يهمني حقًا كيفية تنفيذ ذلك بالضبط، أنا فقط أريد أن أتمكن من البحث والربط بشكل مضمن! أعتقد أنه سيكون إضافة رائعة لمحرر Discourse الممتاز بالفعل ولميزات الراحة العامة.
ومع ذلك، أدرك أن وظائف المحرر الحالية جيدة جدًا، وأن هذه مجرد ميزة راحة، يمكن القول إنها مخصصة لمجموعة معينة من المستخدمين. إنها بالتأكيد ذات أولوية منخفضة حتى لو كان هناك اتفاق على أنها ستكون مفيدة.
يوجد شيء مشابه عند تحديد الرسائل ونقلها إلى موضوع جديد/موجود. وبصراحة، الوضع الحالي مزعج للغاية:
البحث يستغرق وقتًا طويلاً
حتى لو عرفت عنوان الموضوع وكتبته تمامًا كما هو مكتوب (مع مراعاة الأحرف الكبيرة والصغيرة وما إلى ذلك)، فإن البحث لا يجد الموضوع الذي تريده
عندما يجد البحث الموضوع وتحدده، يستمر البحث قبل أن تتاح لك حتى فرصة تأكيد اختيارك. يختفي اختيارك، ولا يظهر الموضوع الذي حددته حتى في قائمة البحث بعد ذلك
تجربتي عكس ذلك تمامًا، انظر ما سبق.
أنا أسرع في العثور على الموضوع الصحيح عندما أستخدم وظيفة البحث القياسية.
عنوان الموضوع غير فريد، لذا عند البحث عن موضوع، ستظهر معلومات إضافية مثل الوسوم والفئات للمساعدة في تمييزه، لكن العرض المضمن قد يكون مزدحمًا جدًا، وأحيانًا يتطابق عدد كبير من المواضيع مع بحثك مما يجعل التصفية داخل النص صعبة.
نقطة أخرى:
عند استخدام هذه اللوحة لإدراج رابط، يجب تأكيد اختيارك بنقرة زر، وهو ما أراه مفيدًا جدًا.
يبدو كل هذا نتيجة لفشل في واجهة المستخدم/تجربة المستخدم أو وظائف البحث، وليس مشكلة في فكرة الارتباط المضمن بحد ذاتها. إذا لم تكن قد قمت بذلك بالفعل، فإنني أقترح عليك فتح موضوع لمناقشة التحسينات/الإصلاحات لسلوك “نقل المنشورات/دمجها” الحالي، بالنظر إلى التجارب التي تصفها. ولكن بافتراض أن هذه الأنواع من المشاكل لم تحدث في سياق نهج الارتباط المقترح مني، هل ستجده مفيدًا حينها؟
لماذا تفترض أن البحث المضمن سيعمل بشكل مختلف عن البحث القائم على شريط الأدوات؟ من حيث سلوك البحث والعرض، يجب أن يعمل بالضبط بنفس الطريقة، وبالتالي سيكون له نفس المستوى من السهولة والفائدة من حيث العثور على الموضوع الصحيح واختياره. تفضيلي هو أن يختلف عن نافذة الارتباط الحالية ويركز على السرعة وسهولة الاستخدام، ويعمل بشكل مشابه جدًا لوظيفة البحث @ الحالية التي تظهر قائمة صغيرة بالنتائج السياقية. يمكن أن تبدو قائمة النتائج تمامًا مثل القائمة في نافذة الارتباط، لكنني لا أريد حقل عنوان موضوع أو زر موافق/إلغاء، إلخ. هناك بالفعل اختصار يستدعي ذلك.
لا أعرف حقًا لماذا سيكون هناك المزيد من الروابط المكسورة. لا تزال بحاجة إلى الضغط على Enter لتأكيد الموضوع الذي اخترته من البحث.
حسنًا، بالتأكيد ليست “أسرع”. قد تكون أكثر ودية للمستخدم، بالتأكيد، لكن اقتراحي ليس استبدال الارتباط الحالي القائم على شريط الأدوات، بل مجرد إضافة طريقة أسرع للارتباط للمستخدمين الأكثر خبرة.
أعتقد أن Ctrl-K (الاختصار) بديل جيد ويوجد بالفعل، بالطبع. أنا فقط أحب القدرة على استخدام بناء الجملة المضمن لتحفيز أشياء مفيدة، وهو شيء تتبناه منصة Discourse موجودًا بالفعل مع @ و # . يمكن الوصول إلى كل من هذين الأمرين أيضًا عبر اختصارات لوحة المفاتيح أو الكتابة اليدوية دون بحث، ولكن بالطبع هناك قيمة مضافة في كيفية عملهما الآن. أقترح أن قد يكتسب الارتباط قيمة مماثلة بهذا النهج.
أوه، هذا مثير للاهتمام وجيد أن نعرفه! ومع ذلك، أعتقد أن هناك فرقًا قيمًا بين “الإجراء من خلال بناء الجملة المضمنة” و"الإجراء عبر أمر لوحة المفاتيح". من ناحية، هناك قابلية الاكتشاف، ومن ناحية أخرى، السرعة.
صحيح أنه بمجرد تعلمك، يكون استخدام هذا التسلسل سريعًا بشكل معقول، لكنني جربته عدة مرات للتأكد، وقد شعرت أنه أبطأ وأقل سلاسة مقارنة بتجربتي في التطبيقات (التي تزداد عددًا) التي تدعم ربط الأقواس []. ربما يكون ذلك جزئيًا بسبب الحاجة إلى تحويل الانتباه/النظر، بالإضافة إلى اختصار لوحة المفاتيح الجديد والقليل من الغرابة. قد يُتغلب على الأخير بمرور الوقت (رغم أن هندسة يدي الأساسية تفرض بعض القيود على هذا الاحتمال)، لكن تحويل الانتباه سيظل دائمًا له تكلفة أثناء كتابة الرسالة.
من المثير للاهتمام بالنسبة لي أنك شعرت برغبة كافية في الربط السريع لإنشاء هذا التسلسل غير العادي من اختصارات لوحة المفاتيح (لا شك لأن العديد من المستخدمين استخدموه). وهذا يشير لي إلى أنك قد ترى بعض القيمة في فكرة الربط المضمن بشكل عام… لكنني أعتقد أن هناك القليل من الدعم لاقتراحي حاليًا. مع ذلك، أنا فضولي لمعرفة ما إذا كانت هناك عوائق واضحة تمنع ذلك، مثل “نحن نستخدم الأقواس لشيء آخر”، أو “لا يمكننا إضافة معالج مضمن آخر لأنه سيُبطئ جميع استعلامات قاعدة البيانات بنسبة 30%” أو ما شابه.
على أي حال، آمل أن يكون هذا قد أثار اهتمام شخص ما على الأقل. لا يزال لدي رغبة شديدة في توفر هذه الميزة، وأتخيل أنه بمجرد أن تتاح الفرصة لمستخدمين آخرين لتجربتها، قد يحبونها هم أيضًا (هل يوجد مستخدمون لـ Roam هنا؟ أم لـ Obsidian؟ أو لـ Logseq؟). لكن على الأقل، آمل أن يكون قد أثار اهتمامًا بفكرة البحث والربط المضمن، وربما يتبلور شيء ما حول ذلك في المستقبل.
هذا جيد أن تعرف! بصفتي شخصًا غير مبرمج، لا أعرف حقًا مقدار ما هو ممكن في مكونات السمات (الكثير يبدو، وهو أحد الأشياء العديدة التي أحبها في Discourse). لذا فهذا رائع حقًا.
من الصحيح أنه في برمجيات أخرى، يُحتفظ بـ [[ ويحتفظ ببعض القيمة حتى بعد إضافة الرابط. أو بالأحرى يجب أن أقول، أن بحث [[ لا يملأ تلقائيًا رابطًا تقليديًا، بل مرجعًا داخليًا متخصصًا. وبما أن تطبيقات متعددة تدعم تنسيق المرجع هذا، فهو قابل للنقل في نسخة من Markdown، لذا فهو مفيد جدًا.
لكن على أي حال، في حالة Discourse، فإن [[ هو مجرد اختصار مألوف مدمج في النص، يحدث بالصدفة أن يكون من غير المرجح أن يُفعّل بالخطأ. سأكون سعيدًا بأي طريقة أخرى تعتمد على النص لاستدعاء البحث المدمج في النص والتي تلبي معايير مماثلة، ولكن رغم الاختلافات في كيفية عملها في Discourse مقابل، على سبيل المثال، Roam، أرى بالفعل بعض القيمة في أن يكون بناء الجملة نفسه على الأقل. كما قلت، إنه إلى حد ما معيار فعلي متنامٍ.
الشيء الآخر الذي يخطر ببالي هو أن Discourse لديها بالفعل ما يعادل الروابط الداخلية التي يتم عرضها بطرق خاصة: إنه طريقة عمل الاقتباس! لذا فإن “post:10, topic:200454” سترتبط بالطبع بردك لي هنا. نظرًا لأن وظيفة هذا الرابط مخصصة تحديدًا للمواضيع الداخلية، يمكن ببساطة استخدامها وعرضها تلقائيًا كرابط للموضوع وقت العرض. لا أستطيع أن أقرر ما إذا كان هذا أكثر توافقًا مع طريقة عمل Discourse، أم أقل…
من ناحية، هناك بالفعل هذه الطريقة للربط، وهذا سيكون مجرد طريقة مختلفة لاستدعاء بحث الرابط واختياره، وهو مشابه جدًا لعمليات البحث الحالية بـ @ و # كما ذكرت. من ناحية أخرى، فإنه يختلف عن سلوك الربط الحالي الذي يتم استدعاؤه عبر Ctrl+K وشريط الأدوات والاختصارات الأخرى. أعتقد، مع ذلك، أن نوع الرابط “post:10” أكثر تشابهًا مع مفهوم الرابط [[ المستخدم في تطبيقات أخرى، لذا أميل قليلاً إلى ذلك… إذا كان لي أي وزن في الأمر. أنا أعلم بالطبع أن هذا هو مجال مكونات السمات على أي حال، لذا ربما يكون لي! ربما يمكنك فقط إبداء الرأي حول ما إذا كان يمكن تنفيذ الربط بنمط “post:10” من خلال بحث منبثق في مكون سمة؟
لقد ذكر @codinghorror عدة مرات في الماضي أنه قلق للغاية بشأن مدى عدم فعالية البحث المضمن عند استخدام المحرر، على الرغم من أنني أعتقد أنه في سياق التوثيق والفئات المحددة حيث تكون النطاقات أضيق، قد يكون ذلك مفيدًا.
لقد أجرينا مناقشات في الماضي حول إدخال صيغة من نوع #784 والتي تشبه إلى حد كبير هذه المناقشة.
طريقة عمل Roam:
تكتب [[
يقوم بإضافة ]] سحرياً ويضع المؤشر في الداخل.
أثناء الكتابة داخل [[ ]]، يقوم بتنفيذ بحث تلقائي للإكمال. على سبيل المثال:
عندما تقرر في النهاية الرابط، يستخدم العنوان الكامل مثل: [[13 أغسطس 2021]]
يتعامل مع إعادة تسمية المستند الأصلي تلقائيًا عن طريق تحديث التنسيق في المستندات المرتبطة.
أي شيء مشابه لهذا السلوك سيتطلب إضافة (plugin) واسعة النطاق إلى Discourse، تربط بين النقاط التي يتم فيها إعادة تسمية المواضيع، ومحرك Markdown وغيرها. سأضع هذا في فئة العمل المعقد الذي يستغرق عدة أسابيع.
حاليًا لدينا:
CTRL+SHIFT+F + A … والذي رغم كونه غير مريح إلا أنه يعمل
حسنًا، هنا يبدأ مثال استخدامي لـ Roam في الانهيار إذا أُخذ حرفيًا جدًا. في الواقع، توقفت عن استخدام Roam منذ فترة طويلة، جزئيًا لأن البحث المضمن فيها فظيع تمامًا. يُعد Obsidian مثالًا أفضل وهو ما أستخدمه بدوام كامل الآن، لكنه يتطلب تنزيلًا لتجربته، بينما لا يتطلب ذلك Roam (أو Logseq).
قبل أن أتقدم أكثر، شكرًا لك @sam على تفاعلك الكبير مع هذه الفكرة، التي أدرك أنها قد تبدو غريبة بعض الشيء. وخاصةً على تزويدي بتقدير تقريبي للعمل الذي تعتقد أنه قد يستغرقه، على الأقل بالطريقة التي وصفت بها عملها.
ومع ذلك، أود التأكيد على أن اقتراحي مستوحى من Roam وتطبيقات مماثلة تستخدم هذا الصياغة، لكنني لست مهتمًا بمحاولة نسخ كل شيء حول كيفية عملها تمامًا.
لا يحتاج إلى إكمال القوس تلقائيًا لأن القوس لن يُحتفظ به في تنسيق Markdown الناتج (في Roam يُحتفظ به، وكذلك في Obsidian)
بحث Discourse، كما يتجلى في بحث الروابط عبر Ctrl-K أو Ctrl-Alt-F، أفضل من Roam، وإذا تم تنفيذه مضمنًا، فسيسمح لي على الأرجح بإيجاد موضوع ذي اهتمام في فترة زمنية معقولة (أي إذا كنت تعتقد أن البحث مفيد على الإطلاق، فسيكون ذلك كافياً لتلبية الحاجة الموصوفة هنا كما هي)
الرابط سيستخدم العنوان الكامل، تمامًا كما لو قمت بنسخ/لصق رابط لموضوع في Discourse داخل نفس المنتدى في رسالة
إعادة التسمية ستُدار بالطريقة التي يتعامل بها Discourse بالفعل مع الروابط الداخلية
لذا، باختصار، Roam مجرد مثال لتوضيح المفهوم وجزء من تجربة المستخدم. ما أقترحه حقًا هو:
مجموعة من الأحرف غير الشائعة ولكن يمكن كتابتها بسرعة لتفعيل بحث موضوع مضمن
بحث موضوع مضمن مع زر Enter لتحديد النتيجة الأولى تلقائيًا
معالجة روابط Discourse العادية في جميع الجوانب الأخرى
التنفيذ بأي طريقة تتوافق أكثر مع نهج Discourse في الأمور
باقي ما قلته مجرد تأملات حول ما قد يكون الأكثر منطقية أو الطرق الممكنة لحل المشكلة.
لذا، مع كل ذلك في الاعتبار، هل يغير ذلك تقدير العمل المطلوب؟ إذا لم يكن كذلك، فما بالضبط في طلب الميزة الذي يجعله أكثر تعقيدًا من مثلاً Ctrl-Alt-F + A؟ أسأل لأن ذلك قد يساعدني على فهم ما إذا كان بإمكاني تضييق نطاق الطلب لجعل التكاليف معقولة، أو إذا كان الأمر ببساطة لا يستحق الوقت المطلوب.
بالنسبة لي، كلما قلّت توافقية Discourse مع Markdown العادي، زادت صعوبة بعض الأمور الأخرى، مثل نقل المحتوى بين Discourse وبين أدوات أخرى تستخدم Markdown. (مواقعنا ومستنداتنا تستخدم عادةً Markdown أو MDX.)
إذا تم إضافة ميزة من هذا النوع، فإن فكرة بديلة للتنفيذ قد تكون استخدام نظام مشابه لـ Confluence أو Notion حيث يفتح حرف / (الشرطة المائلة) قائمة.
إذا وُجدت ميزة مماثلة في Discourse، فقد تفتح الشرطة المائلة قائمة تتضمن خيار “رابط”. وعند اختيار “رابط”، يمكن للمستخدم البحث عن مشاركات أخرى، وسيتم إدراج رابط Markdown عادي في المحرر.
أنا لا أطلب إضافة هذه الميزة، بل أذكر فقط فكرة بديلة للتنفيذ لن تؤدي إلى ابتعاد محتوى raw أكثر عن Markdown العادي.
إذا حافظت على العناصر ضمن الهياكل الموجودة، فإن مكون السمة يمكن أن يعمل بشكل جيد تمامًا، ولن يكون مقدار العمل هائلاً. في الواقع، الرمز [[ مفيد من حيث التنفيذ لأنه يمنحك نقطة ارتكاز واضحة حيث يتوقف التكميل التلقائي.
مثال كامل على سير العمل قد يكون:
يكتب المستخدم: [[
يكمل المحرر ]]، ويوضع المؤشر بين القوسين.
يكتب المستخدم مصطلح البحث، مثل: [[موضوع مضمن]]
أثناء الكتابة، يتم إجراء البحث وعرض النتائج في قائمة تكميل تلقائي مشابهة لـ @الإشارات.
اضغط على السهم للأعلى/لأسفل أو Enter للاختيار.
بمجرد الاختيار، يتم استبدال [[موضوع مضمن]] بالرابط https://meta.discourse.org/t/in-line-topic-search-and-linking-e-g-roam-like-bracket-links/200454.
إذا نقل المستخدم المؤشر ببساطة بعد ]]، فإن التكميل التلقائي يُغلق، ويبقى [[موضوع مضمن]] كما هو في التنسيق.
بشكل عام، بناء شيء مثل هذا ممكن تمامًا باستخدام مكون سمة، ولا يتطلب أي تعديل على جانب الخادم، وسيكون بناءه مباشرًا إلى حد كبير. أقول إن خبيرًا يمكنه إنجاز شيء ما في يوم أو يومين، بينما قد يستغرق الأمر شخصًا متوسط المهارة أسبوعًا تقريبًا.
نعم، قوائم الشرط المائلة هي بالتأكيد نهج مثير للاهتمام وممتع أعجبه وأستخدمه في العديد من التطبيقات. أعتقد أنه لم يخطر ببالي كطريقة لتنفيذ ما أريده في هذه الحالة لأن هذا النهج يستلزم مجموعة كاملة من الوظائف التي سيتم استدعاؤها. وبعبارة أخرى، أعتقد أنه سيكون غريبًا/غير متوقع، بالنسبة لأولئك المعتادين على قوائم الشرط المائلة، أن يُستدعى فقط بحث عن الروابط. وفي حين أن وجود العديد من الوظائف الأخرى في قائمة / سيكون بالتأكيد شيئًا أنا مؤيد له، إلا أنه يبدو لي كطلب ميزة أكبر بشكل ملحوظ.
رائع، شكرًا لك على التفكير في هذا الأمر وإعطائي فكرة عن التعقيد ووقت التطوير! هذا مفيد للغاية. سأحتاج إلى التفكير فيما إذا كان بإمكاني تخصيص بعض ماليا لهذا، حيث لدي بعض الطلبات الأخرى التي ربما تكون أكثر أهمية وأحتاج على الأرجح إلى تمويلها للتطوير. والآن بعد أن عرفت المزيد عن اختصارات لوحة المفاتيح، أصبحت هذه الميزة أكثر راحة منها ضرورة على أي حال.
سيكون هذا أكثر إثارة للاهتمام، إذا تم دعم “إنشاء رابط مسمى” عند إضافة الرابط عبر a إلى النص المحدد. أود أن تكون نتيجة هذا الإجراء [النص المحدد](الرابط).
هذا المفهوم لنظام إدارة المعرفة الشخصية + المنتدى هو تفكير تقدمي حقًا وقوي محتمل. إنه ليس “جديدًا” (على سبيل المثال، انظر “Bliki”، من عام 2003) ولكنه ليس بالضرورة كذلك. السياق جديد، وبالتالي الفكرة جديدة. سوق إدارة المعرفة الشخصية ينمو بسرعة كبيرة لأن الجميع يريد شيئًا يشبه ما تصفه، ولكنه غير موجود. ومع ذلك، لا أعتقد أن الروابط الداخلية ستكون الحل الصحيح؛ ميزات “الربط بالمميز” المدمجة في Discourse (كتحسين/تنوع لوظيفة الاقتباس الحالية) ستكون كذلك. يجب أن يوفر زر “مشاركة” الذي يظهر عند تمييز النص داخل منشور رابطًا بالإضافة إلى خيار إنشاء موضوع جديد داخل المنتدى باستخدام الاقتباس (الميزة الأخيرة مخفية على بعد ثلاث نقرات، ولا تعمل بشكل صحيح). ولكن يمكنني أن أرى كيف يمكن أن يكون من المفيد إنشاء روابط داخلية لمواضيع غير موجودة بعد، والتي تصبح بعد ذلك منشورات ويكي عند قيام شخص ما بالنقر عليها وإنشائها.
أعتقد أن “Garden” الخاص بك هو دليل مفهوم رائع، ومحدود إلى حد كبير بكونه تم تجميعه من Discourse (هل تعتقد أنه سيعمل بشكل أفضل كويكي، أو zettelkasten، أو مثيل Circle/Notion؟). يمكن أن تنهار إدارة المعرفة الشخصية المشتركة بسهولة إذا لم يتم التحكم في جودة المنشورات بإحكام: يمكن أن يصبح المحتوى “عميق ولكنه عديم الفائدة” متجذرًا دون طريقة لتمييز جودة المحتوى قبل النقر. تتعامل المنتديات مع إنتاج المعرفة التعاوني المفتوح بشكل أفضل بكثير من أنظمة إدارة المعرفة الشخصية التقليدية. إليك مثال وسيط مثير للاهتمام: لدى LessWrong نظام “مدونة مجتمعية”، وهو في الواقع تفرع من Reddit، ويعمل بشكل رائع لأغراضهم. يسمح لهم بالتخلص من تحدي مطالبة جميع المساهمين بأن يكونوا جيدين فيما يفعلونه منذ البداية؛ مساهمات المستخدم (المنشورات ومجموعات المنشورات الشبيهة بقوائم التشغيل) ليست معيارية (على عكس وجود مقال واحد عادة لكل موضوع على الويكي).
ستكون بعض الأشياء أفضل، ولكن بعضها أسوأ بشكل ملحوظ. أنا بالتأكيد محدود بـ Discourse في بعض الطرق المهمة لأغراضي، ولكن أعتقد أن أحد أهمها هو ببساطة التنقل، والذي يبدو أنه سهل المعالجة نسبيًا إذا كانت الإرادة وبالتالي موارد التطوير موجودة. لدي فكرة سأقترحها (مع بعض التمويل) قريبًا آمل أن تساعد.
أعتقد أيضًا أنه من المفيد التفكير في فكرة توسيع مفهوم المشرف في سياقات توليد المعرفة المحددة ليصبح شيئًا أقرب إلى “المنسق”. يجمع توليد المعرفة الفردي بين أدوار/أنشطة المولد والمنسق. ولكن توليد المعرفة الجماعي ربما يتطلب - أو على الأقل سيستفيد بشكل كبير من - أشخاص موثوقين يكون دورهم أو جزء من تركيزهم هو اقتباس وترويج وتنظيم وصقل وإبراز المحتوى والأفكار وما إلى ذلك التي يولدها الآخرون، وجعلها في متناول أولئك الذين يمكنهم الاستفادة منها. من الناحية النظرية، يمكن أن تكون وظيفة الويكي في Discourse جزءًا من الحل هنا، ولكنها ستحتاج إلى بعض التعديلات.
هناك أيضًا الكثير من الأشياء المثيرة للاهتمام للتفكير فيها فيما يتعلق بتوليد المعرفة التعاوني، و"البستنة الرقمية"، وما إلى ذلك. هل الهدف هو إنتاج مستندات فردية تمثل منظورًا وفهمًا جماعيًا؟ أو تمثيل وجهات نظر متعددة في وقت واحد؟ أو مزيج من الاثنين. يمكنني رؤية العديد من الأساليب الممكنة للتعامل مع هذه الأسئلة وغيرها.
في النهاية، التحدي هو أن CDCK ربما لا يهتم كثيرًا بهذه الاستخدامات لـ Discourse (وهو ما يمكنني فهمه، فائدتها وبالتالي إمكانية تحقيق إيرادات منها لا تزال في مهدها وغير واضحة في هذه المرحلة). وفي الوقت نفسه، فإن عددًا قليلاً من المنصات الأخرى التي تركز على توليد المعرفة، مثل Wikipedia/MediaWiki، لا تعالج جوانب المحادثة والمناقشة بشكل جيد بما فيه الكفاية، وخاصة التفاعل بين الاثنين. في عالم مثالي، يمكن للمناقشات عالية الجودة على مدى فترات طويلة أن تضيف تدريجيًا إلى ناتج مقطر للمعرفة والأفكار ووجهات النظر، بسهولة وسلاسة، مع الحفاظ على الإسناد مع السماح أيضًا بإنتاج “مستند” / قطعة أثرية منسقة ومتسقة يكون من الممتع قراءتها. Wikipedia هي مرة أخرى مثال جيد للنموذج الحالي الذي يعمل، ولكنه غير كامل للغاية وتحتاج إلى أدوات وطرق جديدة لتجاوز مجرد توثيق المعرفة إلى توليد البصيرة فعليًا، واستكشاف أفكار جديدة، وما إلى ذلك.
يمكن استخدام Discourse لهذه الأشياء الآن، بطرق أسهل من غيرها. ولكن يمكن القيام بذلك، فهي تحتوي على معظم ما هو مطلوب…
أنا أعلم بالطبع أن هذا هو مجال مكونات السمات على أي حال، لذا ربما يكون لي! ربما يمكنك فقط إبداء الرأي حول ما إذا كان يمكن تنفيذ الربط بنمط “post:10” من خلال بحث منبثق في مكون سمة؟
