اختيار الـ Issue الصح

الـ issue الغلط بيحرق أسبوع. الصح بيشحن في يومين. الفرق نادراً عن صعوبة الـ bug — هو عن مدى وضوح مواصفات الـ bug وقد إيه التغيير معزول عن باقي الـ codebase.

استخدم الـ rubric ده وإنت بتمسح issue tracker لـ repo:

الخاصية	إشارة كويسة	إشارة وحشة
Reproducer	الـ issue فيه input + actual + expected output	الـ issue بيقول "doesn't work" من غير تفاصيل
النطاق	الـ bug في ملف واحد أو function واحدة	الـ bug بيلمس "الـ pipeline كله"
Tests	الـ repo فيه coverage معقول للمنطقة المتأثرة	الـ repo فيه 0% coverage
نشاط الـ maintainer	Merges أخيرة، review turnaround سريع	PRs بتفضل مفتوحة لشهور
الإلفة	بتستخدم المشروع؛ فاهم سطحه العام	اكتشفت المشروع الأسبوع اللي فات
تقدير الحجم	الـ maintainer بيقدر ≤ يوم واحد	متاجد "epic" أو "needs design"

إنت عايز أكبر عدد من سطور "إشارة كويسة." سطر أو اتنين "وحشة" تمام لو متعوّضين. تلاتة أو أكتر، امشي.

تاج "good first issue" فلتر مفيد بس مش ضمانة. بعض الـ repos بتستخدمه بسخاء؛ التانية بيستخدموه باعتدال. اقرا الـ issue نفسه، مش التاج. "Good first issue" بخطوات إعادة إنتاج غامضة أوحش من bug من غير تاج بـ reproducer ممتاز.

نمط غلط محدد تتجنبه: refactor مفتوح. Issues بتقول "this code is messy, please clean up" دي فخاخ. مفيش تعريف موضوعي للخلاص. الـ maintainer عنده آراء مش مشاركك فيها. هتعمل الشغل، الـ PR هيتـbikeshed، وهتقفله من غير ما يـmerge.

Bug fixes ملموسة هي النقطة الصح. عندها تعريف موضوعي للخلاص — الـ test اللي بيوضّح الـ bug دلوقتي بيعدّي، مع كل الـ tests الموجودة لسه بتعدّي. تقدر تـprompt في طريقك خلال الـ fix كله:

1. Localization prompt (Module 2) — "find the bug given this failing test"
2. Codegen skeleton (Module 1) — لأي function جديد الـ fix بيقدّمه
3. Type-safety lock (Module 3) — لو الـ fix بيلمس types
4. Code review prompt (Module 4) — self-review قبل الـ push
5. Conventional commit + PR description (Module 5) — للـ merge

5 أنماط prompt من 5 modules مختلفة، end-to-end على PR واحد. ده بالظبط اللي الـ rubric في الدرس 4 بيقيسه.

لو ما لقيتش issue نظيف على repo بتعرفه، بديلين آمنين:

• تصحيح documentation على repo حقيقي. لاقي قسم docs غلط أو قديم. الـ PR صغير؛ الـ maintainers عادة بيـmergoه بسرعة؛ بيدرّسك flow المساهمة من غير تعقيد خاص باللغة.
• Feature صغير على side project بتاعك. لو عندك repo شخصي بمستخدم أو اتنين، ده بيحسب "حقيقي." الميزة سيطرة كاملة على المعيار؛ العيب غياب reviewer خارجي.

أياً كان اللي اخترته، اكتب link الـ issue، قرارات الـ scoping، وتقديرك المبدئي للحجم قبل ما تبدأ prompting. الورقة دي بتبقى أول artifact للمشروع الختامي.

التالي: code-explainer system prompt لتسريع فهمك للملف اللي هتلمسه. :::