عملية 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، احصل على تعليقات من المشرفين والمساهمين قبل إرسالها.
إن كتابة كود التنفيذ ليس شرطًا، ولكنه قد يساعد في تصميم المناقشات.
توظيف الراعي.
- يجب أن يكون الراعي هو القائم على المشروع.
- قم بتحديد الراعي في RFC، قبل نشر العلاقات العامة.
يمكنك نشر RFC بدون جهة راعية، ولكن إذا لم يكن هناك راعي خلال شهر من نشر العلاقات العامة، فسيتم إغلاقه.
أرسل RFC الخاص بك كطلب سحب إلى Tensorflow/community/rfcs .
قم بتضمين جدول الرأس ومحتويات قسم الهدف في التعليق على طلب السحب الخاص بك، باستخدام Markdown. للحصول على مثال، يرجى الاطلاع على هذا المثال RFC . قم بتضمين مقابض GitHub للمؤلفين المشاركين والمراجعين والجهات الراعية.
في الجزء العلوي من PR، حدد المدة التي ستستغرقها فترة التعليق. يجب أن يكون ذلك لمدة أسبوعين على الأقل من تاريخ نشر العلاقات العامة.
أرسل القائمة البريدية للمطورين عبر البريد الإلكتروني مع وصف موجز ورابط للعلاقات العامة وطلب المراجعة. اتبع تنسيق المراسلات السابقة، كما ترون في هذا المثال .
سيطلب الراعي عقد اجتماع للجنة المراجعة، في موعد لا يتجاوز أسبوعين بعد نشر RFC PR. إذا كانت المناقشة نشطة، فانتظر حتى تستقر قبل الذهاب للمراجعة. الهدف من اجتماع المراجعة هو حل المشكلات البسيطة؛ وينبغي التوصل إلى توافق في الآراء بشأن القضايا الرئيسية مسبقا.
قد يوافق الاجتماع على RFC أو يرفضه أو يطلب إجراء تغييرات قبل أن يتم النظر فيه مرة أخرى. سيتم دمج طلبات RFC المعتمدة في المجتمع/RFCs ، وسيتم إغلاق طلبات RFC المرفوضة.
المشاركون في RFC
يشارك العديد من الأشخاص في عملية RFC:
مؤلف RFC - واحد أو أكثر من أعضاء المجتمع الذين يكتبون RFC ويلتزمون بدعمه خلال العملية
راعي RFC - المشرف الذي يرعى RFC وسيرعاه خلال عملية مراجعة RFC
لجنة المراجعة - مجموعة من المشرفين الذين يتحملون مسؤولية التوصية باعتماد RFC
يمكن لأي عضو في المجتمع المساعدة من خلال تقديم تعليقات حول ما إذا كان RFC سيلبي احتياجاته.
الراعي هو المشرف على المشروع المسؤول عن ضمان أفضل نتيجة ممكنة لعملية RFC. هذا يتضمن:
- الدعوة للتصميم المقترح.
- توجيه RFC للالتزام باتفاقيات التصميم والأسلوب الحالية.
- توجيه لجنة المراجعة للتوصل إلى إجماع مثمر.
- إذا طلبت لجنة المراجعة إجراء تغييرات، فتأكد من إجرائها واطلب الموافقة اللاحقة من أعضاء اللجنة.
- إذا انتقل RFC إلى التنفيذ:
- التأكد من أن التنفيذ المقترح يلتزم بالتصميم.
- التنسيق مع الجهات المختصة لإنجاح تنفيذ الأرض.
لجان مراجعة RFC
تقرر لجنة المراجعة على أساس الإجماع ما إذا كانت ستوافق على التغييرات أو ترفضها أو تطلبها. وهم مسؤولون عن:
- التأكد من أن العناصر الجوهرية للتعليقات العامة قد تم أخذها في الاعتبار.
- إضافة ملاحظات الاجتماع الخاصة بهم كتعليقات إلى العلاقات العامة.
- تقديم أسباب قراراتهم.
قد يتغير تشكيل لجنة المراجعة وفقًا لأسلوب الإدارة والقيادة الخاص بكل مشروع. بالنسبة لـ TensorFlow الأساسي، ستتألف اللجنة من المساهمين في مشروع TensorFlow الذين لديهم خبرة في مجال المجال المعني.
أعضاء المجتمع وعملية RFC
الغرض من RFCs هو ضمان تمثيل المجتمع بشكل جيد وخدمته من خلال التغييرات الجديدة في TensorFlow. وتقع على عاتق أفراد المجتمع مسؤولية المشاركة في مراجعة طلبات التعليقات (RFC) عندما يكون لديهم مصلحة في النتيجة.
يجب على أعضاء المجتمع المهتمين بـ RFC:
- تقديم الملاحظات في أقرب وقت ممكن لإتاحة الوقت الكافي للنظر فيها.
- اقرأ RFCs جيدًا قبل تقديم التعليقات.
- كن متحضرًا وبناءً .
تنفيذ الميزات الجديدة
بمجرد الموافقة على RFC، يمكن البدء في التنفيذ.
إذا كنت تعمل على تعليمات برمجية جديدة لتنفيذ RFC:
- تأكد من أنك تفهم الميزة والتصميم المعتمد في RFC. اطرح الأسئلة وناقش النهج قبل بدء العمل.
- يجب أن تتضمن الميزات الجديدة اختبارات وحدة جديدة تتحقق من أن الميزة تعمل كما هو متوقع. إنها فكرة جيدة أن تكتب هذه الاختبارات قبل كتابة الكود.
- اتبع دليل نمط كود TensorFlow
- قم بإضافة أو تحديث وثائق API ذات الصلة. قم بالرجوع إلى RFC في الوثائق الجديدة.
- اتبع أي إرشادات أخرى منصوص عليها في ملف
CONTRIBUTING.md في مستودع المشروع الذي تساهم فيه. - قم بإجراء اختبارات الوحدة قبل إرسال الكود الخاص بك.
- اعمل مع راعي RFC للحصول على الرمز الجديد بنجاح.
الحفاظ على ارتفاع الشريط
في حين أننا نشجع كل مساهم ونحتفل به، إلا أن مستوى قبول RFC يظل مرتفعًا عن عمد. قد يتم رفض ميزة جديدة أو تحتاج إلى مراجعة كبيرة في أي من هذه المراحل:
- محادثات التصميم الأولية على القائمة البريدية ذات الصلة.
- الفشل في تجنيد الراعي.
- الاعتراضات الحرجة خلال مرحلة ردود الفعل.
- الفشل في التوصل إلى توافق في الآراء أثناء مراجعة التصميم.
- المخاوف التي أثيرت أثناء التنفيذ (على سبيل المثال: عدم القدرة على تحقيق التوافق مع الإصدارات السابقة، والمخاوف بشأن الصيانة).
إذا كانت هذه العملية تعمل بشكل جيد، فمن المتوقع أن تفشل طلبات RFC في المراحل السابقة، وليس اللاحقة. لا يعد RFC المعتمد ضمانًا للالتزام بالتنفيذ، ولا يزال قبول تنفيذ RFC المقترح خاضعًا لعملية مراجعة التعليمات البرمجية المعتادة.
إذا كانت لديك أي أسئلة حول هذه العملية، فلا تتردد في طرحها على القائمة البريدية للمطورين أو تقديم مشكلة في Tensorflow/community .
إنّ محتوى هذه الصفحة مرخّص بموجب ترخيص Creative Commons Attribution 4.0 ما لم يُنصّ على خلاف ذلك، ونماذج الرموز مرخّصة بموجب ترخيص Apache 2.0. للاطّلاع على التفاصيل، يُرجى مراجعة سياسات موقع Google Developers. إنّ Java هي علامة تجارية مسجَّلة لشركة 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)."]]
