ملفي الشخصي على GitHub كان مهجوراً: كيف أنقذتني ‘المساهمات في المصادر المفتوحة’ من جحيم السيرة الذاتية الفارغة؟

أذكر ذلك اليوم جيداً. كنت في مقابلة عمل لوظيفة أحلم بها، مقابلة تقنية بحتة. الأمور كانت تسير على ما يرام، أجبت عن الأسئلة الخوارزمية، وتحدثت عن مشاريعي في الشركة السابقة بثقة. ثم جاء السؤال الذي كنت أخشاه: “ممتاز يا أبو عمر، ممكن نشوف ملفك الشخصي على GitHub؟”.

في تلك اللحظة، شعرت بقطرة عرق باردة تسيل على جبيني. فتحت الحاسوب المحمول ببطء، وكأنني أفتح صندوقاً ملعوناً. ظهر ملفي الشخصي على الشاشة: صورة باهتة، بضعة مستودعات (repositories) خاصة بمشاريع التخرج من سبع سنين، وتقويم المساهمات الأخضر كان… أبيض بالكامل. صحراء قاحلة ليس فيها أي أثر للحياة. نظرت إلى وجه المحاور فرأيت خيبة أمل مهذبة. لم يقل شيئاً، لكن نظراته قالت كل شيء: “أين الكود؟ أين الشغف؟ أين الدليل على أنك تتنفس البرمجة خارج ساعات الدوام؟”.

خرجت من تلك المقابلة وأنا أعلم أنني لن أحصل على الوظيفة. لم يكن السبب نقص خبرتي، بل نقص “الدليل” على هذه الخبرة. كانت سيرتي الذاتية تقول “خبير”، لكن ملفي على GitHub كان يصرخ “هاوٍ”. كانت تلك الصفعة التي أحتاجها لأستيقظ من سباتي الرقمي.

لماذا كان ملفي على GitHub مقبرة للمشاريع القديمة؟

قبل أن أروي لكم كيف تغير كل شيء، دعونا نتحدث بصراحة. حالتي لم تكن فريدة من نوعها. الكثير من المطورين، حتى المحترفين منهم، يملكون ملفات GitHub مهجورة. والأسباب غالباً ما تكون واحدة من هذه:

• العمل في شركات مغلقة المصدر: معظمنا يعمل في شركات، وكودنا الذي نكتبه يومياً هو ملكية خاصة للشركة. لا يمكننا ببساطة نشره على حساباتنا الشخصية. وهذا يخلق فجوة كبيرة بين حجم عملنا الفعلي وما يظهر للعلن.
• متلازمة المحتال (Impostor Syndrome): ذلك الصوت الخبيث في رأسك الذي يهمس: “الكود تبعك مش نظيف كفاية”، “الناس رح تضحك على طريقتك في الحل”، “شو بدك بهالشغلة، خليك مستور”. هذا الخوف من النقد يمنعنا من مشاركة أي شيء.
• حجة “ما عندي وقت”: بين ضغط العمل، ومسؤوليات الحياة، من أين نأتي بالوقت لبناء مشروع شخصي ضخم من الصفر؟ هذه حجة منطقية جداً، ولكنها أيضاً فخ نقع فيه بسهولة.
• الضياع وعدم معرفة البداية: حسناً، قررت أن تنشط ملفك. ماذا بعد؟ هل تبني “فيسبوك” جديد؟ أم تبني مكتبة الذكاء الاصطناعي التي ستغير العالم؟ الشعور بالضخامة هذه يسبب شللاً تحليلياً (Analysis Paralysis).

المصادر المفتوحة: طوق النجاة الذي لم أكن أتوقعه

بعد فشلي في المقابلة، قضيت أياماً أفكر في حل. فكرة بناء مشروع ضخم من الصفر كانت مرهقة ومستحيلة في ظل عملي. وهنا، وكأنها إشارة من السماء، قرأت مقالاً عن “المساهمة في المصادر المفتوحة”.

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

المصادر المفتوحة (Open Source) هي مشاريع برمجية متاحة للجميع، يمكن لأي شخص الاطلاع على الكود المصدري الخاص بها، استخدامه، تعديله، والمساهمة في تطويره. هذا هو الحل السحري لمشكلة “السيرة الذاتية الفارغة”. أنت لا تبدأ من الصفر، بل تنضم إلى مجتمع قائم، وتضيف لمستك على مشروع يستخدمه الآلاف أو حتى الملايين.

خطواتي الأولى في عالم المصادر المفتوحة: دليل عملي للمبتدئين

قررت أن أخوض التجربة. في البداية، كان الأمر مربكاً، ولكن مع قليل من الصبر والبحث، بدأت الأمور تتضح. إليكم خارطة الطريق العملية التي اتبعتها، والتي أنصح بها كل من يريد أن يبدأ.

الخطوة الأولى: العثور على المشروع المناسب

هذه أهم خطوة. اختيار المشروع الخطأ قد يسبب لك الإحباط. إليك كيف وجدت مشروعي الأول:

• ابدأ بما تستخدمه: فكر في المكتبات، أطر العمل، أو الأدوات التي تستخدمها يومياً في عملك أو مشاريعك الصغيرة. هل هناك مكتبة JavaScript تحبها؟ إطار عمل Python تعتمد عليه؟ المساهمة في شيء تستخدمه بالفعل تمنحك حافزاً أكبر.
• استخدم محركات البحث المخصصة: مواقع مثل GoodFirstIssue.dev و CodeTriage ممتازة، فهي تجمع الـ “Issues” (المشاكل أو المهام) التي قام أصحاب المشاريع بتعليمها كـ good first issue (مهمة أولى جيدة)، وهي مهام بسيطة ومناسبة للمبتدئين.
• بحث GitHub المتقدم: يمكنك البحث مباشرة على GitHub عن وسوم مثل label:"good first issue" أو label:help-wanted مع تحديد لغة البرمجة التي تفضلها.

