مدیریت یک Issue

مقدمه

در درس قبل با آناتومی یک Issue و اهمیت آن به عنوان سنگ بنای مدیریت پروژه در گیت‌هاب آشنا شدیم. اما ایجاد یک Issue تنها اولین قدم است. یک Issue از زمان ایجاد تا زمانی که حل و بسته می‌شود، یک چرخه حیات را طی می‌کند. مدیریت صحیح این چرخه برای سازماندهی پروژه و اطمینان از اینکه هیچ وظیفه‌ای از قلم نمی‌افتد، حیاتی است.

در این درس، به صورت عملی این چرخه حیات را بررسی می‌کنیم و یاد می‌گیریم که چگونه یک Issue را از مرحله ایجاد، دسته‌بندی، تخصیص و نهایتاً بستن، مدیریت کنیم.

چرخه حیات یک Issue

یک Issue معمولاً چهار مرحله اصلی را طی می‌کند:

1. ایجاد (Creation): یک کاربر یا عضو تیم، یک Issue جدید را باز می‌کند.
2. تریاژ (Triage): نگهدارندگان پروژه، Issue را بررسی، اعتبارسنجی و دسته‌بندی می‌کنند.
3. توسعه (Development): یک توسعه‌دهنده مسئولیت Issue را بر عهده گرفته و کار روی آن را آغاز می‌کند.
4. بستن (Closing): کار مربوط به Issue به اتمام رسیده و Issue بسته می‌شود.

در ادامه هر یک از این مراحل را با جزئیات بیشتری بررسی می‌کنیم.

مرحله اول و دوم: ایجاد و تریاژ یک Issue

پس از اینکه یک Issue جدید ایجاد شد، اولین وظیفه نگهدارندگان پروژه، «تریاژ» کردن آن است. تریاژ به معنی ارزیابی اولیه و دسته‌بندی Issue است. این مرحله شامل اقدامات زیر است:

• اعتبارسنجی: آیا این یک گزارش باگ معتبر است؟ آیا می‌توان آن را بازتولید کرد؟ آیا درخواست قابلیت جدید با اهداف پروژه همسو است؟ اگر اطلاعات ناقص باشد، نگهدارنده با منشن کردن نویسنده (@username) از او اطلاعات بیشتری می‌خواهد.
• برچسب‌گذاری (Labeling): این مهم‌ترین بخش تریاژ است. نگهدارنده برچسب‌های مناسبی مانند bug، enhancement یا question را به Issue اضافه می‌کند تا وضعیت و نوع آن برای همه مشخص شود.
• مرتبط کردن با پروژه یا مایلستون: در صورت لزوم، Issue به یک تخته پروژه (Project Board) یا یک مایلستون (Milestone) اضافه می‌شود تا در نقشه راه کلی پروژه قرار گیرد.

مرحله سوم: تخصیص و شروع توسعه

زمانی که یک Issue به طور کامل بررسی و دسته‌بندی شد، آماده است تا یک نفر روی آن کار کند. نگهدارنده می‌تواند با استفاده از گزینه Assignees در منوی کناری، Issue را به یک یا چند نفر از اعضای تیم تخصیص دهد. فردی که Issue به او محول می‌شود، یک نوتیفیکیشن دریافت می‌کند.

سپس توسعه‌دهنده مسئول، جریان کاری استاندارد گیت را آغاز می‌کند: یک برنچ جدید می‌سازد، تغییرات لازم را در کد اعمال می‌کند، کار خود را کامیت می‌کند و در نهایت یک Pull Request برای بازبینی ارسال می‌نماید.

مرحله چهارم: بستن یک Issue

زمانی که کار مربوط به یک Issue تمام شد، باید بسته شود. دو راه اصلی برای این کار وجود دارد.

بستن به صورت دستی

هر فردی که دسترسی لازم را به مخزن داشته باشد، می‌تواند با کلیک روی دکمه «Close issue» در پایین صفحه، یک Issue را ببندد. این روش معمولاً برای Issueهای تکراری، آن‌هایی که نامعتبر تشخیص داده شده‌اند، یا سوالاتی که پاسخ داده شده‌اند، استفاده می‌شود.

بستن خودکار از طریق Pull Request

این روش ارجح و استاندارد برای بستن Issueهایی است که با تغییر در کد حل می‌شوند. گیت‌هاب یک قابلیت هوشمند دارد: اگر در توضیحات Pull Request خود از کلمات کلیدی خاصی مانند Closes، Fixes یا Resolves به همراه شماره Issue استفاده کنید (مثلاً: Closes #42)، اتفاق جالبی رخ می‌دهد.

به محض اینکه آن Pull Request در برنچ اصلی پروژه ادغام (Merge) شود، گیت‌هاب به صورت خودکار Issue شماره ۴۲ را می‌بندد. این کار یک پیوند ناگسستنی و قابل ردیابی بین گزارش مشکل (Issue) و راه‌حل آن (کد ادغام‌شده) ایجاد می‌کند که برای نگهداری پروژه فوق‌العاده ارزشمند است.

همچنین لازم به ذکر است که اگر یک Issue به اشتباه بسته شود، همیشه می‌توان با کلیک روی دکمه «Reopen issue» آن را دوباره باز کرد.