مقدمة
عندما بدأت المساهمة في مشاريع مفتوحة المصدر، كنت أظن أن الجزء الأصعب سيكون كتابة الكود. مع الوقت، اكتشفت أن الكود ليس سوى جزء من التجربة.
الخبرة العملية
من خلال مساهماتي في مشاريع مختلفة، من بينها RATQ ومشاريع أخرى ضمن مجتمع Itqan، تعاملت مع:
• Issues حقيقية
• مناقشة نطاق العمل مع Maintainers
• كتابة اختبارات
• متابعة CI/CD
• التعامل مع Code Reviews وملاحظات أدوات مثل CodeRabbit
• تحليل أخطاء لم يكن سببها دائمًا الكود الذي كتبته
وهنا بدأت نظرتي إلى هندسة البرمجيات تتغير.
التحدي الأول: معرفة ما الذي يجب تغييره
في المشاريع الشخصية، لديك حرية كبيرة في تغيير المعمارية أو إعادة كتابة جزء كامل من التطبيق. في Open Source الوضع مختلف.
أنت تدخل إلى Codebase بناه أشخاص آخرون، وله قرارات معمارية وتاريخ وقيود لا تظهر دائمًا من النظرة الأولى.
لذلك أصبح السؤال بالنسبة لي ليس فقط: "كيف أنفذ هذه الـ Feature؟" بل: "ما أصغر تغيير يمكن أن يحل المشكلة دون التأثير على بقية النظام؟"
هذا المفهوم، الحفاظ على Atomic Scope، أصبح من أهم الأشياء التي تعلمتها من مساهماتي.
مثال من RATQ
في إحدى مساهماتي، كان المطلوب إضافة Edge Cache لمعاينات مستودعات GitHub. كان من السهل تحويل المهمة إلى Refactoring أكبر، لكن التحدي الحقيقي كان العكس: تنفيذ المطلوب، الحفاظ على السلوك الموجود، إضافة الاختبارات اللازمة، وعدم لمس ما لا يحتاج إلى تغيير.
ما بعد كتابة الكود
من أكثر الأشياء التي تغيرت في طريقة عملي أنني لم أعد أعتبر نجاح التنفيذ محليًا نهاية المهمة.
الأسئلة الجديدة بعد الكود:
• هل الاختبارات تغطي السلوك الحقيقي؟
• هل التغيير كسر شيئًا موجودًا؟
• هل الـ Diff يحتوي فقط على الملفات التي يجب أن تتغير؟
• ماذا تقول نتائج CI؟
• وهل كل Finding من أدوات التحليل يمثل مشكلة فعلية؟
خلال مساهماتي، أصبحت هذه المرحلة أحيانًا أطول وأكثر فائدة من مرحلة كتابة الكود نفسها.
قراءة نتائج CI بشكل صحيح
اللون الأحمر في CI لا يعني دائمًا أن الكود خاطئ.
خلال إحدى المساهمات ظهرت Checks فاشلة في GitHub Actions. كان من السهل افتراض أن التغيير الذي قدمته هو السبب. لكن قراءة الـ Logs أظهرت شيئًا مختلفًا تمامًا:
• أحد الـ Workflows كان يحاول إضافة Label لكنه حصل على: 403 Resource not accessible by integration
• Workflow آخر خاص بإشعارات Slack فشل لأن الـ Token أو Webhook لم يكن متاحًا
المشكلة لم تكن في منطق الـ Feature أصلًا.
هذا النوع من المواقف علمني ألا أتعامل مع CI كإشارة Pass/Fail فقط، بل كأداة تشخيص يجب فهم ما تقوله فعلًا.
استخدام أدوات الذكاء الاصطناعي بحكمة
أدوات الذكاء الاصطناعي تساعدني، لكنها لا تتخذ القرار بدلاً مني.
جزء مهم من تجربتي في Open Source كان استخدام AI Agents وأدوات المراجعة الآلية أثناء التطوير. هذه الأدوات مفيدة جدًا في:
• تحليل Diff
• اقتراح Tests
• اكتشاف مشاكل محتملة
• مساعدتي في فهم Failure أو Review Comment بسرعة أكبر
لكنني تعلمت أيضًا ألا أتعامل مع مخرجاتها كحقيقة نهائية.
الأسئلة التي أطرحها عند تلقي تحليل آلي:
• هل الـ Finding صحيح فعلًا؟
• هل يمكن إثبات المشكلة من خلال مسار التنفيذ؟
• هل الإصلاح المقترح يحسن الكود؟
• هل يمكن أن يسبب Regression؟
• وهل التغيير أصلًا داخل Scope المساهمة؟
في بعض الحالات أصلحت الـ Finding، وفي حالات أخرى كان القرار الصحيح هو عدم تغيير الكود. وهذا فرق مهم بين استخدام AI لكتابة الكود، واستخدامه كأداة ضمن عملية هندسية يقودها الإنسان.
الـ Code Review ليس امتحانًا
في البداية، يمكن أن تبدو ملاحظات Maintainer أو CodeRabbit وكأنها قائمة أخطاء يجب التخلص منها حتى تصبح الـ PR خضراء. لكن مع تكرار التجربة تغيرت نظرتي.
أصبحت أرى الـ Review كحوار هندسي:
• أحيانًا يكون الـ Reviewer قد اكتشف مشكلة حقيقية
• أحيانًا يحتاج اقتراحه إلى تعديل
• وأحيانًا يكون أفضل قرار هو شرح سبب الإبقاء على الكود كما هو
الهدف ليس الوصول إلى صفر ملاحظات بأي ثمن. الهدف أن يكون التغيير صحيحًا، مفهومًا، قابلًا للصيانة، ويحترم المشروع الذي سيعيش داخله.
أكثر ما تعلمته لم يكن تقنية جديدة
بالتأكيد تعلمت أشياء تقنية خلال مساهماتي: Git، الاختبارات، caching، التعامل مع APIs، CI/CD، إدارة الفروع، Rebase، حل التعارضات، وقراءة Codebases لم أكتبها بنفسي.
لكن القيمة الأكبر كانت في طريقة التفكير:
• أن أقرأ قبل أن أعدل
• أن أحدد الـ Scope قبل أن أكتب الكود
• أن أبحث عن Root Cause قبل أن أصلح Error
• أن أراجع اقتراح الـ AI قبل تنفيذه
• وأن أتذكر دائمًا أن الكود الذي أضيفه لن يبقى ملكي؛ سيقرأه ويعدله ويعتمد عليه أشخاص آخرون
التقدير والامتنان
سعدت بأن بعض هذه المساهمات حظيت بتقدير مجتمع Itqan، ومنها إدراج مساهماتي في RATQ ضمن Contributors' Hall of Fame.
لكن القيمة الحقيقية بالنسبة لي ليست في عدد الـ Pull Requests. القيمة في أن كل مساهمة جعلتني أخرج بفهم أفضل قليلًا لكيفية بناء البرمجيات مع الآخرين.
جزى الله خيرًا كل Maintainer راجع مساهمة، كتب ملاحظة، شرح قرارًا، أو أعطاني فرصة للعمل على Issue، وخصوصًا @abubakr-itqan وفريق Itqan على البيئة المشجعة للمساهمة والتعلم.
نصيحة أخيرة
إذا كنت تنتظر حتى تشعر بأنك جاهز تمامًا للمساهمة في Open Source، فربما ستنتظر طويلًا.
اختر Issue تستطيع فهمها.
اقرأ الكود.
اسأل عندما يكون الـ Scope غير واضح.
ابدأ بتغيير صغير.
افتح الـ PR.
ثم دع الـ Review والـ CI والأخطاء والنقاشات تعلمك ما لا يمكن لأي Tutorial أن يعلمك إياه.
بالنسبة لي، هذه المساهمات ليست إنجازًا انتهى. هي بداية طريقة مختلفة في التعلم والعمل كمهندس برمجيات.
