‏راهنمای رسمی اولین مشارکت در Node.js

پروژهٔ Node.js یه راهنمای جدا برای مشارکت‌کننده‌های بار اول منتشر کرده که مکمل راهنمای کلی مشارکت و راهنمای pull request هست. تو این سند اومده که Node.js یه پروژهٔ جامعه‌محور و داوطلبانه‌ست: هیچ مدیر پروژه‌ای وجود نداره که ایشیوها رو به آدم‌ها اختصاص بده، پس لازم نیست رو گیت‌هاب درخواست assign بدی — مشارکت‌کننده‌ها معمولاً با کامنت گذاشتن، پیشرفت کارشون رو اعلام می‌کنن.

برای شروع، برچسب good first issue ایشیوهای مناسب تازه‌واردهاست و help wanted کارهاییه که داوطلب می‌خواد ولی ممکنه سخت‌تر باشه یا تخصص خاصی لازم داشته باشه. اگه تغییری که در نظر داری پیچیده‌ست، قابلیت جدید اضافه می‌کنه، سازگاری عقب‌رو رو می‌شکنه یا بازنویسی بزرگی لازم داره، بهتره اول یه ایشیو باز کنی و سر طراحی‌ش به توافق برسی؛ ولی رفع باگ واضح یا ریفکتور کوچیک رو می‌شه مستقیم به‌شکل PR فرستاد.

بخش «چه کارهایی نکن» صریح‌تر از بقیه‌ست. نویسنده‌های سند می‌گن اولین مشارکتت رو خودکارسازی نکن (اتوماسیون تو این پروژه باید صریحاً مجاز و رهگیری بشه)، PRهای بزرگ نفرست چون عبور دادن تغییر پیچیده از فرایند اجماعِ همکارها حتی برای باتجربه‌ها هم سخته، و تا وقتی PR اولت تأیید نشده PR جدید باز نکن — این کار حس سرریز کردن پروژه رو می‌ده و هم خودت و هم ریویوکننده‌ها رو زیر نوتیفیکیشن دفن می‌کنه.

راهنما یه بخش پرسش‌وپاسخ هم داره که بیشتر دلخوری‌های رایج رو پوشش می‌ده. اگه PRت ریویو نمی‌شه، می‌تونی آدم‌هایی رو که تو ایشیو اصلی علاقه نشون دادن پینگ کنی یا تو کانال #node-core توی اسلک بنیاد OpenJS کمک بخوای؛ بازهٔ معمول پاسخ ریویوکننده‌ها بین ۴۸ ساعت تا ۷ روزه. برای حل کانفلیکت هم باید محلی rebase کنی و force-push بدی — از رابط وب گیت‌هاب استفاده نکن، چون کامیت مرجی که می‌سازه برای CI دردسر درست می‌کنه. امضای DCO روی کامیت‌ها (git commit -s) هم اجباریه.

دربارهٔ CI هم توضیح می‌ده که پروژه دو سیستم داره: Jenkins سیستم اصلی تست PRهاست و GitHub Actions برای بررسی‌های سریع. PRهایی که فقط مستندات رو دست می‌زنن، فقط باید چک‌های GitHub Actions رو رد کنن؛ بقیه برچسب needs-ci می‌گیرن. اجرای Jenkins همیشه دستیه و فقط همکارها و triagerها می‌تونن تریگرش کنن، چون کسی باید اول مطمئن بشه کد مخرب توش نیست. خطاهای بی‌ربط هم شایعن — مخزن reliability گزارش روزانهٔ تست‌های flaky رو نگه می‌داره.

در آخر، زمان انتشار هم شفاف شده: تغییرهای غیر semver-major اول تو نسخهٔ Current منتشر می‌شن و بعد از حداقل دو هفته واجد شرایط ورود به نسخه‌های LTS می‌شن، ولی تغییر semver-major باید تا نسخهٔ major بعدی صبر کنه که ممکنه ماه‌ها طول بکشه.

نکات کلیدی:

• ایشیو به کسی اختصاص داده نمی‌شه؛ با کامنت پیشرفتت رو اعلام کن و هم‌زمان چند ایشیو برندار
• برچسب good first issue نقطهٔ شروع تازه‌واردهاست و help wanted کار سخت‌تر داوطلب‌طلبه
• اولین PR نباید بزرگ یا خودکارسازی‌شده باشه و تا تأیید نشدنش PR بعدی نفرست
• امضای DCO با git commit -s اجباریه وگرنه کامیت مرج نمی‌شه
• کانفلیکت رو محلی rebase کن، نه با رابط وب گیت‌هاب
• Jenkins فقط دستی و توسط همکارها تریگر می‌شه؛ خطاهای flaky رو تو مخزن reliability چک کن