بناء موقع مشروع مفتوح المصدر بمساهمة المجتمع

وضّح غرض الموقع والجمهور المستهدف

قبل أن تختار قالبًا أو تصمم الصفحة الرئيسية، كن محددًا بشأن هدف الموقع. غالبًا ما تحاول مواقع المشاريع مفتوحة المصدر أن تكون كل شيء في آن واحد—بوابة وثائق، صفحة تسويقية، محور مجتمع، مدونة، قنوات تبرع—فتنتهي بعدم أداء أيٍ منها بشكل جيد.

حدد الأهداف الرئيسية

دوّن 1–3 مهام عليا يجب أن ينجزها الموقع. أمثلة شائعة:

• الوثائق: مساعدة المستخدمين على النجاح بسرعة (التثبيت، البرامج التعليمية، مرجع الـ API).
• التنزيلات: إظهار مكان الحصول على الإصدارات، الحزم، أو الحاويات.
• المجتمع: توضيح كيفية طرح الأسئلة، الانضمام إلى الدردشة، العثور على قضايا، أو حضور الاجتماعات.
• التحديثات: نشر ملاحظات الإصدار، الإعلانات، وتغييرات خارطة الطريق.

إذا لم تستطع شرح غرض الموقع في جملة واحدة، لن يستطيع الزائرون فعل ذلك أيضًا.

حدّد الجماهير (وماذا يحتاجون)

اكتب جماهيرك الرئيسية و"النقرة الأولى" التي تريدها من كل مجموعة:

• المستخدمون يريدون بدءًا سريعًا، استكشاف أخطاء، ووثائق مخصّصة للإصدار.
• المساهمون يريدون خطوات مساهمة واضحة و"قضايا جيدة للمبتدئين".
• القائمون على الصيانة يريدون عملية نشر منخفضة الاحتكاك ومراجعات متوقعة.
• الرعاة يريدون دليلًا على الأثر وطريقة سهلة للدعم.

تمرين مفيد: لكل جمهور، اكتب أهم 3 أسئلة يأتون بها (مثل: “كيف أُثبّت؟”، “هل المشروع مُدار بنشاط؟”، “أين أبلغ عن خطأ؟”).

اختر مقاييس نجاح يمكن قياسها فعليًا

اختر مقاييس بسيطة ترتبط بأهدافك وقابلة للتتبع:

• هدف الوثائق → حركة المرور لصفحات الوثائق الأساسية، استعلامات البحث، وقت الوصول إلى دليل النجاح الأول.
• هدف المجتمع → عدد المساهمين الجدد، القضايا المصنفة، طلبات السحب المدمجة.
• هدف التحديثات → الاشتراكات بالنشرة، المشتركين في RSS، مشاهدات منشورات الإصدار.

اذكر ما ليس من أهدافك لمنع اتساع النطاق

قائمة صريحة بما لن يقوم به الموقع (في الوقت الحالي): تطبيقات ويب مخصصة، أنظمة حسابات معقّدة، تكاملات ثقيلة، أو ميزات CMS مصممة حسب الطلب. هذا يحمي وقت القائمين على الصيانة ويُبقي المشروع قابلًا للإصدار.

قرر ما يمكن للمجتمع تحريره مقابل ما يقتصر على القائمين

قسّم المحتوى إلى دلوين:

• قابل للتحرير من المجتمع: الوثائق، الأسئلة الشائعة، البرامج التعليمية، الترجمات، الأمثلة، تصحيحات الإملاء.
• خاص بالقائمين: صفحات الأمان، النصوص القانونية/السياسة، قرارات الحوكمة، التصريحات الرسمية.

هذا القرار الواحد سيحدد اختيارات الأدوات وسير المراجعة وتجربة المساهم لاحقًا.

خطط هيكل الموقع ونموذج المحتوى

يصبح موقع المجتمع فوضويًا بسرعة إذا لم تقرر ما "ينتمي" إلى الموقع مقابل ما يجب أن يبقى في README الخاص بالمستودع. قبل الأدوات والقوالب، اتفق على بنية بسيطة ونموذج محتوى واضح—حتى يعرف المساهمون أين يضيفون الأشياء ويعرف القائمون على الصيانة كيفية مراجعتها.

