هر ویژگی جدید TensorFlow زندگی خود را به عنوان یک درخواست برای اظهار نظر (RFC) آغاز می کند.
RFC سندی است که یک نیاز و تغییرات پیشنهادی که آن را حل می کند را توصیف می کند. به طور خاص، RFC:
- مطابق با قالب RFC فرمت شود.
- به عنوان یک درخواست کشش به دایرکتوری انجمن/rfcs ارسال شود.
- قبل از پذیرش موضوع مورد بحث و بررسی قرار گیرد.
هدف از درخواست نظرات TensorFlow (RFC) مشارکت دادن جامعه TensorFlow در توسعه، با دریافت بازخورد از ذینفعان و کارشناسان، و ارتباط گسترده با تغییرات طراحی است.
نحوه ارسال RFC
قبل از ارسال RFC، اهداف خود را با همکاران و نگهبانان پروژه در میان بگذارید و بازخورد اولیه را دریافت کنید. از فهرست پستی توسعه‌دهنده برای پروژه مربوطه استفاده کنید (developers@tensorflow.org یا لیست مربوط به SIG).
RFC خود را پیش نویس کنید.
- معیارهای بررسی طراحی را بخوانید
- الگوی RFC را دنبال کنید.
- نام فایل RFC خود را
YYYYMMDD-descriptive-name.mdبگذارید که در آنYYYYMMDDتاریخ ارسال است وdescriptive-nameمربوط به عنوان RFC شما است. (به عنوان مثال، اگر RFC شما با عنوان Parallel Widgets API است، ممکن است از نام فایل20180531-parallel-widgets.mdاستفاده کنید. - اگر تصاویر یا فایل های کمکی دیگری دارید، دایرکتوری به شکل
YYYYMMDD-descriptive-nameایجاد کنید تا آن فایل ها را در آن ذخیره کنید.
پس از نوشتن پیش‌نویس RFC، قبل از ارسال آن، بازخوردی از نگهبانان و مشارکت‌کنندگان دریافت کنید.
نوشتن کد پیاده سازی الزامی نیست، اما ممکن است به بحث طراحی کمک کند.
جذب اسپانسر
- یک حامی باید نگهبان پروژه باشد.
- قبل از ارسال PR، حامی را در RFC شناسایی کنید.
شما می توانید یک RFC بدون حامی ارسال کنید، اما اگر تا یک ماه پس از ارسال PR هنوز اسپانسر وجود نداشته باشد، بسته خواهد شد.
RFC خود را به عنوان یک درخواست کشش به tensorflow/community/rfcs ارسال کنید.
جدول هدر و محتویات بخش Objective را با استفاده از Markdown در کامنت درخواست کشش خود وارد کنید. برای مثال، لطفاً این مثال RFC را ببینید. شامل دسته‌های GitHub از نویسندگان، بازبین‌ها و حامیان مالی مشترک.
در بالای PR مشخص کنید که مدت زمان اظهار نظر چقدر خواهد بود. این باید حداقل دو هفته از ارسال PR باشد.
لیست پستی توسعه دهنده را با توضیحات مختصر، پیوندی به روابط عمومی و درخواست بررسی ایمیل کنید. همانطور که در این مثال می بینید، فرمت نامه های قبلی را دنبال کنید.
حامی درخواست یک جلسه کمیته بازبینی، حداکثر دو هفته پس از ارسال RFC PR خواهد کرد. اگر بحث پر جنب و جوش است، قبل از رفتن به بررسی، صبر کنید تا حل شود. هدف از جلسه بررسی حل مسائل جزئی است. قبل از آن باید در مورد مسائل عمده به اجماع رسید.
جلسه ممکن است RFC را تأیید کند، آن را رد کند، یا قبل از بررسی مجدد، نیاز به تغییرات داشته باشد. RFC های تایید شده در جامعه/rfc ادغام می شوند و RFC های رد شده PR بسته می شوند.
شرکت کنندگان RFC
افراد زیادی در فرآیند RFC درگیر هستند:
نویسنده RFC - یک یا چند عضو انجمن که یک RFC می نویسند و متعهد به حمایت از آن در طول فرآیند هستند
حامی RFC - نگهدارنده‌ای که از RFC حمایت می‌کند و از طریق فرآیند بررسی RFC از آن حمایت می‌کند
کمیته بررسی - گروهی از نگهبانان که مسئولیت توصیه پذیرش RFC را دارند
هر عضو جامعه ممکن است با ارائه بازخورد در مورد اینکه آیا RFC نیازهای آنها را برآورده می کند یا خیر، کمک کند.
حامیان RFC
حامی یک نگهدارنده پروژه است که مسئول اطمینان از بهترین نتیجه ممکن فرآیند RFC است. این شامل:
- حمایت از طرح پیشنهادی
- هدایت RFC برای پایبندی به قراردادهای طراحی و سبک موجود.
- هدایت کمیته بررسی برای رسیدن به یک اجماع سازنده.
- در صورت درخواست تغییرات توسط کمیته بررسی، اطمینان حاصل کنید که این تغییرات انجام شده است و از اعضای کمیته درخواست تأیید بعدی کنید.
- اگر RFC به سمت پیاده سازی حرکت کند:
- اطمینان از پایبندی اجرای پیشنهادی به طرح.
- برای اجرای موفقیت آمیز زمین با طرف های مناسب هماهنگ کنید.
کمیته های بررسی RFC
کمیته بررسی بر اساس اجماع تصمیم می گیرد که آیا تغییرات را تایید، رد یا درخواست کند. آنها مسئول هستند:
- اطمینان از اینکه موارد اساسی بازخورد عمومی در نظر گرفته شده است.
- اضافه کردن یادداشت های جلسه خود به عنوان نظرات به روابط عمومی.
- ارائه دلایل تصمیمات خود.
اساسنامه یک کمیته بازنگری ممکن است با توجه به سبک خاص حکمرانی و رهبری هر پروژه تغییر کند. برای هسته TensorFlow، کمیته متشکل از مشارکت کنندگان در پروژه TensorFlow خواهد بود که در حوزه مربوطه تخصص دارند.
اعضای جامعه و فرآیند RFC
هدف از RFC ها این است که اطمینان حاصل شود که جامعه با تغییرات جدید در TensorFlow به خوبی نشان داده می شود و در خدمت آنهاست. این مسئولیت اعضای جامعه است که در بررسی RFC ها در جایی که به نتیجه علاقه دارند، شرکت کنند.
اعضای انجمنی که به RFC علاقه مند هستند باید:
- در اسرع وقت بازخورد ارائه دهید تا زمان کافی برای بررسی در نظر گرفته شود.
- قبل از ارائه بازخورد ، RFC ها را به طور کامل بخوانید .
- مدنی و سازنده باشید.
پیاده سازی ویژگی های جدید
پس از تایید یک RFC، پیاده سازی می تواند آغاز شود.
اگر روی کد جدیدی برای پیاده سازی RFC کار می کنید:
- مطمئن شوید که ویژگی و طراحی تایید شده در RFC را درک کرده اید. قبل از شروع کار، سوال بپرسید و در مورد رویکرد بحث کنید.
- ویژگی‌های جدید باید شامل تست‌های واحد جدید باشد که تأیید می‌کند ویژگی همانطور که انتظار می‌رود کار می‌کند. بهتر است این تست ها را قبل از نوشتن کد بنویسید.
- راهنمای سبک کد TensorFlow را دنبال کنید
- اسناد API مربوطه را اضافه یا به روز کنید. RFC را در مستندات جدید ارجاع دهید.
- هر دستورالعمل دیگری را که در فایل
CONTRIBUTING.mdدر مخزن پروژه ای که در آن مشارکت می کنید، دنبال کنید. - قبل از ارسال کد، تست های واحد را اجرا کنید.
- با حامی RFC کار کنید تا کد جدید را با موفقیت وارد کنید.
بالا نگه داشتن میله
در حالی که ما هر مشارکت کننده را تشویق و تجلیل می کنیم، نوار پذیرش RFC عمداً بالا نگه داشته می شود. یک ویژگی جدید ممکن است رد شود یا در هر یک از این مراحل نیاز به بازبینی اساسی داشته باشد:
- مکالمات طراحی اولیه در لیست پستی مربوطه.
- عدم جذب اسپانسر
- اعتراضات انتقادی در مرحله بازخورد.
- عدم دستیابی به اجماع در طول بررسی طراحی.
- نگرانی های مطرح شده در حین اجرا (به عنوان مثال: ناتوانی در دستیابی به سازگاری با عقب، نگرانی در مورد تعمیر و نگهداری).
اگر این فرآیند به خوبی کار کند، انتظار می رود که RFCها در مراحل اولیه و نه مراحل بعدی شکست بخورند. یک RFC تایید شده تضمینی برای تعهد به پیاده سازی نیست و پذیرش پیاده سازی RFC پیشنهادی همچنان منوط به روند معمول بررسی کد است.
اگر در مورد این فرآیند سؤالی دارید، در لیست پستی توسعه دهندگان بپرسید یا مشکلی را در tensorflow/community ثبت کنید.