عندما تشرف maintain على مستودع برنامجٍ مفتوح المصدر، فإنك تتولى دورًا قياديًا، سواءً كنت مؤسِّس المشروع الذي أطلقه وأتاحه للاستخدام والمساهمات، أو كنت تعمل ضمن فريق وتشرف على جانبٍ محددٍ من المشروع، فأنت تقدم خدمةً مهمةً لمجتمع المطورين العام.
على الرغم من أن مساهمات مجتمع المطورين مفتوحة المصدر التي تجري من خلال طلبات السحب ضروريةٌ لضمان تحقيق البرنامج الفائدة القصوى للمستخدمين النهائيين، لكن يوجد للمشرفين تأثيرٌ حقيقي على صياغة مجمَل المشروع؛ إذ يشارك المشرفون على المستودعات لدرجة هائلة في المشاريع مفتوحة المصدر التي يديرونها، من التنظيم والتطوير اليومي إلى التفاعل مع الجمهور وتقديم ملاحظاتٍ فوريةٍ وفعالةٍ للمساهمين.
سيتناول هذا الدليل بعض النصائح حول الإشراف على المستودعات العامة للبرامج مفتوحة المصدر، إذ يترافق كونك قائدًا لمشروعٍ مفتوح المصدر مع مسؤولياتٍ تقنية وغير تقنية للمساهمة في تعزيز قاعدة المستخدمين والدائرة المجتمعية حول مشروعك. إن تولي دور المشرف هو فرصة للتعلُّم من الآخرين، واكتساب الخبرة في إدارة المشاريع، ومراقبة نمو مشروعك وتغيره عندما يصبح المستخدمون مساهمين مستثمرين.
كتابة توثيق مفيد
يساهم التوثيق Documentation الشامل وحسن التنظيم الذي يخدم الفئات المستهدفة في مشروعك على توسيع قاعدة مستخدميه، وستصبح قاعدة المستخدمين هذه مع مرور الوقت هي المساهمة في مشروعك مفتوح المصدر.
قد يفيدك جعل كتابة التوثيق جزءًا من عملية التطوير الخاصة بك، لأنك ستفكر في الشيفرة البرمجية التي تكتبها على أية حال، وربما تدِّون ملاحظاتٍ عنها، فتستغل بذلك أن الأفكار حديثة في ذهنك؛ وربما ترغب في كتابة التوثيق قبل الشيفرة البرمجية، فتكون بذلك متبعًا لفلسفة نهج التطوير المستند على التوثيق، إذ يوثق هذا النهج خصائص البرنامج أولًا ثم يبرمجها بعد كتابة وظيفة كلٍ منها.
إليك بعض ملفات التوثيق التي يجب الاحتفاظ بها في مجلد المستوى الأعلى top-level directory الخاص بك، إلى جانب ملف شيفرتك البرمجية:
- ملف README.md، الذي يقدم ملخصًا عن المشروع وأهدافك منه.
- ملف CONTRIBUTING.md، الذي يحتوي على تعليمات المساهمة.
- ترخيص برنامجك، والذي يمكن أن يشجع الأشخاص على تقديم مساهماتٍ أكثر. ويمكنك قراءة المزيد حول اختيار ترخيص لبرنامجٍ مفتوح المصدر.
يوجد للتوثيق عدّة صيغٍ، ويمكن أن يُوجَّه لجماهير مختلفة، إذ يمكنك اختيار نوعٍ واحد أو أكثر من الأنواع التالية على أنه جزءٌ من توثيقك بناءً على مجال عملك:
- دليل عام general guide: لتعريف المستخدمين بالمشروع.
- دروس تعليمية Tutorials: لشرح حالات الاستخدام المختلفة.
- الأسئلة الشائعة FAQs: للإجابة على أكثر الأسئلة التي يطرحها المستخدمون.
- أدلة اكتشاف الأخطاء وتصحيحها Troubleshooting guides: لمساعدة المستخدمين على حل المشاكل.
- مرجع للواجهة البرمجية API reference: الذي يوفر للمستخدمين طريقةً سريعةً للعثور على معلومات الواجهة البرمجية API.
- ملاحظات الإصدار Release notes: إضافةً إلى الأخطاء البرمجية bugs المعروفة وذلك لإعلام المستخدمين ماذا يتوقعون في كل إصدار.
- الخصائص المخطط لها Planned features: لمتابعتها وشرح الخصائص المُخطط إضافتها لاحقًا.
- مقاطع فيديو توجيهية Video walkthroughs: لتزويد المستخدمين بنهج وسائط متعددة لاستخدام برنامجك.
قد تلائم أنواعٌ معينة من التوثيق مشروعك أكثر من غيرها، ولكن سيساعد تقديم أكثر من نهجٍ واحدٍ في البرنامج قاعدة المستخدمين لديك على فهم آلية التفاعل مع عملك بصورةٍ أفضل.
عند كتابة التوثيق أو تسجيل مقطع صوت أو فيديو، يجب أن تكون واضحًا قدر الإمكان، إذ يُستحسن ألا تضع افتراضاتٍ حول إمكانيات جمهورك التقنية، وعليك أيضًا التعامل مع التوثيق من القشرة إلى اللب، أي شرح وظائف برنامجك بصورةٍ عامة، مثل أتمتة مهام الخادم وإنشاء موقع إلكتروني وتحريك العفاريت لتطوير لعبة، قبل الخوض في التفاصيل.
أصبحت اللغة الإنجليزية لغةً عالميةً في مجال التكنولوجيا، ومع ذلك عليك دراسة هوية المستخدمين المستهدفين وكيفية الوصول إليهم؛ إذ قد تكون اللغة الإنجليزية هي الخيار الأفضل للتواصل مع قاعدة مستخدمين واسعة، لكن عليك أن تُبقي في ذهنك أن توثيقك سيكون مُوجَّهًا للعديد من الأشخاص الذين لا تكون اللغة الإنجليزية لغتهم الأم، لذا اعمل على تفضيل لغةٍ يسهل الوصول إليها ولا تربك القراء أو المشاهدين.
حاول كتابة التوثيقات كما لو كانت موجهةً إلى أحد المساهمين الذين يحتاجون إلى الاطلاع على المشروع الحالي بسرعة؛ ففي النهاية، سترغب في تشجيع المساهمين المحتملين على تقديم طلبات سحب لمشروعك.
تنظيم المشاكل
تُعد المشاكل issues عادةً طريقةً لمتابعة الزلات البرمجية أو الإبلاغ عنها، أو لطلب خصائص جديدة لإضافتها إلى الشيفرة البرمجية الرئيسية، إذ تقدم خدمات استضافة المستودعات مفتوحة المصدر، مثل غيت هَب وغيت لاب GitLab وبيت بَكيت Bitbucket واجهةً لك وللآخرين لمتابعة المشاكل ضمن مستودعك.
عند إصدار شيفرة برمجية مفتوحة المصدر للعامة، يجب أن تتوقع ظهور مشاكل يفتحها مجتمع المستخدمين، لذلك يمنحك تنظيم المشاكل وترتيب أولويتها دليلًا تفصيليًا جيدًا للعمل اللاحق في مشروعك.
يستطيع كل مستخدم تقديم قضية، وبالتالي لن تكون كل المشاكل إبلاغًا عن أخطاء برمجية أو طلبات لإضافة خصائص، فقد تتلقى مثلًا أسئلةً عبر أداة تتبع المشاكل، أو طلباتٍ لتحسينات صغيرة على واجهة المستخدم، لذلك يُستحسن تنظيم هذه المشاكل قدر الإمكان والتواصل مع المستخدمين الذين يقدمون هذه المشاكل.
ينبغي أن تمثّل المشاكل مهامًا محددة تحتاج تنفيذها على الشيفرة البرمجية المصدرية، وعليك ترتيبها حسب أولويتها وفقًا لذلك؛ كما لا بُدّ من التفاهم مع فريقك على مقدار الوقت والطاقة الذي ستكرسه أنت أو المساهمون لتطبيق المشاكل المقدَّمة، ويمكنكم التعاون معًا في اتخاذ القرارات ووضع خطة قابلة للتنفيذ؛ وعندما تعلم أنك لن تتمكن من تناول قضيةٍ معينة خلال إطارٍ زمني عاجل، علِّق على القضية لإعلام المستخدم بأنك قد اطلعت عليها وأنك ستتطرق إليها عندما تستطيع، وإذا استطعت يمكنك تزويده بالجدول الزمني المتوقع الذي يتضمن الوقت الذي سيُتاح لك فيه مراجعة القضية مجددًا.
بالنسبة إلى المشاكل التي تتضمن طلبات خصائص أو تحسينات، يمكنك أن تسأل الشخص الذي قدَّم القضية عما إذا كان قادرًا على المساهمة في الشيفرة البرمجية بنفسه، ويمكنك توجيهه إلى الملف "CONTRIBUTORS.md" وأي توثيقٍ آخر ذي صلة.
لا تمثِّل الأسئلة غالبًا مهامًا محددةً، لذلك يُعد تعليقك على القضية بتوجيه المستخدم بلطف إلى التوثيق المرتبط بسؤاله خيارًا جيدًا للمحافظة على أسلوب تواصلك احترافيًا ولطيفًا؛ وإذا لم يكن التوثيق المتعلق بهذا السؤال موجودًا، فهذا الوقت المناسب لإضافة توثيقٍ ذي صلة به والتعبير عن امتنانك للمستخدم لتنبيهك على إغفالك لهذا الجزء؛ وإذا كنت تتلقى كثيرًا من الأسئلة عبر المشاكل، ينصح أن تفكر في إنشاء قسم الأسئلة الشائعة بين ملفات توثيقك، أو ملف توثيق ويكي wiki، أو منتدى ليشارك فيه الآخرون في الإجابة على الأسئلة.
عندما يقدم المستخدم قضيةً، حاول أن تكون لطيفًا وحليمًا قدر الإمكان، فالمشكلات هي مؤشرات على إعجاب المستخدمين ببرنامجك ويريدون تحسينه.
يجعل تنظيم المشاكل قدر الإمكان مشروعك محدثًا باستمرار وعلى صلةٍ بمجتمع المستخدمين، لذلك احذف المشاكل التي تكون خارج مجال مشروعك أو التي أصبحت قديمة، وحدِّد أولوية المشاكل الأخرى حتى تتمكن من تحقيق تقدُّمٍ متواصل.
أتمتة المهام
يمكنك تحسين فعالية وجودة مشروعك عن طريق أتمتة مهام الصيانة والاختبار، إذ يمكن للصيانة والاختبار المؤتمتَين التحقُّق باستمرار من دقة شيفرتك البرمجية وتوفر عمليةٍ رسميةٍ أكثر للموافقة على عمليات تقديم المساهمين، ويساعد هذا في توفير الوقت حتى تتمكن من التركيز على الجوانب الأهم في مشروعك، ولعل الجانب الإيجابي في توفُّر كثيرٍ من الأدوات المُطوّرة فعلًا لذلك قد يلبي احتياجات مشروعك.
-
أعِدَّ الاختبار المؤتمت للمساهمات الواردة من خلال فرض عمليات تحقق من الحالة، واحرص على إضافة معلوماتٍ حول آلية عمل الاختبار لمشروعك إلى ملف "CONTRIBUTORS.md".
-
تحقق من الأدوات المُطوَّرة لأتمتة مهام الصيانة، إذ تقدِّم لك هذه الأدوات خياراتٍ متنوعة، مثل أتمتة الإصدارات الخاصة بك ومراجعة الشيفرة البرمجية، أو إغلاق المشاكل إذا لم يستجب كاتبها عند طلب معلوماتٍ منه.
أبقِ في ذهنك أن كل زائدٍ ناقص، واحرص على أن تكون العمليات والمهام التي تختار أتمتتها مدروسةً وبطرائقٍ تُحسِّن كفاءة وإنتاجية وجودة عملك ومشروعك والمساهمين فيه.
اجعل المساهمة مجزية
كلما رحبت بالمساهمين في مشروعك وكافأت جهودهم، زادت احتمالية تشجيع تلقي مساهماتٍ أكثر. ولمساعدة الأشخاص على البدء، عليك أن تضع ملف "CONTRIBUTORS.md" في أعلى مستوى top-level من المستودع الخاص بك، ومؤشرٌ على مكان هذا الملف في ملف "README.md".
ستحدّد سمات ملف المساهمة النافع طريقة بدء المطور في العمل على المشروع، وتقديم دليلٍ مفصَّل أو قائمة تحقق يتّبعها المطورون، تشرح كيف ينجحون في دمج شيفرتهم البرمجية في المشروع من خلال طلب السحب.
لاتنسَ بعد إضافة توثيقٍ حول طريقة المساهمة في المشروع، أن تحافظ على تناسق كامل شيفرتك البرمجية وقابليتها للقراءة، إذ ستسهم الشيفرة البرمجية التي يسهل فهمها من خلال إضافة تعليقاتٍ إليها واستخدامها الواضح والمتناسق إسهامًا كبيرًا في منح المساهمين الإحساس بأنهم يستطيعون المشاركة في المشروع.
وختامًا، أبقِ قائمةً بالمساهمين والكتاب لديك، كما يمكنك أن تدعو المساهمين إلى إضافة أنفسهم إلى هذه القائمة مهما كانت مساهماتهم (حتى تصحيح الأخطاء الإملائية يُعَد مساهمةً مهمةً، وقد تقود إلى مساهمات أكبر لاحقًا). يتيح هذا الأسلوب إبراز المساهمين وعملهم على المشروع للجميع بحيث يستطيعون الإشارة إليه، وجعل الجميع يعي قدر المعاملة الحسنة التي يتلقاها المساهمون.
بناء مجتمعك
يعني تمكينك للمستخدمين من خلال إضافتك للتوثيق، وتجاوبك مع المشاكل، وتشجيع المستخدمين على المشاركة، أنك تسير على الطريق الصحيح نحو بناء مجتمعٍ حول مشروعك مفتوح المصدر، إذ سيروِّج المستخدمون الذين تحرص على إسعادهم وتعاملهم على أنهم مساهمون لبرنامجك بدورهم.
إضافةً إلى ما سبق، يمكنك العمل على الترويج لمشروعك بعدة أساليب:
- التدوين Blogging.
- إصدار مقاطع فيديو للمراجعة walkthrough أو متضمنةً لمحةً عامةً عن المشروع.
- حفظ قائمة بحسابات بريد إلكتروني.
- كن نشطًا على قنوات وسائل التواصل الاجتماعي.
- التعاون مع مطوري مشاريع مشابهة لمشروعك أو مرتبطةً به وتحقيق الترويج المتبادل بينهما.
عليك تصميم أسلوبك الترويجي وفقًا لمجال مشروعك وعدد أعضاء الفريق والمساهمين النشطين الذين يعملون معك؛ وكلما توسع مجتمعك، يمكنك توفير مساحات أكبر يتفاعل ضمنها المساهمون والمستخدمون والمشرفون. إليك بعض الخيارات التي قد تنظر في تطبيقها:
- ملفات توثيق ويكي، التي تقدم توثيقًا يُحفَظ في متناول المجتمع.
- منتديات لمناقشة الخصائص المحتمَلة والإجابة على الأسئلة.
- خادم قوائم بريدية للمشاركة المجتمعية المعتمدة على البريد الإلكتروني.
ادرس قاعدة المستخدمين الأساسية لديك ومجال مشروعك (وهذا يشمل عدد الأشخاص الذين يعملون على الإشراف على المشروع والموارد المتاحة لديك) قبل نشر هذه المساحات المحتمَلة؛ واِسعَ للحصول على آراء مجتمعك حول ما يناسبهم؛ وقبل كل شيء، لا بد أن تكون لطيفًا وأن تُظهر بعض المودة في جميع تفاعلاتك مع مجتمعك. قد يصعب أن تتسم بالحلم عندما تؤدي دور المشرف، لكن ذلك سيؤتي ثماره على مشروعك في المستقبل.
الخاتمة
يؤدي المشرفون على المستودعات دورًا بالغ الأهمية ضمن المجتمع مفتوح المصدر العام، وعلى الرغم أن ذلك يتطلب استثمارًا ضخمًا وعملًا شاقًا، إلا أنه يكون غالبًا تجربةً مجزيةً تتيح لك النمو بصفتك مطورًا ومساهمًا، كما يمكن أن يساهم تأديتك لدور المشرف بودٍ ولطف مساهمةً كبيرةً في تطوير المشروع الذي تهتم به.
ترجمة -وبتصرف- للمقال How To Maintain Open-Source Software Projects لصاحبته Lisa Tagliaferri
أفضل التعليقات
لا توجد أية تعليقات بعد
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.