تطوير البرمجيات يبدأ دائماً بسؤال: ما المشكلة؟ لماذا تهمّنا؟ وكيف نعرف أننا انتهينا؟ على GitHub، الجواب يتشكّل في Issue. مهما كانت أدواتك ومهما كان فريقك، الـ Issue الجيد هو الذي يحدد مسار الـ PR والمراجعة والاختبار والنشر. في هذا الدرس ستتعلم كيف تكتب Issues بشكل صحيح، وكيف تُحوّلها إلى Draft PRs تلقائياً مع Copilot.
١. لماذا Issues وPull Requests أساس العمل؟
أربع فوائد أساسية لكل Issue وPR مبنيَّين بشكل صحيح:
- سياق مشترك — رابط واحد يحمل وصف المشكلة وخطوات الإعادة وتعريف "الانتهاء". أي شخص يلتحق بعد أسبوع أو بعد سنة يفهم ما جرى في دقائق. وكما يُقال في GitHub: إذا لم يكن له رابط، فهو لم يحدث.
- تنسيق غير متزامن (Async) — لا حاجة لاجتماعات متكررة. المطورون يعملون كل في وقته دون توقف.
- تتبع وتحليل — التسميات والمراحل والقوالب تُغذّي لوحات المتابعة والإبلاغ الامتثالي.
- خطّافات الأتمتة — سير عمل Actions، لوحات المشاريع، والأدوات الذكية تعتمد على بيانات وصفية منتظمة في كل issue.
Issue #12609: وجدتُ رابطاً مكسوراً. الرجاء الإصلاح!
لا وصف، لا رابط، لا سياق، لا بيئة، لا مثال. هذا يُوقف أي مطور — أو أي ذكاء اصطناعي — في منتصف الطريق.
٢. تشريح الـ Issue المثالي
استخدم هذه القائمة عند كتابة أي issue أو مراجعته:
| العنصر | الوصف | مثال |
|---|---|---|
| عنوان يبدأ بفعل | اذكر الاسم أولاً ثم المشكلة |
✅ "زر تسجيل الدخول — تعطيل على Safari 17" ❌ "مشكلة في تسجيل الدخول؟" |
| المشكلة أو قصة المستخدم | اعرض الألم من منظور المستخدم | "كمتسوّق، لا أستطيع الضغط على زر الشراء في Safari للجوال فأتركُ السلة." |
| السلوك المتوقع مقابل الفعلي | نقطتان واضحتان | "المفترض: زر أساسي · الواقع: الزر غير قابل للنقر، لا يوجد pointer-events في CSS." |
| خطوات الإعادة أو دليل مرئي | صور، GIFs، أوامر terminal | لقطة شاشة أو تسجيل مختصر للمشكلة |
| معايير القبول / تعريف "الانتهاء" | شروط واضحة لإغلاق الـ issue | "كل الاختبارات تمر · نقاط Lighthouse > 90 · حذف feature flag" |
| النطاق والقيود | حدود واضحة لمنع التشعّب | ميزانية الأداء، قائمة المتصفحات، لا dependencies جديدة |
| البيانات الوصفية | تسميات، منفّذ، مرحلة، مشروع | يُشغّل اللوحات والفلاتر وإشعارات Slack |
٣. كيف تكتب Issues أسرع مع Copilot
بدلاً من التنقّل بين الحقول ونسخ النصوص، افتح github.com/copilot واكتب وصفاً بلغتك العادية:
"أنشئ تقرير خطأ عن خطأ 500 في نموذج تسجيل الدخول في octo-org/octo-web."Copilot يُنشئ العنوان والوصف ويقترح التسميات والمنفّذ — مع الالتزام بقالب المستودع الخاص بك تلقائياً.
الخطوات بالتفصيل
- افتح Copilot Chat Immersive View على github.com/copilot
- صِف ما تحتاجه، واذكر المستودع (
org/repo) أو دع Copilot يستنتجه - أرفق لقطة شاشة إن أرادت الصورة أكثر من الكلمات — Copilot سيُضمّنها في الـ issue تلقائياً
- راجع المسودة: أضف تعليقاً ("أضف خطوات الإعادة"، "استخدم قالب البلاغ عن خطأ") أو عدّل الـ Markdown مباشرة
- اضغط Create عندما يبدو صحيحاً
يمكنك في نفس المحادثة طلب إنشاء أكثر من issue دفعةً واحدة — مفيد جداً وقت فرز الأخطاء (Triage).
ماذا تفعل وكيف يساعد Copilot؟
| ما تفعله | كيف يساعد Copilot | لماذا يهم |
|---|---|---|
| ابدأ بالسياق (متوقع/فعلي، خطوات الإعادة) | يُحلّل صياغتك ويضعها في أقسام القالب الصحيحة | زملاؤك (أو Copilot) يفهمون على الفور |
| أرفق دليلاً (صور، سجلات) | يحفظ الملف ويُضمّنه في نص الـ issue | من يُصلح المشكلة لاحقاً يرى ما رأيتَ بالضبط |
| أضف الإجراء التالي ("اسند لـ Copilot"، "صنّف frontend") | يُضيف المنفّذ والتسميات والمراحل دفعةً واحدة | لوحات المشاريع نظيفة وسير العمل منظّم |
| اجمع أخطاء متشابهة في prompt واحد | يُنشئ مسودات متعددة تقبلها واحدةً واحدة | صفر تبديل للنوافذ في وضع الفرز |
٤. تحويل الـ Issue إلى Draft PR تلقائياً
بعد إنشاء الـ issue، اسنده لـ Copilot (وكيل الكودينج) — يظهر في قائمة المنفّذين مثل أي زميل — أو اكتب في المحادثة:
"اسنده لـ Copilot."ما يحدث خلف الكواليس
- Copilot يُهيّئ بيئة GitHub Actions آمنة ومعزولة
- يستنسخ المستودع ويبحث دلالياً في الكود (بأسلوب RAG) ويرسم خطة الإصلاح
- الـ commits تتراكم في Draft PR يمكنك متابعته في الوقت الفعلي — لا مفاجآت
- حمايات الفروع (Branch protections) وبوابات الـ CI تعمل كالمعتاد
لماذا هذا مهم؟
- توازٍ في العمل: تراجع الـ PR بينما Copilot يكتب — دورات التطوير تتداخل
- تتبع كامل: كل commit وdiff وتعليق موثّق — لا صندوق أسود
- ضوابط سليمة: نفس قواعد CODEOWNERS ونفس توقيع الكود — سرعة بلا قلق
٥. أسئلة شائعة وإجابات سريعة
❓ "هل سيُغرق Copilot مستودعي بـ issues رديئة الجودة؟"
لا — Copilot يُنشئ المسودة، أنت من يضغط "Create". نفس حدود المعدل، نفس القوالب، فقط أقل كتابة.
❓ "هل يستطيع تحديث Issue موجود؟"
لا بعد. الآن فقط إنشاء issues جديدة — تحديث الـ Issues موجود في خارطة الطريق.
❓ "هل يفهم قوالبي المخصّصة؟"
نعم! Copilot يستنتجها من مستودعك، ويمكنك تغيير القالب في منتصف المسودة دون فقدان أي محتوى.
❓ "هل يعمل على الجوال؟"
حالياً على سطح المكتب فقط — دعم الجوال قادم.
تمرين عملي
طبّق ما تعلّمته خطوةً بخطوة:
- افتح github.com/copilot
- اكتب: "أنشئ issue يصف خطأ في صفحة تسجيل الدخول في مستودعي — الزر لا يستجيب على الجوال"
- راجع المسودة التي يُنشئها Copilot وقارنها بقائمة عناصر الـ Issue المثالي في القسم الثاني
- جرّب إضافة: "أضف خطوات الإعادة" وشاهد كيف يُعدّل المسودة
- اسند الـ issue لـ Copilot وراقب ظهور Draft PR