كيفية إدارة برنامج InnerSource بشكل ناجح

مكتمل

هنا، نناقش كيف يمكنك تصميم برنامج InnerSource للاستمتاع بأفضل الأنماط مفتوحة المصدر داخل أي مؤسسة لتطوير البرامج.

ما هو InnerSource؟

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

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

فوائد InnerSource

يمكن لبرنامج InnerSource أن يقدم العديد من الفوائد التي تتجاوز ما توفره النماذج التقليدية مغلقة المصدر.

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

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

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

‏‫نَصِيحة

ضع في اعتبارك استخدام مناقشات GitHub ومشاريع GitHub لمزيد من الدعم لدعم تعاون InnerSource عبر الفرق.

هذه الأمثلة ليست سوى عدد قليل من الفوائد التي تتمتع بها برامج InnerSource. لمعرفة المزيد، راجع مقدمة إلى InnerSource.

إعداد برنامج InnerSource على GitHub

تعيين رؤية المستودع والأذونات

يمكنك تكوين مستودعات GitHub بثلاثة مستويات من الرؤية. يرى المستخدمون الذين لا يستوفون متطلبات الرؤية صفحات "غير موجود" عندما يحاولون الوصول إلى مستودعك. مستويات الرؤية هي كما يلي:

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

Note

المستودعات الداخلية متاحة فقط لعملاء GitHub Enterprise. استخدم هذه الرؤية لمشاريع InnerSource.

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

بمجرد إنشاء رؤية المستودع، يمكنك تكوين الأذونات على أساس فردي أو فريق. توجد خمسة مستويات للإذن:

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

تعرف على المزيد حول أذونات الوصول إلى المستودع حسب المستوى.

إنشاء مستودعات قابلة للاكتشاف

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

ومن بين تلك أفضل الممارسات:

• استخدم اسم مستودع وصفي، مثل warehouse-api أو supply-chain-web.
• وقم بتضمين وصف موجز. وينبغي أن تكون جملة أو جملتين كافيتين للمستخدمين المحتملين لمعرفة ما إذا كان المشروع قد يناسب احتياجاتهم.
• قم بترخيص مستودعك حتى يعرف العملاء كيف يمكنهم استخدام البرنامج وتغييره وتوزيعه.
• قم بتضمين README.md ملف في المستودع. يستخدم GitHub هذا الملف كصفحة يتم الانتقال إليها عند زيارة الأشخاص للمستودع.

إضافة ملف README

ينقل ملف README توقعات مشروعك ويساعدك على إدارة المساهمات. يمكن لملفات README:

• وضِّح غرض المشروع ورؤيته حتى يفهم المستهلكون المحتملون ما إذا كان يناسب احتياجاتهم.
• قدم وسائل مساعدة بصرية؛ مثل: لقطات الشاشة أو نماذج التعليمات البرمجية، لتوضيح المشروع أثناء العمل.
• قم بتضمين ارتباطات إلى إصدار إنتاج أو عرض توضيحي للتطبيق لمراجعته.
• قم بتعيين توقعات المتطلبات الأساسية، وإجراءات النشر.
• قم بتضمين مراجع للمشاريع التي تعتمد عليها. هذه المراجع هي وسيلة جيدة لتعزيز عمل الآخرين.
• استخدم Markdown لتوجيه القراء من خلال المحتوى المنسق بشكل صحيح.

إذا وضعت ملف README.md الخاص بك في الدليل الجذر للمستودع الخاص بك ، أو في الدليل المخفي .github أو docs ، فإن GitHub يتعرف على README الخاص بك ويعرضه تلقائيا على زوار المستودع. إذا كان المستودع يحتوي على أكثر من ملف README واحد، اختيار الملف المعروض من المواقع بالترتيب التالي:

1. الدليل .github
2. الدليل الجذر للمستودع
3. الدليل docs

اطلع على بعض أمثلة README الرائعة.

بمجرد إطلاق المشروع، استخدم البريد الإلكتروني وقنوات الشبكات الأخرى للترويج له. ويمكن أن يؤدي الوصول إلى جمهور مناسب إلى دفعة كبيرة في المشاركة في المشاريع.

تعرف على المزيد حول ملفات README في وثائق GitHub.

إدارة المشاريع على GitHub

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

لمعالجة هذه المشكلة بشكل استباقي، يبحث GitHub عن CONTRIBUTING.md ملف في جذر (أو /docs ) /.githubالمستودع. استخدم هذا الملف لشرح سياسة المساهمة للمشروع. قد تختلف التفاصيل الدقيقة، ولكن من الجيد السماح للمساهمين المحتملين بمعرفة الاصطلاحات التي يتبعها المشروع. على سبيل المثال، حيث يبحث الفريق عن طلبات السحب، وما هي التفاصيل المطلوبة لتقارير الأخطاء، وما إلى ذلك.

CONTRIBUTING.md إذا كان موجودا، يقدم GitHub ارتباطا إليه عندما يقوم المستخدمون بإنشاء مشكلات أو سحب الطلبات لتشجيعهم على متابعته.

اطلع على بعض الأمثلة CONTRIBUTING.md الرائعة

بالإضافة إلى ذلك، ضع في اعتبارك إضافة ملف CODEOWNERS إلى المستودع لتحديد الأفراد أو الفرق المسؤولة عن مراجعة تعديلات التعليمات البرمجية.

إنشاء قوالب طلب المشكلة والسحب

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

على سبيل المثال، إذا كان مشروعك يحتوي .github/ISSUE_TEMPLATE.mdعلى ، في أي وقت يبدأ فيه المستخدم عملية إنشاء مشكلة، يرى هذا المحتوى. بدلا من الاضطرار إلى الرجوع باستمرار إلى التفاصيل المطلوبة من CONTRIBUTING.md، يمكنهم فقط ملء المشكلة مثل نموذج باستخدام نص القالب.

الأمر نفسه بالنسبة لطلبات السحب، باستثناء أن المسار هو .github/PULL_REQUEST_TEMPLATE.md.

تحقق من بعض مشكلة GitHub الرائعة وقوالب طلب السحب.

تعريف مهام سير العمل

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

ينبغي عليك توصيل إستراتيجية لإدارة عمليات الإصدار والنشر. تؤثر هذه الأجزاء من سير العمل على التفريع والدمج اليومي، لذلك من المهم توصيلها إلى المساهمين. تعرف على المزيد حول كيفية ارتباطها باستراتيجية تفريع Git الخاصة بك.

قياس نجاح البرنامج

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

بدلا من ذلك، ضع في اعتبارك إضافة مقاييس توضح كيفية تحسين المشاركة الخارجية لجودة المشروع. هل يقوم المستودع بتلقي طلبات السحب من مصادر خارجية، والتي تقوم بإصلاح الأخطاء وإضافة ميزات؟ هل يوجد مشاركون نشطون في المناقشات حول المشروع ومستقبله؟ هل البرنامج يلهم توسعًا في InnerSource، والذي بدوره يستحث الفوائد في مكان آخر في المؤسسة؟

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

• عملية القياس، وليس الإخراج
  • وقت استجابة استعراض التعليمات البرمجية
  • حجم طلب السحب
  • العمل قيد التنفيذ
  • وقت الفتح
• التأكد من المستوى في مقابل الأهداف، وليس القيم المطلقة
• قياس الفرق وليس الأفراد
  • عدد المساهمين الفريدين في مشروع
  • عدد المشاريع التي تعيد استخدام التعليمات البرمجية
  • عدد الفرق المشتركة @mentions

تعرف على النجاحات التي يتمتع بها الآخرون في دراسات الحالة InnerSource هذه.