ابدأ بخريطة موقع تتوافق مع طريقة تفكير الناس

اجعل التنقل الرئيسي تقليديًا بقصد. خريطة موقع افتراضية جيدة لموقع مشروع مفتوح المصدر:

• الصفحة الرئيسية: ما هو المشروع، لماذا وُجِد، روابط سريعة
• الوثائق: البدء السريع، الأدلة، API/المرجع، الأسئلة الشائعة
• المدونة/الأخبار: الإصدارات، الإعلانات، تسليط الضوء على المجتمع
• المجتمع: روابط الدردشة/المنتدى، الفعاليات، مدونة السلوك
• المساهمة: "كيفية المساعدة"، قضايا للمبتدئين، خطوات المساهمة
• الحوكمة: صنع القرار، القائمون على الصيانة، السياسات

إذا لم تتناسب صفحة مع أحد هذه، فهذه إشارة إلى أنك قد تضيف شيئًا داخليًا (أنسب للمستودع) أو شيء يحتاج نوع محتوى منفصل.

قرر ما الذي يعيش على الموقع مقابل README في المستودع

استخدم README لضروريات المطور: تعليمات البناء، الإعداد المحلي، الاختبار، وحالة المشروع السريعة. استخدم الموقع لـ:

• محتوى الإعداد للمستخدمين والمساهمين
• الأدلة الطويلة والبرامج التعليمية
• السياسات العامة (مدونة السلوك، الحوكمة)
• ملاحظات الإصدار والإعلانات

هذا الفصل يمنع تكرار المحتوى الذي يبتعد تدريجيًا عن التزامنه.

حدد الملكية، النبرة، وإصدار الوثائق مقدمًا

عيّن مالكي المحتوى لكل مجال (الوثائق، المدونة/الأخبار، الترجمات). يمكن أن تكون الملكية مجموعة صغيرة بمسؤولية مراجعة واضحة، لا شخصًا واحدًا يحكم.

اكتب دليل نبرة وأسلوب قصير يكون ودياً لمجتمع عالمي: لغة بسيطة، مصطلحات متسقة، وإرشاد للكتّاب غير الناطقين بالإنجليزية.

إذا كان مشروعك يصدر إصدارات، خطط لإصدار مستندات مُرقّمة مبكرًا (مثال: “الأحدث” بالإضافة إلى الإصدارات المدعومة). تصميم البنية الآن أسهل من تعديلها بعد عدة إصدارات.

اختر مجموعة تقنية تدعم المساهمات

يجب أن تجعل بنية الموقع من السهل على أي شخص تصحيح خطأ إملائي، إضافة صفحة جديدة، أو تحسين الوثائق دون أن يصبح مهندس بناء. لمعظم المشاريع المفتوحة، يعني ذلك: محتوى Markdown أولًا، إعداد محلي سريع، وسير طلب سحب سلس مع معاينات.

إذا كنت تتوقع تكرارًا سريعًا على التخطيط والتنقل، فكِّر في بناء تجربة الموقع أولًا قبل الالتزام بإطار طويل الأمد. منصات مثل Koder.ai يمكن أن تساعدك على تصميم موقع وثائق/تسويق عبر المحادثة، توليد واجهة React العاملة مع خلفية عند الحاجة، ثم تصدير الشيفرة المصدرية للاحتفاظ بها في المستودع—مفيدة لاستكشاف بنية المعلومات وسير المساهمة دون أسابيع من الإعداد.

مولدات المواقع الثابتة المناسبة لتحرير المجتمع

كيف تتراصّ الخيارات الشائعة لمواقع الوثائق والصيانة بالمساهمات:

• Docusaurus: ممتاز لمواقع الوثائق مع إصدار نسخ، شريط جانبي، وخيارات بحث مدمجة. الإعداد المحلي مباشر (Node) ومهيأ للوثائق المعتمدة على PR.
• MkDocs (مع Material): سهل جدًا للمساهمين—اكتب Markdown، عدّل mkdocs.yml، وشغّل أمرًا واحدًا. عادةً ما يكون البحث قويًا وسريعًا.
• Hugo: بنى سريعة جدًا وأنواع محتوى مرنة. تعقيد أعلى قليلًا في القوالب، لكنه ممتاز عندما تريد كلًا من الوثائق وموقع تسويقي أغنى.
• Jekyll: يعمل بانسجام مع GitHub Pages، لكن قد يشعر أنه أقل ملاءمة من الأدوات الأحدث. ما يزال مناسبًا للمواقع الأبسط.
• Astro: ممتاز للمواقع الحديثة الغنية بالمحتوى والصفحات المكونية. الأفضل عندما تتوقع المزيد من واجهات المستخدم المخصصة خارج نطاق الوثائق.

الاستضافة والمعاينات: ركّز على “PR → معاينة → دمج”

اختر استضافة تدعم بناء المعاينات حتى يرى المساهمون تغييراتهم حية قبل النشر:

• GitHub Pages / GitLab Pages: بسيطة ومألوفة؛ قد تتطلب معاينات إعداد CI إضافي.
• Netlify / Cloudflare Pages: دعم قوي لمعَينات PR خارج الصندوق، مع سهولة التراجع.

إذا استطعت، اجعل المسار الافتراضي "افتح PR، احصل على رابط معاينة، اطلب مراجعة، ادمج". هذا يقلل الحاجة إلى تواصل طويل ويزيد ثقة المساهم.

دوِّن القرار حتى لا يخمن القادمون

أضف docs/website-stack.md قصير (أو قسم في README.md) يشرح ما اخترت ولماذا: كيفية تشغيل الموقع محليًا، أين تظهر المعاينات، وأنواع التغييرات التي تنتمي لمستودع الموقع.

أعد المستودع للتعاون

مستودع مرحّب يصنع الفرق بين "تعديلات عابرة" ومساهمات مجتمعية مستمرة. هدفك هو بنية سهلة التصفح، متوقعة للمراجعين، وبسيطة للتشغيل محليًا.

تخطيط المستودع الموصى به

جمع ملفات الويب ذات الصلة وتسميتها بوضوح. نهج شائع:

/
  /website        # صفحات تسويقية، الصفحة الرئيسية، التنقل
  /docs           # مصدر الوثائق (المرجع، الأدلة)
  /blog           # ملاحظات الإصدارات، الإعلانات، القصص
  /static         # صور، أيقونات، أصول قابلة للتنزيل
  /.github        # قوالب القضايا، سير العمل، CODEOWNERS
  README.md       # نظرة عامة على المستودع

إذا كان مشروعك يحتوي بالفعل على شفرة تطبيق، فكِّر بوضع الموقع في /website (أو /site) حتى لا يضطر المساهمون للتخمين من أين يبدأون.

أضف README مركز داخل /website

أنشئ /website/README.md يجيب عن: "كيف أعاين تغييري؟"، اجعله قصيرًا ويمكن نسخه ولصقه.

مثال بدء سريع (عدّل وفق مكدّنك):

# Website quickstart

## Requirements
- Node.js 20+

## Install
npm install

## Run locally
npm run dev

## Build
npm run build

## Lint (optional)
npm run lint

أضف أيضًا مكان الملفات الأساسية (التنقل، التذييل، إعادة التوجيه) وكيف تضيف صفحة جديدة.

قدّم قوالب محتوى يمكن للناس نسخها

القوالب تقلّل من نقاشات التنسيق وتسّرع المراجعات. أضف مجلد /templates (أو وثّق القوالب في /docs/CONTRIBUTING.md).

/templates
  docs-page.md
  tutorial.md
  announcement.md

قد يبدو قالب صفحة الوثائق الأدنى هكذا:

---
title: "Page title"
description: "One-sentence summary"
---

## What you’ll learn

## Steps

## Troubleshooting

وجّه المراجعات عبر CODEOWNERS (عند الاقتضاء)

إذا كان لديك مسؤولون عن مجالات محددة، أضف /.github/CODEOWNERS حتى يتم طلب الأشخاص المناسبين تلقائيًا:

