كيف تحوّل مساهماتك على GitHub إلى سيرة ذاتية يقرأها المُوظِّفون فعلًا

لصق رابط GitHub في أسفل سيرتك الذاتية ليس دليلًا. إنه واجب منزلي تكلّف به مسؤول توظيف يراجع مئة طلب ولن يفتحه. (أما لماذا يطلبونه رغم ذلك فسؤال منفصل — وهذا المقال هو الجانب العملي.)

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

ما الذي يمكن أن يقوله النشاط العام فعلًا

من الخارج، يدعم حساب GitHub العام مجموعة ضيّقة لكن مفيدة فعلًا من الادّعاءات:

• اللغات التي تكتب بها، مُرجَّحة بحجم ما تكتبه. تُقاس بحجم الشيفرة عبر مستودعاتك غير المنسوخة (non-fork) — وهي إشارة أفضل بكثير من قائمة مهارات تُصرّح بها بنفسك، لأنك لا تستطيع حشوها.
• الاستمرارية. نشاط الالتزامات (commits) خلال السنة الأخيرة يفرّق بين مساهم منتظم وحساب نشِط لفترة واحدة قبل ثلاث سنوات.
• نطاق العمل. كم مستودعًا عامًا تملك، وما هي.
• التلقّي. النجوم والنسخ (stars و forks)، وتشير إلى أن آخرين وجدوا شيئًا مفيدًا — مع التحفّظ المذكور أدناه.

هذه هي القائمة الصادقة. وهي لا تشمل جودة الشيفرة، ولا مهارة العمل الجماعي، ولا مستوى الأقدمية. ومن يدّعي قراءة هذه من صفحة ملف شخصي فهو يخمّن.

استورده بدل أن تكتبه

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

أمران يستحقان المعرفة عن آليته:

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

صُغه كخبرة لا كإحصاءات

تمنحك البنود المستوردة مادة خامًا دقيقة. وإعادة الصياغة هي ما يجعلها مُقنِعة. فالعدد المجرّد ضعيف:

24 مستودعًا عامًا على GitHub.

اربط الحقيقة نفسها بلغة وغرض وإطار زمني:

أُشرِف على 24 مستودعًا عامًا، أغلبها Python و Go، منها أداة سطر أوامر لتحليل السجلات دفعيًا يستخدمها نحو 40 مطوّرًا؛ مع التزامات نشطة على مدى الاثني عشر شهرًا الأخيرة.

كلاهما صحيح. لكن الثاني يجيب عمّا يسأل عنه المُوظِّف فعلًا: ماذا تبني، وبأي أدوات، وهل تواظب؟

وهذه قواعد صياغة تصمد:

• ابدأ باللغة والغرض لا بالعدد.
• اذكر مستودعك الأوثق صلة بالوظيفة لا الأكثر نجومًا. الصلة تتفوّق على الشهرة.
• قل "مستودعات عامة" — فهي دقيقة، وتشير ضمنًا إلى وجود عمل آخر غير عام.
• لا توحِ أبدًا بأن النجوم تعني الاعتماد الفعلي. إنها تعني الظهور.

كن صادقًا فيما يفوته

هذا مهم للمصداقية، وهو يحميك في المقابلة:

• العمل الخاص والمؤسسي غير مرئي. لا تراه واجهة GitHub العامة، فلا يمكن استيراده. وإذا كان أقوى أعمالك خاصًّا، فقُل ذلك في سطر مستقل — فهذا وضع طبيعي ومتوقّع لكل من عمل داخل مؤسسة.
• عدد الالتزامات ليس إنتاجية. فهو يعكس أسلوب الالتزام بقدر ما يعكس المُخرَج. استخدم النشاط لإظهار الانتظام، لا للإيحاء بحجم القيمة المُنجَزة.
• السنة الخالية ليست ثغرة في القدرة. كثير من المهندسين البارعين لا يكتبون شيفرة عامة. لا تصطنع نشاطًا لملء الرسم البياني؛ فمن يفهم الإشارة يفهم غيابها أيضًا.
• المستودعات المنسوخة (forks) مُستبعَدة من حساب اللغات، عن قصد — فنسخ مشروع شخص آخر ليس دليلًا على أنك كتبته.

أين موضعه في السيرة

لا تُنشئ قسمًا مستقلًّا باسم "GitHub". ضع الدليل حيث ينظر القارئ أصلًا:

• أقوى بند أو بندين يدخلان ضمن أوثق خبرة أو مشروع لديك صلةً بالوظيفة.
• اللغات تنضمّ إلى قسم المهارات، مصوغة كما يسمّيها الوصف الوظيفي — وهو الانضباط نفسه الذي يغطّيه دليل كلمات Cloud/DevOps المفتاحية.
• رابط الملف يوضع في كتلة بيانات الاتصال، كنصٍّ صريح — لا كصورة أو أيقونة فقط، فكثير من أدوات التحليل تُسقطها تمامًا.

وبعد إدراج بنودك، مرّر النتيجة على مدقّق تقييم ATS للتأكد من أن السيرة كاملةً ما زالت تُحلَّل بوضوح وتغطّي الكلمات المفتاحية التي يتوقّعها الدور المستهدف. فالدليل لا ينفع إلا إذا استطاع النظام قراءته.