ارائه بازبینی درخواست کشش¶
ما همیشه از دریافت بازخورد از مشارکتکنندگان، صرفنظر از سطح تجربهٔ آنها، خوشحال میشویم.
چرا مشارکتها را بازبینی کنیم؟¶
هر مشارکتی که ارسال میشود، چه توسط یکی از اعضای تیم اصلی باشد چه توسط یک مشارکتکنندهٔ تازهکار، باید بازبینی شود. همه ممکن است چیزی را از قلم بیندازند. فرایند بازبینی برای فراهم کردن یک شبکهٔ ایمنی اضافی وجود دارد.
هدف از فرایند بازبینی این است که اطمینان حاصل شود تمام محتوا، از جمله کد و مستندات، تا حد امکان عاری از خطا و آسان برای نگهداری باشد. هر کاری که برای پیشبرد این هدف انجام دهید، یک مشارکت ارزشمند است. این میتواند از اصلاح یک اشتباه تایپی ساده تا یافتن موارد حاشیهای در استفاده از API که شناسایی نمیشوند، متغیر باشد. میتوانید راههایی برای تقویت روند تست شناسایی کنید یا پیشنهادی برای ساختاردهی معماری کلی تغییرات ارائه دهید تا نگهداری یا توسعه آنها آسانتر شود.
آیا میتوانم بازبینی کنم؟¶
بله! شما میتوانید در هر درخواست تغییری که در BeeWare باز است، بازخورد ارائه دهید.
بهعنوان یک مشارکتکنندهٔ تازهکار، شما میتوانید هر درخواست ادغام (pull request) را که پیدا میکنید بازبینی کنید، حتی اگر توسط یکی از اعضای اصلی تیم ارسال شده باشد. اگر تازهکار باشید، ممکن است برخی از زمینههای کلی پروژه را درک نکنید؛ اما هدف ما این است که پایگاه کد را فارغ از سطح تجربهی شما، قابلدرک نگه داریم. اگر چیزی در کد وجود دارد که منطقی به نظر نمیرسد، ممکن است نشانهی نیاز به مستندسازی بیشتر باشد (چه در خود کد و چه بهصورت مستندسازی مستقل طراحی).
مشارکت در بازبینی یک درخواست کشش¶
ارائه بازبینی درخواست کشش
همه میتوانند هرگونه مشارکت در پروژه BeeWare را بازبینی کنند. قبل از شروع، چند نکته مهم وجود دارد که باید به آنها توجه کنید.
قبل از نقد کردن، فکر کنید¶
قبل از پرداختن به بازبینی، فکر کنید. بهعنوان بازبینان، باید در نظر بگیریم که پاسخی که قرار است ارسال کنیم آیا:
- درست است. همیشه تلاش کنید پیشنهادها و اطلاعات دقیقی ارائه دهید.
- مفید. ما راهنماییهایی برای بهبود ارسال ارائه میدهیم؛ این راهنماییها باید بهوضوح منبع یک مشکل یا یک مورد استفاده در نظر گرفته نشده را مشخص کنند و در حالت ایدهآل مسیری برای پیشبرد ارائه دهند که نگرانی را برطرف یا برآورده سازد.
- الهامبخش. این وظیفه ماست که نویسنده را ترغیب کنیم تا تغییرات درخواستی ما را اعمال کند.
- ضروری. انتظار میرود که نویسنده همهٔ مطالبی را که ما منتشر میکنیم بخواند؛ ما باید با احترام به زمان و تلاش او، تنها در مواقع ضروری پست کنیم.
- مهربان. راههای متعددی برای ارائهٔ همان بازخورد وجود دارد؛ باید مطمئن شویم که با سخنانمان مهربان، حمایتگر و سازنده هستیم.
کاملاً ممکن است که همزمان با ارائه یک بازبینی مؤثر، فکر هم کنید. مفاهیم مطرحشده در بالا مانع از اشاره به هر مشکلی که در یک PR پیدا میکنید، نمیشوند. اگر مشارکتکنندگان از نقاطی که نیاز به بهبود دارند بیخبر باشند، فرصتی برای بهبود مشارکت خود نخواهند داشت. نکته مهم این است که همواره از نحوه ارائه این بازخورد آگاه باشید. سعی کنید بازبینی خود را از حالت شخصی خارج کنید. به جای «شما اشتباه کردید»، میتوانید بگویید: «این کد میتواند بهبود یابد.» کد را بازبینی کنید، نه نویسنده را.
مهم است که علاوه بر شناسایی حوزههایی که نیاز به بهبود دارند، بازخورد مثبت نیز ارائه دهید. اگر، برای مثال، تغییرات بهویژه مفید باشند، کاری هوشمندانه انجام دهند یا شما با APIای آشنا شوید که قبلاً از آن خبر نداشتید، به نویسنده اطلاع دهید! هرگز تأثیر اشاره به کاری را که کسی درست یا خوب انجام داده است دستکم نگیرید، بهویژه در شرایطی که همه موارد دیگری که به آنها اشاره کردهاید نیازمند حلوفصل هستند.
پیشنهادات بازبینی گیتهاب¶
رابط بازبینی گیتهاب دارای سازوکاری برای پیشنهاد تغییرات است که در آن میتوانید تغییر دقیقی را که پیشنهاد میکنید بهعنوان جایگزین محتوای موجود ارائه دهید. به خاطر داشته باشید تا زمانی که این پیشنهادهای تغییر پذیرفته و کامیت نشوند، تحت بررسیهای پیشکامیت و لینت قرار نخواهند گرفت. بنابراین این قابلیت باید برای تغییرات کوچکتر استفاده شود، زیرا هرچه تغییر پیشنهادی بزرگتر باشد، احتمال بیشتری دارد که مشکلات جدیدی ایجاد کند.