/docs/    @docs-team
/blog/    @community-team
/website/ @web-maintainers

اجعل الإعدادات بسيطة ومشروحة جيدًا

فضّل ملف إعداد موحّد لكل أداة، وأضف تعليقات مختصرة تشرح "لماذا" (وليس كل خيار). الهدف أن يغيّر المساهم الجديد عنصر قائمة أو يصلح تهجئة دون تعلم نظام البناء بأكمله.

أنشئ إرشادات مساهمة يتبعها الناس

الموقع يجذب نوعًا مختلفًا من المساهمات عن قاعدة الشيفرة: تصحيحات نصية، أمثلة جديدة، لقطات شاشة، ترجمات، وتعديلات واجهة صغيرة. إذا كان CONTRIBUTING.md مكتوبًا فقط للمطورين، ستفقد الكثير من المساعدة المحتملة.

اجعل CONTRIBUTING.md "مركزًا للموقع"

أنشئ (أو فصل) CONTRIBUTING.md يركّز على تغييرات الموقع: مكان المحتوى، كيف تُولّد الصفحات، وما يعنيه "تم". أضف جدول "المهام الشائعة" القصير (تصحيح تهجئة، إضافة صفحة جديدة، تحديث التنقل، نشر منشور مدونة) حتى يبدأ القادمون خلال دقائق.

إذا كان لديك إرشاد أعمق، اربطه بوضوح من CONTRIBUTING.md (مثلاً، صفحة إرشادية تحت /docs).

فسّر كيفية اقتراح التعديلات (قضايا مقابل PRs)

كن صريحًا بشأن متى تفتح Issue أولًا ومتى تُقدّم PR مباشرًا:

• افتح issue أولًا للصفحات الجديدة، التغييرات الهيكلية، أو أي شيء يحتاج نقاشًا (النبرة، التموضع، تغييرات التصميم الكبرى).
• الـ PRs المباشرة مرحب بها لتصحيحات الإملاء، الروابط المكسورة، والتوضيحات الصغيرة الواضحة.

ضمّن نموذج "قضية جيدة" قصيرًا: عنوان الصفحة/URL، التغيير المطلوب، لماذا يساعد القرّاء، وأي مصادر.

حدد توقعات المراجعة التي يمكن الوثوق بها

أغلب الإحباط يأتي من الصمت، ليس الرد. حدد:

• زمن الاستجابة المعتاد (مثال: "نقر بالع acknowledgement خلال 3 أيام عمل")
• الموافقات المطلوبة (مثال: مُراجع واحد + مُدقق وثائق لصفحات جديدة)
• فحوصات النمط (linters، التنسيق، مدقق الروابط، التدقيق الإملائي) وهل يجب على المساهم تشغيلها محليًا

أضف قائمة فحص للمحتوى لكل PR

قائمة خفيفة تمنع العودة والعودة:

• الروابط تعمل (يفضّل الروابط النسبية للصفحات الداخلية)
• لقطات الشاشة حديثة ولها نص بديل
• العناوين قابلة للمسح؛ النبرة تطابق الوثائق الحالية
• أساسيات الوصول: تباين الألوان، أنماط قابلة للوصول عبر لوحة المفاتيح، نصوص رابط وصفية
• ملاحظة سجل التغييرات إذا أثر التغيير على المستخدمين

صمّم سير مراجعة ونشر

يبقى الموقع المجتمعي صحيًا عندما يعرف المشاركون بالضبط ماذا يحدث بعد فتح طلب السحب. الهدف هو سير عمل متوقع، منخفض الاحتكاك، وآمن للنشر.

ابدأ بقالب PR يقلل الحاجة للتواصل الطويل

أضف قالب طلب سحب (مثلاً .github/pull_request_template.md) يسأل فقط ما يحتاجه المراجعون:

• ما الذي تغيّر؟ (جملة أو اثنتان)
• لماذا؟ (رابط issue أو سياق)
• لقطات شاشة (للتغييرات البصرية—قبل/بعد)
• قائمة التحقق (تهجئة، روابط، frontmatter)

