يرغب الكثير من أصحاب المعرفة الشرعية أو حتى أصحاب الوقت والقادرين على التجربة والاختبار وأصحاب الأفكار المميزة بالمساهمة في المشاريع البرمجية مفتوحة المصدر أو إيصال أفكارهم للمطورين، لكن لا يعرف الكثير منهم الطريقة الأمثل لفعل هذا، لذا قررت كتابة موضوع سريع حول هذا الأمر يوضح: كيف يمكنك استخدام غيتهب لتوصل أفكارك للمطورين بأفضل شكل ممكن
لنبدأ أولاً بحديث صغير حول غيتهب:
غيتهب منصّة تجمع المبرمجين لحفظ ومشاركة مشاريعهم البرمجية مع الآخرين، وظيفتها الأساسية حفظ الكود وتتبع نُسخه والتعديلات عليها، لكن فيها وظائف ثانوية كثيرة تسهّل عمل المطوّرين، أهمّ ما عليك معرفته منها ميزتان رئيسيّتان سأسلط الضوء عليهما:
- الـ Issues أو المشاكل: وفيها يمكن للمطور متابعة المشاكل والمقترحات حول البرنامج الذي يعمل عليه
- الـ Projects أو المشاريع: وفيها يمكن للمطور عرض قائمة المهام التي يعمل عليها وأولويتها بالنسبة له
باستخدام هاتين الميزتين يمكنك كشخص قادم من الخارج فهم حالة المشروع، وخطة المطور للعمل عليه، والاقتراحات والمشاكل السابقة التي وصلته وردوده عليها.
باختصار: الـIssues مثل نظام متابعة للمشاكل والتواصل مع المستخدمين والمطورين الآخرين، بينما الـProjects نظام مثل trello أو اي نظام بطاقات مهام آخر لترتيب المهام.
عندما تخطر لك فكرة المساهمة في مشروع مفتوح المصدر، فإن أول ما عليك فعله هو الدخول لهذين القسمين وتصفح ما الموجود فيهما:
في قسم Issues المفتوحة سترى ما وصل للمطور من ملاحظات وقد يكون أضاف المطور نفسه بعض الـIssues التي يرغب بالعمل عليها مستقبلاً ليخبرك أنّه على علم بهذه المشكلة أو بهذا المقترح
وفي قسم Issues المغلقة، يمكنك النظر في المقترحات المرفوضة أو التي تم تنفيذها بالفعل
بنظرة سريعة هنا، يمكنك فهم حالة المشروع.
أما بالنسبة للـProjects فهي أقلّ شيوعاً واستخداماً لوجود أدوات أكثر قوّة من تلك المتوفرة في غيتهب، وعادةً ما تستخدم لتنظيم الـIssues الموجودة بالفعل في قوائم مهام.
كيف أضيف الـIssue الخاصّة بي؟
لا تستعجل في إضافة Issue إلى القائمة فور دخولك لمستودع المشروع، هذه بعض العادات -والإيتيكيت- في التعامل مع المشاريع مفتوحة المصدر التي سيقدّر المطوّر جداً لو قمت بها:
انظر في الـIssues المفتوحة والمغلقة، يمكنك إجراء بحث سريع لترى لو طرح أحد مشكلتك من قبل.
في بعض المستودعات، هناك قالب جاهز للـIssues ومن الأفضل الالتزام به، حيث يطلب المطوّر معلومات محددة تساعده على تكرار الخطأ محلياً وإصلاحه.
في حال عدم وجود قالب جاهز إليك هذه التفاصيل التي من الضروري مشاركتها مع المطور كقاعدة عامّة:
ماهو الخطأ الحاصل: عليك صياغة هذا على شكل "ما يحصل الآن" ثم "ما كان يجب حصوله"
كيف يمكن للمطور تكرار الخطأ: صغ هذا بشكل خطوات "انقر هنا، ثم انقر هنا، ثم انقر هنا، وسيحصل ما يلي"
ما هي ظروف التشغيل البرمجية: في حال كان موقعاً (ما هو المتصفح المستخدم؟ أي إصدار؟ وعلى أي نظام تشغيل؟) و في حال كان برنامجاً (ما هو نظام التشغيل؟ وما هي مواصفات العتاد المستخدم في تشغيله؟) ولو كان هاتفاً (ما اسم الطراز؟ وهل هناك أي تعديلات أو إعدادات خاصة على الجهاز؟)
ملفات السجلات: خصوصاً لو كان هناك طريقة سهلة للوصول لها من التطبيق أو صور الشاشة التي تساعد على فهم المشكلة خصوصاً لو كانت مشكلة بصرية.
إضافة لكل هذا، تذكّر أن المطور يعمل على هذا المشروع ويتيح مصدره مفتوحاً ليساهم بنشر العلم والفائدة غالباً كمشروع شغف جانبيّ وليس كمشروع رئيسيّ ومصدر دخل، لذا عند التبليغ عن مشكلة خطيرة أو ذات حساسية أمنية، من الأفضل التواصل معه على الخاص قبل نشرها على العام ليتاح للناس استغلالها.
تذكر أيضاً أنّه شخص حقيقي خلف الشاشة، لذا اكتب بلطف وأدب، ولا تطالبه بمطالبة فظّة، كثير من الناس تكتب للمطورين في المشاريع مفتوحة المصدر وكأنّهم موظّفون عندهم، هذا ينفّر الكثير من الاهتمام بمشاريعهم.
وفي الختام: تابع مع المطوّر وحاول الإجابة على أسئلته وردوده على الـIssue التي فتحتها واقترحتها، فهكذا يمكنه العمل عليها وإنجازها أو إصلاحها
