18 أبريل 2025·6 دقيقة
بناء موقع مشروع مفتوح المصدر بمساهمة المجتمع
تعلم كيفية تخطيط وبناء وصيانة موقع لمشروع مفتوح المصدر يرحب بمساهمات المجتمع مع سير عمل واضح، خطوات مراجعة، ونشر موثوق.
تعلم كيفية تخطيط وبناء وصيانة موقع لمشروع مفتوح المصدر يرحب بمساهمات المجتمع مع سير عمل واضح، خطوات مراجعة، ونشر موثوق.
قبل أن تختار قالبًا أو تصمم الصفحة الرئيسية، كن محددًا بشأن هدف الموقع. غالبًا ما تحاول مواقع المشاريع مفتوحة المصدر أن تكون كل شيء في آن واحد—بوابة وثائق، صفحة تسويقية، محور مجتمع، مدونة، قنوات تبرع—فتنتهي بعدم أداء أيٍ منها بشكل جيد.
دوّن 1–3 مهام عليا يجب أن ينجزها الموقع. أمثلة شائعة:
إذا لم تستطع شرح غرض الموقع في جملة واحدة، لن يستطيع الزائرون فعل ذلك أيضًا.
اكتب جماهيرك الرئيسية و"النقرة الأولى" التي تريدها من كل مجموعة:
تمرين مفيد: لكل جمهور، اكتب أهم 3 أسئلة يأتون بها (مثل: “كيف أُثبّت؟”، “هل المشروع مُدار بنشاط؟”، “أين أبلغ عن خطأ؟”).
اختر مقاييس بسيطة ترتبط بأهدافك وقابلة للتتبع:
قائمة صريحة بما لن يقوم به الموقع (في الوقت الحالي): تطبيقات ويب مخصصة، أنظمة حسابات معقّدة، تكاملات ثقيلة، أو ميزات CMS مصممة حسب الطلب. هذا يحمي وقت القائمين على الصيانة ويُبقي المشروع قابلًا للإصدار.
قسّم المحتوى إلى دلوين:
هذا القرار الواحد سيحدد اختيارات الأدوات وسير المراجعة وتجربة المساهم لاحقًا.
يصبح موقع المجتمع فوضويًا بسرعة إذا لم تقرر ما "ينتمي" إلى الموقع مقابل ما يجب أن يبقى في README الخاص بالمستودع. قبل الأدوات والقوالب، اتفق على بنية بسيطة ونموذج محتوى واضح—حتى يعرف المساهمون أين يضيفون الأشياء ويعرف القائمون على الصيانة كيفية مراجعتها.
اجعل التنقل الرئيسي تقليديًا بقصد. خريطة موقع افتراضية جيدة لموقع مشروع مفتوح المصدر:
إذا لم تتناسب صفحة مع أحد هذه، فهذه إشارة إلى أنك قد تضيف شيئًا داخليًا (أنسب للمستودع) أو شيء يحتاج نوع محتوى منفصل.
استخدم README لضروريات المطور: تعليمات البناء، الإعداد المحلي، الاختبار، وحالة المشروع السريعة. استخدم الموقع لـ:
هذا الفصل يمنع تكرار المحتوى الذي يبتعد تدريجيًا عن التزامنه.
عيّن مالكي المحتوى لكل مجال (الوثائق، المدونة/الأخبار، الترجمات). يمكن أن تكون الملكية مجموعة صغيرة بمسؤولية مراجعة واضحة، لا شخصًا واحدًا يحكم.
اكتب دليل نبرة وأسلوب قصير يكون ودياً لمجتمع عالمي: لغة بسيطة، مصطلحات متسقة، وإرشاد للكتّاب غير الناطقين بالإنجليزية.
إذا كان مشروعك يصدر إصدارات، خطط لإصدار مستندات مُرقّمة مبكرًا (مثال: “الأحدث” بالإضافة إلى الإصدارات المدعومة). تصميم البنية الآن أسهل من تعديلها بعد عدة إصدارات.
يجب أن تجعل بنية الموقع من السهل على أي شخص تصحيح خطأ إملائي، إضافة صفحة جديدة، أو تحسين الوثائق دون أن يصبح مهندس بناء. لمعظم المشاريع المفتوحة، يعني ذلك: محتوى Markdown أولًا، إعداد محلي سريع، وسير طلب سحب سلس مع معاينات.
إذا كنت تتوقع تكرارًا سريعًا على التخطيط والتنقل، فكِّر في بناء تجربة الموقع أولًا قبل الالتزام بإطار طويل الأمد. منصات مثل Koder.ai يمكن أن تساعدك على تصميم موقع وثائق/تسويق عبر المحادثة، توليد واجهة React العاملة مع خلفية عند الحاجة، ثم تصدير الشيفرة المصدرية للاحتفاظ بها في المستودع—مفيدة لاستكشاف بنية المعلومات وسير المساهمة دون أسابيع من الإعداد.
كيف تتراصّ الخيارات الشائعة لمواقع الوثائق والصيانة بالمساهمات:
mkdocs.yml، وشغّل أمرًا واحدًا. عادةً ما يكون البحث قويًا وسريعًا.اختر استضافة تدعم بناء المعاينات حتى يرى المساهمون تغييراتهم حية قبل النشر:
إذا استطعت، اجعل المسار الافتراضي "افتح PR، احصل على رابط معاينة، اطلب مراجعة، ادمج". هذا يقلل الحاجة إلى تواصل طويل ويزيد ثقة المساهم.
أضف docs/website-stack.md قصير (أو قسم في README.md) يشرح ما اخترت ولماذا: كيفية تشغيل الموقع محليًا، أين تظهر المعاينات، وأنواع التغييرات التي تنتمي لمستودع الموقع.
مستودع مرحّب يصنع الفرق بين "تعديلات عابرة" ومساهمات مجتمعية مستمرة. هدفك هو بنية سهلة التصفح، متوقعة للمراجعين، وبسيطة للتشغيل محليًا.
جمع ملفات الويب ذات الصلة وتسميتها بوضوح. نهج شائع:
/
/website # صفحات تسويقية، الصفحة الرئيسية، التنقل
/docs # مصدر الوثائق (المرجع، الأدلة)
/blog # ملاحظات الإصدارات، الإعلانات، القصص
/static # صور، أيقونات، أصول قابلة للتنزيل
/.github # قوالب القضايا، سير العمل، CODEOWNERS
README.md # نظرة عامة على المستودع
إذا كان مشروعك يحتوي بالفعل على شفرة تطبيق، فكِّر بوضع الموقع في /website (أو /site) حتى لا يضطر المساهمون للتخمين من أين يبدأون.
/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
إذا كان لديك مسؤولون عن مجالات محددة، أضف /.github/CODEOWNERS حتى يتم طلب الأشخاص المناسبين تلقائيًا:
/docs/ @docs-team
/blog/ @community-team
/website/ @web-maintainers
فضّل ملف إعداد موحّد لكل أداة، وأضف تعليقات مختصرة تشرح "لماذا" (وليس كل خيار). الهدف أن يغيّر المساهم الجديد عنصر قائمة أو يصلح تهجئة دون تعلم نظام البناء بأكمله.
الموقع يجذب نوعًا مختلفًا من المساهمات عن قاعدة الشيفرة: تصحيحات نصية، أمثلة جديدة، لقطات شاشة، ترجمات، وتعديلات واجهة صغيرة. إذا كان CONTRIBUTING.md مكتوبًا فقط للمطورين، ستفقد الكثير من المساعدة المحتملة.
أنشئ (أو فصل) CONTRIBUTING.md يركّز على تغييرات الموقع: مكان المحتوى، كيف تُولّد الصفحات، وما يعنيه "تم". أضف جدول "المهام الشائعة" القصير (تصحيح تهجئة، إضافة صفحة جديدة، تحديث التنقل، نشر منشور مدونة) حتى يبدأ القادمون خلال دقائق.
إذا كان لديك إرشاد أعمق، اربطه بوضوح من CONTRIBUTING.md (مثلاً، صفحة إرشادية تحت /docs).
كن صريحًا بشأن متى تفتح Issue أولًا ومتى تُقدّم PR مباشرًا:
ضمّن نموذج "قضية جيدة" قصيرًا: عنوان الصفحة/URL، التغيير المطلوب، لماذا يساعد القرّاء، وأي مصادر.
أغلب الإحباط يأتي من الصمت، ليس الرد. حدد:
قائمة خفيفة تمنع العودة والعودة:
يبقى الموقع المجتمعي صحيًا عندما يعرف المشاركون بالضبط ماذا يحدث بعد فتح طلب السحب. الهدف هو سير عمل متوقع، منخفض الاحتكاك، وآمن للنشر.
أضف قالب طلب سحب (مثلاً .github/pull_request_template.md) يسأل فقط ما يحتاجه المراجعون:
هذا يُسرّع المراجعات ويعلم المساهمين شكل "الجيد".
فعّل معاينات نشر حتى يتمكن المراجعون من رؤية التغيير على موقع حي. هذا مفيد خصوصًا لتحديثات التنقل، الأنماط، والتخطيطات التي لا تظهر في diff نصي.
نمط شائع:
استخدم CI لتشغيل بوابات خفيفة على كل PR:
افشل سريعًا مع رسائل خطأ واضحة، حتى يتمكن المساهمون من الإصلاح دون تدخل القائمين.
وثق قاعدة واحدة: عندما يُوافق على PR ويُدمج إلى main، يُنشر الموقع تلقائيًا. لا خطوات يدوية، لا أوامر سرية. ضع السلوك الدقيق في /contributing ليكون التوقع واضحًا.
إذا كنت تستخدم منصة تدعم اللقطات/التراجع (بعض المضيفين يفعلون، وكذلك Koder.ai عند النشر من خلالها)، وثّق أين تجد "آخر بناء جيد" وكيف تستعيده.
الانتشار قد يفشل أحيانًا. وثّق دليل تراجع قصير:
يبقى الموقع مرحبًا عندما تشعر الصفحات بأنها تنتمي إلى نفس المكان. نظام تصميم خفيف الوزن يساعد المساهمين على التحرّك أسرع، يقلل الخلافات خلال المراجعة، ويحافظ على توجيه القراء—حتى مع نمو الموقع.
حدد مجموعة صغيرة من أنواع الصفحات والتزم بها: صفحة وثائق، منشور مدونة/أخبار، صفحة هبوط، وصفحة مرجعية. لكل نوع، قرر ما يظهر دائمًا (العنوان، الملخص، آخر تحديث، جدول المحتويات، روابط التذييل) وما لا يجب أن يظهر أبدًا.
ضع قواعد تنقل تحمي الوضوح:
sidebar_position أو weight).بدلًا من مطالبة المساهمين بـ"جعلها متناسقة"، قدّم لهم قطع بناء:
وثّق هذه المكونات في صفحة "طقم واجهة محتوى" قصيرة (مثال: /docs/style-guide) مع أمثلة للنسخ واللصق.
حدد الحد الأدنى: استخدام الشعار (أين لا يجوز تمديده أو إعادة تلوينه)، لونان-ثلاثة ألوان أساسية بتباين قابل للوصول، وخط أو خطين. الهدف تسهيل "الجيد بما فيه الكفاية" بدلًا من قمع الإبداع.
اتفق على اتفاقيات: عرض ثابت، حشوة متسقة، وتسميات مثل feature-name__settings-dialog.png. فضّل ملفات المصدر للرسوم (مثل Mermaid أو SVG قابلة للتعديل) حتى لا تتطلب التحديثات مصممًا.
أضف قائمة بسيطة لقالب PR: "هل توجد صفحة لذلك بالفعل؟"، "هل العنوان يتطابق مع القسم؟"، و"هل سينشئ هذا فئة عليا جديدة؟". هذا يمنع انتشار المحتوى بينما يشجع المساهمات.
موقع المجتمع يعمل فقط إذا استطاع الناس استخدامه—على تقنيات المساعدة، على اتصالات بطيئة، ومن خلال البحث. عامل الوصول، الأداء، وSEO كاعدادات افتراضية، لا كلمسات نهائية.
ابدأ ببنية دلالية. استخدم الرؤوس بالترتيب (H1 في الصفحة، ثم H2/H3)، ولا تتخطى المستويات لمجرد الحصول على حجم خط أكبر.
للمحتوى غير النصي، اطلب نصًا بديلًا ذا معنى. قاعدة بسيطة: إذا كانت الصورة تنقل معلومة، فصِفها؛ إن كانت زخرفية فقط، استخدم alt="" ليتم تجاهلها من قارئات الشاشة.
تحقق من تباين الألوان وحالات التركيز في رموز التصميم حتى لا يضطر المساهمون للتخمين. تأكد أن كل عنصر تفاعلي يمكن الوصول إليه عبر لوحة المفاتيح، وأن التركيز لا يحجز في قوائم أو حوارات أو أمثلة الكود.
حسّن الصور افتراضيًا: غيّر الحجم لأقصى حجم عرض، اضغطها، وفضّل الصيغ الحديثة حيث يدعم البناء ذلك. تجنّب تحميل حزم عميلة كبيرة لصفحات نصية بحتة.
قلّل السكربتات الطرف ثالث قدر الإمكان؛ كل عنصر إضافي يزيد الوزن وقد يبطئ الموقع للجميع.
استفد من قواعد التخزين المؤقت الافتراضية المقدّمة من مضيفك (مثلاً، أصول غير قابلة للتغيير مع هاش). إن أمكن، ولّد CSS/JS مصغَّرًا وضمّن فقط ما هو حيوي.
امنح كل صفحة عنوانًا واضحًا ووصفًا ميتا قصيرًا يطابق محتواها. استخدم روابط نظيفة ومستقرة (لا تواريخ إلا إن كانت مهمة) ومسارات قانونية ثابتة.
ولّد خريطة موقع وملف robots.txt يسمح بفهرسة الوثائق العامة. إذا نشرت إصدارات متعددة من الوثائق، تجنّب المحتوى المكرر بجعل نسخة واحدة "الحالية" وربط أخرى بوضوح.
أضف التحليلات فقط إن كنت ستستغل البيانات. إن فعلت، اشرح ما يُجمع ولماذا وكيفية الانسحاب في صفحة مخصصة (مثال: /privacy).
أخيرًا، أدرج إشعار ترخيص واضح لمحتوى الموقع (بمنفصل عن ترخيص الشيفرة إن لزم). ضعه في التذييل وفي README الخاص بالمستودع ليعلم المساهمون كيف يمكن إعادة استخدام نصوصهم وصورهم.
اكتب جملة غرضية للموقع، ثم حدد أهم 1–3 مهام يجب أن ينجزها الموقع (مثل: الوثائق، التنزيلات، المجتمع، التحديثات). إذا كانت صفحة أو ميزة لا تدعم هذه المهام، اعتبرها هدفًا غير مقصود لهذه المرحلة.
فحص بسيط: إذا لم تستطع شرح غرض الموقع في جملة واحدة، فالمستخدمون لن يتمكنوا من ذلك أيضًا.
قوّم جماهيرك الرئيسية وحدد «النقرة الأولى» التي تريدها من كل مجموعة:
لكل جمهور، اكتب أهم 3 أسئلة يأتون بها (مثل: «هل لا يزال المشروع مُدارًا؟»، «أين أبلغ عن خطأ؟») وتأكد أن التنقل يجيب عنها بسرعة.
ابدأ بخريطة موقع «مملّة عن قصد» تتطابق مع طريقة بحث الناس:
إذا لم تناسب محتويات جديدة أيًا من هذه، فربما تحتاج إلى نوع محتوى جديد (نادر) أو أن المعلومات تنتمي إلى المستودع بدل الموقع.
احتفظ بـ سير عمل المطوّر في README واستخدم الموقع للمواد العامة.
استخدم README للمطورين لِـ:
استخدم الموقع لـ:
اختر بنية تقنية تدعم تحريرات "Markdown أولاً" ومعاينة محلية سريعة.
خيارات شائعة:
استهدف مسارًا افتراضيًا: PR → معاينة → مراجعة → دمج.
الخطوات العملية:
main ينشر")هذا يقلل المراجعات المطوّلة ويعطي المساهمين ثقة بأن التغيير صحيح بصريًا.
استخدم بنية ومُقَسّمات تقلّل المناقشات الشكلية.
أساسيات مفيدة:
اجعل CONTRIBUTING.md "مركّزًا على الموقع":
يجب أن يحتوي على:
اجعله قصيرًا بما يكفي ليقرأه الناس، واربطه بتوثيق أعمق عند الحاجة.
عامل الوصول، الأداء، والاكتشاف كقواعد افتراضية:
أضف فحوصات آلية عندما تستطيع (مدقق الروابط، linter للماركدون، تنسيق) حتى لا يضطر المراجعون للقيام بها يدويًا.
اجعل التحديثات سهلة والصيانة متوقعة:
لتحديثات المجتمع:
/docs/en/..., /docs/es/...لاستدامة القائمين على الصيانة:
هذا الفصل يمنع تكرار المحتوى الذي ينسى التحديث تدريجيًا.
اختر أبسط أداة تلبي احتياجاتك الآن، لا الأكثر مرونة للمستقبل.
/website, /docs, /blog, /.github/website/README.md قصير بأوامر نسخ ولصق للتشغيل محليًا/templates (صفحة وثائق، برنامج تعليمي، إعلان)CODEOWNERS لتوجيه المراجعات بحسب المنطقةالهدف أن يقدر أي شخص تصحيح خطأ إملائي أو إضافة صفحة دون أن يصبح خبير بناء.
/privacy تشرح ما يُجمع ولماذا