لدينا مجموعة كبيرة من الأدلة، وأحيانًا يشارك @dax أو @jomaxro دليل howto لم أكن أعرف بوجوده فأكون منبهرًا!
لاحظت أيضًا أن هذا الأمر ينطبق على العديد من المستخدمين الجدد ومديري المجتمعات في Discourse هنا في Meta. لذا، وبهدف حل هذه المشكلة، توصل @justin إلى فكرة رائعة لتجميع أدلة الـ howto لدينا وتوفير نقطة انطلاق أفضل للجميع، ونأمل أن نصل إلى شيء مشابه لـ https://support.teams.discourse.com/docs
هاها نعم، هناك الكثير! من المثالي أن نتمكن من الوصول إلى 6-12 دليلًا تعليميًا لكل فئة، سيكون ذلك رائعًا. نحن لا نبحث عن تصنيف جميعها، بل فقط الأفضل التي قد يبحث عنها الناس.
@osioke – إحدى الطرق للتعامل مع هذا الأمر هي البحث عن أدلة تعليمية الأكثر مشاهدة والتي تتوافق مع هذه الفئات واختيار أفضل 6-12 دليلًا من حيث المشاهدات لوضع العلامات عليها. سيكون ذلك نقطة انطلاق سهلة مقترنة باقتراحات @بنجامين_دي هنا!
جمالية العلامات تكمن في أنه يمكننا تعديلها بسهولة أثناء تقدمنا أيضًا.
حسناً، يمكن أن تحمل مقالات إعداد تسجيل الدخول فئة خاصة بها، وهي مجموعة فرعية من “البداية” لأنها واحدة من أول الأشياء التي ترغب في القيام بها على موقع جديد، إذا كنت ترغب في ذلك من الأساس.
لست متأكدًا مما إذا كان يجب ذكر متعدد المواقع هنا ، أو ربما يمكن أن تأتي مجموعة الإعدادات المتقدمة مع تحذير، ابحث في الميتا! على سبيل المثال، هذا المنشور مفيد جدًا pros-and-cons-of-a-multisite-installation.
صحيح، القائمة مستندة إلى أكثر 20 موضوعًا مشاهدةً، وقد شاركتها لأوضح تفكيري في ترتيبها. إنها ليست القائمة النهائية بأي حال، كان يجب أن أكون أكثر وضوحًا قليلاً
أفترض أن موقع وثائق Discourse للفرق يستخدم Discourse لجميع الوثائق. المشكلة في ذلك لموقع تعليمي حول Discourse حيث يمكن لأي شخص من المجتمع المشاركة هي إدارة الإصدارات وتتبع كل شيء. أنا متأكد من أن استخدام Discourse لهذا الغرض هو الطريقة المفضلة، لكن هل لي أن أقترح ربما موقع Hugo أو موقع Jekyll، بحيث تكون الوثائق ملفات في مستودع GitHub يمكن لأي شخص تقديم طلبات دمج (PRs) إليها. إذا لم يعجبك أي من هذين الخيارين، فهناك العديد من أنظمة توثيق مستودعات GitHub الأخرى المتاحة بأنواع مختلفة.
مجرد معلومة، كنت أعمل ببطء على تنظيف قسم #howto:sysadmin، والتأكد من أن كل منها محدث وذو صلة، ثم نقلها إلى auto-delete-posts-after. يبدو أن معظمها تم تصنيفه هنا على أنه advanced config.
أعتقد أن المواقع المتعددة مدعومة إلى حد كبير لكن يُتوقع أنه إذا سلكْتَ هذا المسار، فستكون لديك معرفة بأن الأمر يتطلب منك المزيد (على سبيل المثال، تحتاج إلى التفكير في معنى أمر rebuild app في سياقات مختلفة). سأقول إنها “متقدمة”، لكنها ليست “متقدمة للغاية للغاية”.
أتفق على أن الفئات من الدرجة الثالثة والمجلدات الفرعية “متقدمة للغاية للغاية”.
آه، نعم. أعتقد أن هذا الأمر مستقر إلى حد كبير الآن (أعتقد أن آخر تغيير كان يتعلق بكيفية معالجة إعادة التوجيه في nginx)، ولدي رابط Multisite Configuration with Let's Encrypt and no reverse proxy - Documentation - Literate Computing Support أعتزم نشره هنا قريبًا جدًا (لقد كتبته واختبرته آخر مرة في 2 ديسمبر 2020). لكن multisite تعني بالتأكيد أنك ستعتمد على نفسك إلى حد كبير. لا أعتقد أن لها معنى إلا إذا كان لديك 3 مواقع على الأقل (ربما 10؟)، لأن معظم الأشخاص الذين يعتقدون أنهم يريدونها يحاولون الاعتماد على خادم واحد بسعة 1 جيجابايت.
ما أجد أنه الأكثر فائدة هو ألا تبذلوا جهدًا أكبر في هيكلة التصنيف (كيفية) بحد ذاته، بل أن تمنحوا هيكلاً أفضل للوثائق.
أقدر حقًا أن يكون المنتدى سلسًا للمستخدمين للنشر. أعتقد أن الأمر الجوهري لذلك هو أن يكون لديك تصنيفات رئيسية جيدة وينشر المستخدمون في التصنيف الصحيح منها. لكن عندما تصبح التصنيفات الفرعية معقدة، وعندما يصبح من المهم للمستخدمين النشر في التصنيف الفرعي الصحيح أو البحث في أي تصنيف فرعي، أجد ذلك مُشتتًا إلى حد ما.
في الوقت الحالي، تقررون عمليًا إعداد المنتدى في الوثائق:
لماذا لا يستخدم الموظفون وسومًا مخصصة للموظفين فقط لتنظيم وهيكلة الوثائق، مثل ‘docs-getting-started’، ‘docs-setup’ - مع محتوى من أي مكان في المنتدى؟ ثم يمكنكم إعداد صفحة وثائق تكون أكثر من مجرد مرآة للمنتدى، بل تحتوي على جدول محتويات منسق بعناية، مثل:
هذه هي الفكرة بالفعل، @manuel! نخطط لإنشاء طرق لتصفية هذه الأنواع من الأدلة التوجيهية بسهولة، مع الاحتفاظ بالمرشحات الموجودة بالفعل في مكون Docs. إن تنظيم هذه الأدلة التوجيهية في وسوم محددة هو الخطوة الأولى للبدء.
، أو ربما يمكن أن تأتي مجموعة الإعدادات المتقدمة مع تحذير، ابحث في الميتا! على سبيل المثال، هذا المنشور مفيد جدًا 
)، و 
.