هذا يُسرّع المراجعات ويعلم المساهمين شكل "الجيد".

اجعل كل PR قابلاً للنقر بمعاينات النشر

فعّل معاينات نشر حتى يتمكن المراجعون من رؤية التغيير على موقع حي. هذا مفيد خصوصًا لتحديثات التنقل، الأنماط، والتخطيطات التي لا تظهر في diff نصي.

نمط شائع:

• فتح PR → CI يبني الموقع
• مزوّد الاستضافة ينشر رابط معاينة إلى PR
• المراجعون ينقرون، يتحققون، ويطلبون تغييرات إن احتاج الأمر

آتومات الفحوصات المملة والمعرضة للخطأ

استخدم CI لتشغيل بوابات خفيفة على كل PR:

• مدقق روابط لاكتشاف الروابط الداخلية/الخارجية المعطلة
• Markdown lint للحفاظ على تنسيق متسق
• تنسيق (Prettier أو ما شابه) لتجنّب مناقشات النمط

افشل سريعًا مع رسائل خطأ واضحة، حتى يتمكن المساهمون من الإصلاح دون تدخل القائمين.

اجعل النشر بسيطًا: الدمج إلى main ينشر

وثق قاعدة واحدة: عندما يُوافق على PR ويُدمج إلى main، يُنشر الموقع تلقائيًا. لا خطوات يدوية، لا أوامر سرية. ضع السلوك الدقيق في /contributing ليكون التوقع واضحًا.

إذا كنت تستخدم منصة تدعم اللقطات/التراجع (بعض المضيفين يفعلون، وكذلك Koder.ai عند النشر من خلالها)، وثّق أين تجد "آخر بناء جيد" وكيف تستعيده.

اكتب خطوات التراجع قبل الحاجة إليها

الانتشار قد يفشل أحيانًا. وثّق دليل تراجع قصير:

• عدّل commit الدمج (revert) أو استعد الوسم الأخير المعروف بالجيد
• أكد إعادة تشغيل عملية النشر
• افتح قضية متابعة تشرح ما حدث وكيف نمنع تكراره

ابنِ نظام تصميم محتوى متسق

يبقى الموقع مرحبًا عندما تشعر الصفحات بأنها تنتمي إلى نفس المكان. نظام تصميم خفيف الوزن يساعد المساهمين على التحرّك أسرع، يقلل الخلافات خلال المراجعة، ويحافظ على توجيه القراء—حتى مع نمو الموقع.

ابدأ بتخطيطات صفحات قابلة لإعادة الاستخدام وقواعد تنقل

حدد مجموعة صغيرة من أنواع الصفحات والتزم بها: صفحة وثائق، منشور مدونة/أخبار، صفحة هبوط، وصفحة مرجعية. لكل نوع، قرر ما يظهر دائمًا (العنوان، الملخص، آخر تحديث، جدول المحتويات، روابط التذييل) وما لا يجب أن يظهر أبدًا.

ضع قواعد تنقل تحمي الوضوح:

• حافظ على فئات التنقل العليا ثابتة؛ أضف صفحات جديدة داخل المجموعات القائمة أولًا.
• تجنب أكثر من 3 مستويات تعشيش في الأشرطة الجانبية.
• اطلب من الصفحات الجديدة إعلان مكانها في التسلسل الهرمي (مثال: sidebar_position أو weight).

أنشئ مكونات محتوى قابلة لإعادة الاستخدام

بدلًا من مطالبة المساهمين بـ"جعلها متناسقة"، قدّم لهم قطع بناء:

• نداءات مميزة للملاحظات، التحذيرات، والنصائح
• قوالب كود قياسية بعلامات اللغة، قواعد التفاف الأسطر، وأزرار النسخ (إن وُجدت)
• أنماط مرجع API (جدول نقط النهاية، المعلمات، الاستجابات، أمثلة)

وثّق هذه المكونات في صفحة "طقم واجهة محتوى" قصيرة (مثال: /docs/style-guide) مع أمثلة للنسخ واللصق.

اجعل العلامة التجارية خفيفة الوزن

