مرحبًا. أنا أبحث عن بناء ويكي يمكن للمستخدمين التحكم فيه، وأود استخدام Discourse للقيام بذلك. أفضل طريقة أراها للقيام بذلك هي السماح للمستخدمين بإنشاء “صفحة ويكي” عن طريق إنشاء منشور Discourse جديد مُعدّل ليكون صفحة ويكي، وسيكون هذا المنشور الواحد بمثابة صفحة الويكي الكاملة.
*هل هذه بالفعل أفضل طريقة للقيام بذلك؟
على سبيل المثال، هل من المقبول وجود منشور واحد يُحرره العديد من المستخدمين، ويبقى مفتوحًا للتعديل لأسابيع، وينمو ليصبح كبيرًا جدًا (بحجم هذا مثلًا)؟ يبدو أن المنشور الواحد يختلف كثيرًا عن صفحة شبيهة بويكيبيديا كاملة، لذا أريد التأكد من أنه يمكن أن يعمل ويكون مستقرًا.
*أرى أنه يمكنك إضافة جدول محتويات. هل هناك إضافات أخرى يجب أن أستخدمها؟ على سبيل المثال، أعتقد أن Discourse يمكن أن يعمل للربط الشبيه بويكي في عناوين URL، لكنني لست متأكدًا بعد.
بالمناسبة، إليك بعض المنشورات الأخرى التي راجعتها:
كما أرى النقاش الموسع هنا حول إنشاء ويكي—هذا الحوار يعود لسنوات عدة ويبدو أنه يركز على عدة جوانب مختلفة، لذا أقوم بالنشر هنا لطرح هذا السؤال الأكثر تحديدًا.
كما أُشير في أحد المنشورات ضمن موضوع مرتبط، هناك ثلاثة عناصر مفيدة لإنشاء مواضيع ويكي على Discourse.
الأول الذي أشرت إليه (ما هي منشور الويكي؟) يوضح كيفية تحويل منشور عادي إلى منشور ويكي، مما يعني أن أي مستخدم يمتلك مستوى الثقة الصحيح (trust level) يمكنه تحريره.
أما الثالث فلم تذكره تحديدًا، لكنك أشرت إليه، وهو إضافة مستكشف المعرفة، وقد تكون لديك القدرة على تثبيته أو لا، اعتمادًا على خطة الخدمة الخاصة بك أو استضافتك الذاتية.
منذ أشهر عديدة، كان لموقعنا صفحات ويكي في فئة منفصلة، مع صفحات نقاش في فئة ذات صلة. تُحفظ صفحات الويكي في منشور واحد فقط، بينما تعمل صفحات النقاش المقابلة كمواضيع عادية.
في اليوم السابق، وبعد أن تعلمت عن (DiscoTOC - جدول محتويات تلقائي - سمة)، أضفتها إلى بعض الصفحات وسمحت للمستخدمين الذين لديهم مستوى ثقة 3 أو أعلى باستخدامها.
يبدو أن منشورًا واحدًا مختلفًا جدًا عن صفحة كاملة تشبه ويكيبيديا، لذا أريد التأكد من إمكانية عملها واستقرارها.
إنها تعمل على موقعنا وهي مستقرة. كما أشرت، يتم نقل المناقشات إلى منشور نقاش مقابِل، وبما أن لدي حقوق المسؤول على الموقع، يمكنني نقل أي ردود إلى منشور النقاش. لقد جربت بعض الأمور لتقييد الردود لكنني لم أكن راضيًا عن النتيجة؛ أنا منفتح على الاقتراحات.
السبب الرئيسي لاستقرارها هو أن معظم المستخدمين على موقعنا لا يساهمون في صفحات الويكي. وأرى نفس الشيء في StackOverflow حيث يفضل الكثيرون ترك تعليق حول تعديل مطلوب بدلاً من إجراء التعديل مباشرة. كما أنه من الجيد معرفة أن جميع منشورات Discourse تحتفظ بسجل تعديلات ويمكن التراجع عنها.
هناك نقطة أخرى تتعلق بصفحات الويكي أراها بشكل مختلف عن الكثيرين، وهي أنه لا يشترط أن تبدأ نظيفة. أحد أكثر مواضيعنا شعبيةً والأكثر تعليقًا عليه حاليًا، وقد ظل كذلك لعدة أشهر، هو مجرد مجموعة متنامية من الروابط والاقتباسات والتعليقات وما إلى ذلك. الفكرة هي أنه كلما تم اكتشاف شيء متعلق بالموضوع (صندوق أدوات البحث عن الأخطاء)، يتم إضافته إلى منشور الويكي حتى لا يُنسى.
وصل الآن إلى قائمة كبيرة الحجم، ويحتاج الآن إلى إعادة تنسيق وإضافة المزيد من التفاصيل والأمثلة العملية. تمنحنا سمة جدول المحتويات القدرة على اتخاذ الخطوة التالية وتنظيم المعلومات بسهولة أكبر للعثور على شيء ما أسرع من قراءة المنشور بالكامل.
أتساءل عما إذا كان ذلك سيتحسن إذا تم إخفاء اسم المستخدم الذي نشر المنشور أولًا في منشورات الويكي. أشعر بعدم الارتياح عند تعديل منشور شخص آخر عندما يكون اسمه مرتبطًا به.
بصفتي مسؤولًا، لا يمكنني استخدام واجهة المسؤول الرسومية لإنشاء مستخدم فقط. يبدو أن ذلك ممكن من خلال وحدة التحكم، للأسف لا أملك هذه الصلاحية لذا اتبعت الطريقة التقليدية. كيفية إضافة مستخدم يدويًا في discourse؟
إليك بعض النصائح العملية من محرر ويكي بخبرة عدة سنوات: لا توجد ويكي تناسب الجميع، لذا يجب عليك شرحها في مكان ما. في المكان الذي تشرحه فيه، شجّع على السلوك الذي ترغب به.
التعاون يتطلب تقنيّة يدوية، ويشمل ذلك التشجيع. بالنسبة لمنصة Discourse، أشجّع المستخدمين على أن يكونوا جريئين وإجراء التعديلات لأننا نستطيع دائمًا إصلاح أي شيء، ولكن من المقبول تمامًا أيضًا مناقشة التغييرات في موضوع ما. ثم، إذا توصلنا إلى تعديلات واضحة، أشجّع الأفراد على إجراء التغييرات الفعلية.
قليل من المساعدة اليدوية يقطع شوطًا طويلاً مع مستخدمي الويكيات. ^_~
شكرًا لجميع الردود هنا. إذن، فيما يتعلق بالسؤال عما إذا كان من المقبول أن يتحول منشور واحد على Discourse إلى صفحة ويكي كاملة—أي أن يصبح طويلاً جدًا، ويساهم فيه العديد من المستخدمين، ويبقى مفتوحًا لفترة طويلة—يبدو أن ذلك مقبول، أليس كذلك؟
يوجد حد أقصى لعدد الأحرف في المنشور يبلغ 32000 حرف. كما أنه إذا كنت تستخدم DiscoTOC مع الصفحة وكانت طويلة، فتوقع أن يستغرق إنشاء جدول المحتويات بضع ثوانٍ.
شكرًا لك، فهذا هو نوع التفاصيل الدقيق الذي يُعد مفيدًا جدًا للاستماع إليه. لم أكن على علم بهذه القيود، وهي خطيرة جدًا بالنسبة لحالة الاستخدام الخاصة بي.
هل توجد مشاكل تقنية أخرى قد أواجهها عند محاولة السماح للمستخدمين بنشر مقالات طويلة على شكل صفحات ويكي؟
على الرغم من أن هذا ليس مشكلة تقنية، إلا أنه إذا بدأت في اقتراح ميزات ترغب في إضافتها لمنشورات الويكي، فستواجه حالات استخدام منصة Discourse، مثل تحسين الويكي – تقسيم المحتوى إلى أقسام متعددة؟
شكرًا لك. نعم، هذا على الأرجح هو القلق الجوهري. فـ Discourse يحتوي على الكثير من المزايا: واجهة نظيفة، وظائف رائعة كثيرة، سهولة التطبيق، وما إلى ذلك. لكن في النهاية، هو مخصص للمنتديات وليس لمقالات الويكي. لذا، حتى لو وجدت حلولًا بديلة تقترب من وظائف الويكي، فإن القلق قائم من أن محاولة استخدام Discourse لإنشاء ويكي ذات محتوى غني ومتنامٍ ستؤدي إلى محاولة دائمة لإجبار الأمور على التوافق مع Discourse وهو لم يُبنَ لهذا الغرض في الأساس.
سأفكر في الأمر، وسأكون شخصيًا متحمسًا جدًا لو توفرت وظائف ويكي كاملة في Discourse، لكني أميل إلى البحث عن حل ويكي كامل لبناء ويكي.
إذا شاهدت العروض التقديمية بالفيديو التي قدمها جيف، فستلاحظ أنه شخص يستمع ومنفتح على التغيير، لكن يجب أن تقدم حجة مقنعة جدًا. هذه طريقة قد لا تكون قد فكرت فيها من قبل.
هذه هي القيمة الافتراضية، ولكن يمكنك تغييرها بسهولة عبر إعدادات الموقع إذا لزم الأمر.
“بضع ثوانٍ” فترة طويلة جدًا، ولا ينبغي أن يحدث ذلك أبدًا.
يجب أن يتم إنشاء جدول المحتويات باستخدام هذا المكون بشكل فوري. إذا استغرق ذلك وقتًا طويلاً، فهذا يعني وجود مشكلة، ويمكنني إصلاحها إذا شاركت المزيد من التفاصيل حول متى يحدث ذلك.
لذا سيكون من المفيد الاستماع إلى الفريق بشأن هذا الأمر: هل تتوقعون أن يعمل استخدام Discourse لإنشاء موقع ويكي بشكل جيد؟ الطريقة المقترحة هي السماح للمستخدمين بإنشاء “صفحات ويكي”، وذلك من خلال إنشاء مشاركات مُعدَّة كصفحات ويكي.
(السبب في تجربة هذا النهج بدلاً من استخدام أداة ويكي كاملة مثل MediaWiki هو أن Discourse سهل الاستخدام بشكل عام، ويبدو رائعًا، وما إلى ذلك.)
هل قرأت 32,000 حرف؟ لا أعتبر ذلك “محدودية” بحد ذاتها.
صفحة تتراوح بين 30 كيلوبايت و50 كيلوبايت من النص المقروء، والتي تتوافق تقريبًا مع 4,000 إلى 10,000 كلمة، تستغرق بين 30 و40 دقيقة للقراءة بالسرعة المتوسطة
أعتقد أن الأمر يعتمد على حجم هذه “الويكي”. إذا كانت مشاريع خفيفة وبسيطة تمزج بحرية مع بعض النقاش، فمن المحتمل أن يكون ذلك مقبولاً. أما إذا كانت روايات ضخمة تتألف من مليون كلمة في محاولة لإعادة بناء ويكيبيديا من الصفر، فمن المرجح ألا يكون ذلك مناسباً.
ها. سنضع المشكلة المحتملة المتمثلة في “المخطوطات الضخمة التي تتكون من مليون كلمة” في فئة المشكلات من نوع “سنتعامل مع ذلك عندما نصل إلى ذلك”… إذن، ليست منشورات ضخمة، بل ربما منشورات بطول “متوسط” مشابه لويكيبيديا، مثل هذه الصفحة.
من الأساسيات التي أستطيع رؤيتها—القدرة على السماح للمستخدمين بإنشاء منشورات بأسلوب ويكي، وإضافة فهرس المحتويات، والقدرة الأساسية على ربط الروابط في المنشورات العادية—يبدو أن الأمر قد ينجح.
بما أنني جديد على نظام Discourse، فمن الصعب معرفة ما إذا كانت هناك مشاكل غير متوقعة قد تظهر عند بناء موقع بأسلوب ويكي—ليس ويكيبيديا كاملة، بل موقع يشبه ويكيبيديا ويركز على مجموعة محددة من المواضيع—باستخدام Discourse، مما قد يجعل من الأفضل البدء مباشرةً باستخدام برمجيات مخصصة للويكي مثل MediaWiki.
أدرك أن الاختبار الحقيقي سيكون في النهاية عندما أغوص في التطبيق العملي، لكن هذه التعليقات مفيدة جدًا لتحديد نقطة البداية.
إليك طريقة ممكنة مع تعديل على “تطوير إضافة لـ ديسكورد لتوسيع وظائف الويكي”، ولكن بدلاً من إضافة، قد يكون ذلك قابلاً للتنفيذ باستخدام سمة (Theme) لأن السمة ليست سوى جافا سكريبت و CSS.
فقط أفكر بصوت عالٍ، ولكن هل من الممكن استخدام سمة مثل DiscoTOC أو ما شابه لإضافة رابط [تحرير] في نهاية كل قسم، والذي عند النقر عليه يأخذ القسم، ويرسله إلى محرر ويكي ميديا، وعند الانتهاء من التغييرات يقوم بتحديث منشور ديسكورد. وبذلك يتمكن ديسكورد من تجاوز مشكلة الحاجة إلى إنشاء محرر ويكي، مع الاستفادة من الجاذبية والتسويقية لامتلاك صفحات ويكي أفضل.
من الجيد أن ديسكورد لا يحتوي على أصوات سلبية، وإلا لما عرضت هذا كإجابة على StackOverflow.
