فرآیند TensorFlow RFC
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
هر ویژگی جدید 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
کمیته بررسی بر اساس اجماع تصمیم می گیرد که آیا تغییرات را تایید، رد یا درخواست کند. آنها مسئول هستند:
- اطمینان از اینکه موارد اساسی بازخورد عمومی در نظر گرفته شده است.
- اضافه کردن یادداشت های جلسه خود به عنوان نظرات به روابط عمومی.
- ارائه دلایل تصمیمات خود.
اساسنامه یک کمیته بازنگری ممکن است با توجه به سبک خاص حکمرانی و رهبری هر پروژه تغییر کند. برای هسته TensorFlow، کمیته متشکل از مشارکت کنندگان در پروژه TensorFlow خواهد بود که در حوزه مربوطه تخصص دارند.
اعضای جامعه و فرآیند RFC
هدف از RFC ها این است که اطمینان حاصل شود که جامعه با تغییرات جدید در TensorFlow به خوبی نشان داده می شود و در خدمت آنهاست. این مسئولیت اعضای جامعه است که در بررسی RFC ها در جایی که به نتیجه علاقه دارند، شرکت کنند.
اعضای انجمنی که به RFC علاقه مند هستند باید:
- در اسرع وقت بازخورد ارائه دهید تا زمان کافی برای بررسی در نظر گرفته شود.
- قبل از ارائه بازخورد ، RFC ها را به طور کامل بخوانید .
- مدنی و سازنده باشید.
پیاده سازی ویژگی های جدید
پس از تایید یک RFC، پیاده سازی می تواند آغاز شود.
اگر روی کد جدیدی برای پیاده سازی RFC کار می کنید:
- مطمئن شوید که ویژگی و طراحی تایید شده در RFC را درک کرده اید. قبل از شروع کار، سوال بپرسید و در مورد رویکرد بحث کنید.
- ویژگی‌های جدید باید شامل تست‌های واحد جدید باشد که تأیید می‌کند ویژگی همانطور که انتظار می‌رود کار می‌کند. بهتر است این تست ها را قبل از نوشتن کد بنویسید.
- راهنمای سبک کد TensorFlow را دنبال کنید
- اسناد API مربوطه را اضافه یا به روز کنید. RFC را در مستندات جدید ارجاع دهید.
- هر دستورالعمل دیگری را که در فایل
CONTRIBUTING.md در مخزن پروژه ای که در آن مشارکت می کنید، دنبال کنید. - قبل از ارسال کد، تست های واحد را اجرا کنید.
- با حامی RFC کار کنید تا کد جدید را با موفقیت وارد کنید.
بالا نگه داشتن میله
در حالی که ما هر مشارکت کننده را تشویق و تجلیل می کنیم، نوار پذیرش RFC عمداً بالا نگه داشته می شود. یک ویژگی جدید ممکن است رد شود یا در هر یک از این مراحل نیاز به بازبینی اساسی داشته باشد:
- مکالمات طراحی اولیه در لیست پستی مربوطه.
- عدم جذب اسپانسر
- اعتراضات انتقادی در مرحله بازخورد.
- عدم دستیابی به اجماع در طول بررسی طراحی.
- نگرانی های مطرح شده در حین اجرا (به عنوان مثال: ناتوانی در دستیابی به سازگاری با عقب، نگرانی در مورد تعمیر و نگهداری).
اگر این فرآیند به خوبی کار کند، انتظار می رود که RFCها در مراحل اولیه و نه مراحل بعدی شکست بخورند. یک RFC تایید شده تضمینی برای تعهد به پیاده سازی نیست و پذیرش پیاده سازی RFC پیشنهادی همچنان منوط به روند معمول بررسی کد است.
اگر در مورد این فرآیند سؤالی دارید، در لیست پستی توسعه دهندگان بپرسید یا مشکلی را در tensorflow/community ثبت کنید.
جز در مواردی که غیر از این ذکر شده باشد،محتوای این صفحه تحت مجوز Creative Commons Attribution 4.0 License است. نمونه کدها نیز دارای مجوز Apache 2.0 License است. برای اطلاع از جزئیات، به خطمشیهای سایت Google Developers مراجعه کنید. جاوا علامت تجاری ثبتشده Oracle و/یا شرکتهای وابسته به آن است.
تاریخ آخرین بهروزرسانی 2023-12-01 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین بهروزرسانی 2023-12-01 بهوقت ساعت هماهنگ جهانی."],[],[],null,["# The TensorFlow RFC process\n\n\u003cbr /\u003e\n\nEvery new TensorFlow feature begins life as a Request for Comment (RFC).\n\nAn RFC is a document that describes a requirement and the proposed changes that\nwill solve it. Specifically, the RFC will:\n\n- Be formatted according to the [RFC template](https://github.com/tensorflow/community/blob/master/rfcs/yyyymmdd-rfc-template.md).\n- Be submitted as a pull request to the [community/rfcs](https://github.com/tensorflow/community/tree/master/rfcs) directory.\n- Be subject to discussion and a review meeting prior to acceptance.\n\nThe purpose of a TensorFlow Request for Comments (RFC) is to engage the\nTensorFlow community in development, by getting feedback from stakeholders and\nexperts, and communicating design changes broadly.\n\nHow to submit an RFC\n--------------------\n\n1. Before submitting an RFC, discuss your aims with project contributors and\n maintainers and get early feedback. Use the developer mailing list for the\n project concerned (developers@tensorflow.org, or the list for the relevant\n SIG).\n\n2. Draft your RFC.\n\n - Read the [design review criteria](https://github.com/tensorflow/community/blob/master/governance/design-reviews.md)\n - Follow the [RFC template](https://github.com/tensorflow/community/blob/master/rfcs/yyyymmdd-rfc-template.md).\n - Name your RFC file `YYYYMMDD-descriptive-name.md`, where `YYYYMMDD` is the date of submission, and `descriptive-name` relates to the title of your RFC. (For instance, if your RFC is titled *Parallel Widgets API* , you might use the filename `20180531-parallel-widgets.md`.\n - If you have images or other auxiliary files, create a directory of the form `YYYYMMDD-descriptive-name` in which to store those files.\n\n After writing the RFC draft, get feedback from maintainers and contributors\n before submitting it.\n\n Writing implementation code is not a requirement, but it may help design\n discussions.\n3. Recruit a sponsor.\n\n - A sponsor must be a maintainer of the project.\n - Identify the sponsor in the RFC, before posting the PR.\n\n You *may* post an RFC without a sponsor, but if within a month of posting\n the PR there is still no sponsor, it will be closed.\n4. Submit your RFC as a pull request to\n [tensorflow/community/rfcs](https://github.com/tensorflow/community/tree/master/rfcs).\n\n Include the header table and the contents of the *Objective* section in the\n comment of your pull request, using Markdown. For an example, please see\n [this example RFC](https://github.com/tensorflow/community/pull/5). Include\n the GitHub handles of co-authors, reviewers, and sponsors.\n\n At the top of the PR identify how long the comment period will be. This\n should be a *minimum of two weeks* from posting the PR.\n5. Email the developer mailing list with a brief description, a link to the PR\n and a request for review. Follow the format of previous mailings, as you can\n see in\n [this example](https://groups.google.com/a/tensorflow.org/forum/#!topic/developers/PIChGLLnpTE).\n\n6. The sponsor will request a review committee meeting, no sooner than two\n weeks after the RFC PR is posted. If discussion is lively, wait until it has\n settled before going to review. The goal of the review meeting is to resolve\n minor issues; consensus should be reached on major issues beforehand.\n\n7. The meeting may approve the RFC, reject it, or require changes before it can\n be considered again. Approved RFCs will be merged into\n [community/rfcs](https://github.com/tensorflow/community/tree/master/rfcs),\n and rejected RFCs will have their PRs closed.\n\nRFC participants\n----------------\n\nMany people are involved in the RFC process:\n\n- **RFC author** --- one or more community members who write an RFC and are\n committed to championing it through the process\n\n- **RFC sponsor** --- a maintainer who sponsors the RFC and will shepherd it\n through the RFC review process\n\n- **review committee** --- a group of maintainers who have the responsibility of\n recommending the adoption of the RFC\n\n- Any **community member** may help by providing feedback on whether the RFC\n will meet their needs.\n\n### RFC sponsors\n\nA sponsor is a project maintainer responsible for ensuring the best possible\noutcome of the RFC process. This includes:\n\n- Advocating for the proposed design.\n- Guiding the RFC to adhere to existing design and style conventions.\n- Guiding the review committee to come to a productive consensus.\n- If changes are requested by the review committee, ensure these are made and seek subsequent approval from the committee members.\n- If the RFC moves to implementation:\n - Ensuring proposed implementation adheres to the design.\n - Coordinate with appropriate parties to successfully land implementation.\n\n### RFC review committees\n\nThe review committee decides on a consensus basis whether to approve, reject, or\nrequest changes. They are responsible for:\n\n- Ensuring that substantive items of public feedback have been accounted for.\n- Adding their meeting notes as comments to the PR.\n- Providing reasons for their decisions.\n\nThe constitution of a review committee may change according to the particular\ngovernance style and leadership of each project. For core TensorFlow, the\ncommittee will consist of contributors to the TensorFlow project who have\nexpertise in the domain area concerned.\n\n### Community members and the RFC process\n\nThe purpose of RFCs is to ensure the community is well represented and served by\nnew changes to TensorFlow. It is the responsibility of community members to\nparticipate in reviewing RFCs where they have an interest in the outcome.\n\nCommunity members who are interested in an RFC should:\n\n- **Provide feedback** as soon as possible to allow adequate time for consideration.\n- **Read RFCs** thoroughly before providing feedback.\n- Be **civil and constructive**.\n\nImplementing new features\n-------------------------\n\nOnce an RFC has been approved, implementation can begin.\n\nIf you are working on new code to implement an RFC:\n\n- Make sure you understand the feature and the design approved in the RFC. Ask questions and discuss the approach before beginning work.\n- New features must include new unit tests that verify the feature works as expected. It's a good idea to write these tests before writing the code.\n- Follow the [TensorFlow Code Style Guide](#tensorflow_code_style_guide)\n- Add or update relevant API documentation. Reference the RFC in the new documentation.\n- Follow any other guidelines laid out in the `CONTRIBUTING.md` file in the project repo you're contributing to.\n- Run unit tests before submitting your code.\n- Work with the RFC sponsor to successfully land the new code.\n\nKeeping the bar high\n--------------------\n\nWhile we encourage and celebrate every contributor, the bar for RFC acceptance\nis kept intentionally high. A new feature may be rejected or need significant\nrevision at any one of these stages:\n\n- Initial design conversations on the relevant mailing list.\n- Failure to recruit a sponsor.\n- Critical objections during the feedback phase.\n- Failure to achieve consensus during the design review.\n- Concerns raised during implementation (for example: inability to achieve backwards compatibility, concerns about maintenance).\n\nIf this process is functioning well, RFCs are expected to fail in the earlier,\nrather than later, stages. An approved RFC is no guarantee of a commitment to\nimplement, and acceptance of a proposed RFC implementation is still subject to\nthe usual code review process.\n\nIf you have any questions about this process, feel free to ask on the developers\nmailing list or file an issue in\n[tensorflow/community](https://github.com/tensorflow/community/tree/master/rfcs)."]]