حدد الحد الأدنى: استخدام الشعار (أين لا يجوز تمديده أو إعادة تلوينه)، لونان-ثلاثة ألوان أساسية بتباين قابل للوصول، وخط أو خطين. الهدف تسهيل "الجيد بما فيه الكفاية" بدلًا من قمع الإبداع.

اجعل لقطات الشاشة والمخططات سهلة الصيانة

اتفق على اتفاقيات: عرض ثابت، حشوة متسقة، وتسميات مثل feature-name__settings-dialog.png. فضّل ملفات المصدر للرسوم (مثل Mermaid أو SVG قابلة للتعديل) حتى لا تتطلب التحديثات مصممًا.

احمِ تسلسل المعلومات

أضف قائمة بسيطة لقالب PR: "هل توجد صفحة لذلك بالفعل؟"، "هل العنوان يتطابق مع القسم؟"، و"هل سينشئ هذا فئة عليا جديدة؟". هذا يمنع انتشار المحتوى بينما يشجع المساهمات.

اجعل الموقع قابلًا للوصول، سريعًا، وقابلًا للفهرسة

موقع المجتمع يعمل فقط إذا استطاع الناس استخدامه—على تقنيات المساعدة، على اتصالات بطيئة، ومن خلال البحث. عامل الوصول، الأداء، وSEO كاعدادات افتراضية، لا كلمسات نهائية.

الوصول: التزم بالحد الأدنى في كل مرة

ابدأ ببنية دلالية. استخدم الرؤوس بالترتيب (H1 في الصفحة، ثم H2/H3)، ولا تتخطى المستويات لمجرد الحصول على حجم خط أكبر.

للمحتوى غير النصي، اطلب نصًا بديلًا ذا معنى. قاعدة بسيطة: إذا كانت الصورة تنقل معلومة، فصِفها؛ إن كانت زخرفية فقط، استخدم alt="" ليتم تجاهلها من قارئات الشاشة.

تحقق من تباين الألوان وحالات التركيز في رموز التصميم حتى لا يضطر المساهمون للتخمين. تأكد أن كل عنصر تفاعلي يمكن الوصول إليه عبر لوحة المفاتيح، وأن التركيز لا يحجز في قوائم أو حوارات أو أمثلة الكود.

الأداء: حافظ على خفة الصفحة

حسّن الصور افتراضيًا: غيّر الحجم لأقصى حجم عرض، اضغطها، وفضّل الصيغ الحديثة حيث يدعم البناء ذلك. تجنّب تحميل حزم عميلة كبيرة لصفحات نصية بحتة.

قلّل السكربتات الطرف ثالث قدر الإمكان؛ كل عنصر إضافي يزيد الوزن وقد يبطئ الموقع للجميع.

استفد من قواعد التخزين المؤقت الافتراضية المقدّمة من مضيفك (مثلاً، أصول غير قابلة للتغيير مع هاش). إن أمكن، ولّد CSS/JS مصغَّرًا وضمّن فقط ما هو حيوي.

الاكتشاف: SEO بسيط وعملي

امنح كل صفحة عنوانًا واضحًا ووصفًا ميتا قصيرًا يطابق محتواها. استخدم روابط نظيفة ومستقرة (لا تواريخ إلا إن كانت مهمة) ومسارات قانونية ثابتة.

ولّد خريطة موقع وملف robots.txt يسمح بفهرسة الوثائق العامة. إذا نشرت إصدارات متعددة من الوثائق، تجنّب المحتوى المكرر بجعل نسخة واحدة "الحالية" وربط أخرى بوضوح.

التحليلات والترخيص: كن شفافًا

أضف التحليلات فقط إن كنت ستستغل البيانات. إن فعلت، اشرح ما يُجمع ولماذا وكيفية الانسحاب في صفحة مخصصة (مثال: /privacy).

أخيرًا، أدرج إشعار ترخيص واضح لمحتوى الموقع (بمنفصل عن ترخيص الشيفرة إن لزم). ضعه في التذييل وفي README الخاص بالمستودع ليعلم المساهمون كيف يمكن إعادة استخدام نصوصهم وصورهم.