نصيحة من أبو عمر: بلّش صغير يا خوي. أنا بدأت بمشروع توثيق لمكتبة رسوم بيانية كنت أستخدمها. وجدت خطأ إملائياً بسيطاً في صفحة الأمثلة. نعم، مجرد خطأ إملائي! كانت هذه هي بوابتي للدخول.

الخطوة الثانية: فهم قواعد اللعبة

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

• README.md: هذا هو الملف الترحيبي الذي يشرح المشروع.
• CONTRIBUTING.md: هذا هو الأهم. يشرح لك بالتفصيل كيفية المساهمة، أسلوب الكود المتبع، كيفية تشغيل الاختبارات، وكل ما تحتاجه لتقديم مساهمة ناجحة.
• CODE_OF_CONDUCT.md: يوضح قواعد السلوك والتواصل داخل مجتمع المشروع.

تجاهل هذه الملفات هو أسرع طريق لرفض مساهمتك (Pull Request).

الخطوة الثالثة: مساهمتك الأولى (مثال عملي)

لنفترض أننا وجدنا خطأً إملائياً في ملف README.md لمشروع ما. كيف نصلحه؟ العملية تسمى دورة “Fork & Pull Request”، وهي كالتالي:

1. اعمل Fork للمشروع: اذهب إلى صفحة المشروع على GitHub واضغط على زر “Fork” في أعلى اليمين. هذا سينشئ نسخة كاملة من المشروع على حسابك الشخصي.
2. انسخ (Clone) المشروع إلى جهازك:

   git clone https://github.com/your-username/project-name.git
   cd project-name

3. أنشئ فرعاً جديداً (Branch) لعملك: من أفضل الممارسات أن تقوم بكل تغيير في فرع منفصل. هذا يحافظ على نظافة عملك.

   git checkout -b fix/readme-typo

4. قم بالتعديل المطلوب: افتح ملف README.md في محرر الأكواد المفضل لديك، وأصلح الخطأ الإملائي.
5. أضف التغييرات وقم بعمل Commit:

   # أضف الملف الذي عدلته إلى منطقة التجهيز
   git add README.md
   
   # قم بعمل commit مع رسالة واضحة تصف ما فعلته
   git commit -m "docs: Fix a typo in the introduction section"

   ملاحظة: كتابة رسالة commit جيدة هي فن بحد ذاته. اتبع الأسلوب المعتمد في المشروع.

6. ارفع (Push) التغييرات إلى نسختك (Fork):

   git push origin fix/readme-typo

7. افتح طلب سحب (Pull Request): الآن اذهب إلى صفحة نسختك من المشروع على GitHub. ستجد زراً يقترح عليك عمل “Pull Request”. اضغط عليه، اكتب عنواناً واضحاً ووصفاً جيداً يشرح تغييرك، ثم أرسله.

وهكذا تكون قد قدمت أول مساهمة لك! الآن عليك الانتظار حتى يقوم أحد مشرفي المشروع بمراجعة عملك. قد يطلبون تعديلات، أو قد يدمجونه مباشرة. في كلتا الحالتين، أنت تتعلم وتتطور.

الخطوة الرابعة: ما بعد المساهمة الأولى

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

• تحسين التوثيق (Documentation): إضافة أمثلة، شرح أجزاء غامضة، أو حتى ترجمة التوثيق إلى لغات أخرى.
• إصلاح الأخطاء البرمجية (Bug Fixes): ابحث عن الـ Issues التي تحمل وسم bug.
• مراجعة أكواد الآخرين (Code Review): قراءة مساهمات الآخرين وتقديم ملاحظات بناءة هي طريقة ممتازة للتعلم.
• إضافة ميزات جديدة (New Features): هذه خطوة متقدمة تتطلب نقاشاً مع مشرفي المشروع أولاً.

كيف حوّلت المساهمات ملفي الشخصي من أرض قاحلة إلى حديقة غنّاء؟

خلال أشهر قليلة من اتباع هذه الاستراتيجية، تغير ملفي الشخصي على GitHub بشكل جذري:

• التقويم الأخضر: تلك المربعات البيضاء بدأت تتحول إلى درجات متفاوتة من اللون الأخضر. لم يعد ملفي يبدو مهجوراً، بل أصبح دليلاً على نشاطي المستمر.
• مهارات عملية حقيقية: تعلمت استخدام Git و GitHub كالمحترفين، وليس فقط كأداة لحفظ الكود. فهمت معنى الـ rebase، والـ cherry-pick، وكيفية التعامل مع النزاعات (conflicts) في الكود.

– هوية تقنية واضحة: أصبحت مساهماتي تظهر في مشاريع معروفة في مجال الذكاء الاصطناعي وعلوم البيانات. أي شخص يزور ملفي الآن يرى فوراً مجالات اهتمامي وخبرتي.

• الثقة بالنفس: عندما ترى الكود الخاص بك يُدمج في مشروع يستخدمه الآلاف، تشعر بإنجاز حقيقي يمحو “متلازمة المحتال”.
• مقابلات عمل مختلفة تماماً: في المقابلات التالية، عندما كان يُطرح سؤال GitHub، كنت أفتحه بفخر. لم يعد مجرد مستودع، بل أصبح قصة تروي شغفي وتعاوني وقدرتي على التعلم وحل المشكلات في بيئة عمل حقيقية.

خلاصة الحكي ونصيحة من القلب

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

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

ملفك الشخصي على GitHub هو قصتك، فتأكد من أنك تروي قصة جيدة. يلا شدّوا حيلكم! 💪