تبدأ كل ميزة جديدة في TensorFlow كطلب للتعليق (RFC).
RFC هو مستند يصف أحد المتطلبات والتغييرات المقترحة التي ستحلها. على وجه التحديد ، ستقوم RFC بما يلي:
- يتم تنسيقها وفقًا لقالب RFC .
- يتم تقديمها كطلب سحب إلى دليل المجتمع / rfcs .
- أن تخضع للمناقشة واجتماع مراجعة قبل القبول.
الغرض من طلب TensorFlow للتعليقات (RFC) هو إشراك مجتمع TensorFlow في التنمية ، من خلال الحصول على تعليقات من أصحاب المصلحة والخبراء ، وإبلاغ تغييرات التصميم على نطاق واسع.
كيفية إرسال RFC
قبل إرسال طلب طلب تقديمي ، ناقش أهدافك مع المساهمين في المشروع والمشرفين عليه واحصل على تعليقات مبكرة. استخدم القائمة البريدية للمطورين للمشروع المعني (developer@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 ، قبل نشر PR.
تستطيع الرد على RFC بدون كفيل، ولكن إذا غضون شهر من نشر PR لا يوجد حتى الآن الراعي، سيتم إغلاقه.
قم بإرسال RFC الخاص بك كطلب سحب إلى tensorflow / community / rfcs .
قم بتضمين جدول الرأس ومحتويات قسم الهدف في تعليق طلب السحب الخاص بك ، باستخدام Markdown. على سبيل المثال ، يرجى الاطلاع على هذا المثال RFC . قم بتضمين مقابض GitHub للمؤلفين المشاركين والمراجعين والجهات الراعية.
في الجزء العلوي من العلاقات العامة ، حدد المدة التي ستستغرقها فترة التعليق. يجب أن يكون هذا ما لا يقل عن أسبوعين من نشر العلاقات العامة.
أرسل القائمة البريدية للمطور مع وصف موجز ورابط للعلاقات العامة وطلب للمراجعة. اتبع تنسيق المراسلات السابقة ، كما ترى في هذا المثال .
سيطلب الراعي اجتماع لجنة المراجعة ، في موعد لا يتجاوز أسبوعين بعد نشر RFC PR. إذا كانت المناقشة حية ، فانتظر حتى تستقر قبل الذهاب للمراجعة. الهدف من اجتماع المراجعة هو حل القضايا الثانوية ؛ يجب أن يتم التوصل إلى توافق في الآراء بشأن القضايا الرئيسية مسبقا.
قد يوافق الاجتماع على RFC أو يرفضه أو يطلب تغييرات قبل إعادة النظر فيه مرة أخرى. سيتم دمج طلبات التعليقات (RFC) المعتمدة في المجتمع / rfcs ، وسيتم إغلاق طلبات التعليقات (RFC) المرفوضة.
المشاركون RFC
يشارك العديد من الأشخاص في عملية RFC:
مؤلف RFC - واحد أو أكثر من أعضاء المجتمع الذين يكتبون RFC ويلتزمون بمناصرته خلال العملية
راعي RFC - المشرف الذي يرعى RFC وسيقوم برعايته من خلال عملية مراجعة RFC
لجنة المراجعة - مجموعة من المشرفين الذين يتحملون مسؤولية التوصية باعتماد RFC
قد يساعد أي عضو في المجتمع من خلال تقديم ملاحظات حول ما إذا كانت RFC ستلبي احتياجاتهم.
رعاة RFC
الراعي هو مشرف على المشروع مسؤول عن ضمان أفضل نتيجة ممكنة لعملية RFC. هذا يتضمن:
- الدعوة للتصميم المقترح.
- توجيه RFC للالتزام باتفاقيات التصميم والأسلوب الحالية.
- توجيه لجنة المراجعة للتوصل إلى توافق مثمر.
- إذا طلبت لجنة المراجعة تغييرات ، فتأكد من إجرائها واطلب الموافقة اللاحقة من أعضاء اللجنة.
- إذا انتقل RFC إلى التنفيذ:
- التأكد من أن التنفيذ المقترح يلتزم بالتصميم.
- التنسيق مع الأطراف المناسبة لتنفيذ الأراضي بنجاح.
لجان مراجعة RFC
تقرر لجنة المراجعة على أساس الإجماع ما إذا كانت ستوافق على التغييرات أو ترفضها أو تطلبها. هم مسؤولون عن:
- التأكد من مراعاة البنود الموضوعية للتعليقات العامة.
- إضافة ملاحظات اجتماعهم كتعليقات على العلاقات العامة.
- إبداء أسباب قراراتهم.
قد يتغير تشكيل لجنة المراجعة وفقًا لأسلوب الحوكمة والقيادة الخاصة لكل مشروع. بالنسبة إلى TensorFlow الأساسي ، ستتألف اللجنة من المساهمين في مشروع TensorFlow الذين لديهم خبرة في مجال المجال المعني.
أعضاء المجتمع وعملية RFC
الغرض من طلبات التعليقات (RFCs) هو ضمان تمثيل المجتمع جيدًا وتقديمه من خلال التغييرات الجديدة على TensorFlow. تقع على عاتق أعضاء المجتمع مسؤولية المشاركة في مراجعة طلبات التعليقات عندما يكون لديهم مصلحة في النتيجة.
يجب على أعضاء المجتمع المهتمين بـ RFC:
- قدم التغذية الراجعة في أقرب وقت ممكن لإتاحة الوقت الكافي للنظر فيها.
- اقرأ طلبات التعليقات جيدًا قبل تقديم التعليقات.
- كن متحضرًا وبناءً .
تنفيذ الميزات الجديدة
بمجرد الموافقة على RFC ، يمكن أن يبدأ التنفيذ.
إذا كنت تعمل على كود جديد لتطبيق RFC:
- تأكد من فهمك للميزة والتصميم المعتمد في RFC. اطرح الأسئلة وناقش النهج قبل بدء العمل.
- يجب أن تتضمن الميزات الجديدة اختبارات وحدة جديدة تتحقق من عمل الميزة على النحو المتوقع. من الجيد كتابة هذه الاختبارات قبل كتابة الكود.
- اتبع دليل نمط كود TensorFlow
- إضافة أو تحديث وثائق API ذات الصلة. ارجع إلى RFC في الوثائق الجديدة.
- اتبع أي إرشادات أخرى موضحة في ملف
CONTRIBUTING.mdفي ملف إعادة الشراء الخاص بالمشروع الذي تساهم فيه. - قم بإجراء اختبارات الوحدة قبل إرسال التعليمات البرمجية الخاصة بك.
- اعمل مع راعي RFC للحصول على الرمز الجديد بنجاح.
إبقاء الشريط عالياً
بينما نشجع كل مساهم ونحتفل به ، يظل مستوى قبول RFC مرتفعًا عن عمد. قد يتم رفض ميزة جديدة أو تحتاج إلى مراجعة كبيرة في أي من هذه المراحل:
- محادثات التصميم الأولية في القائمة البريدية ذات الصلة.
- عدم تعيين كفيل.
- الاعتراضات الحرجة خلال مرحلة التغذية الراجعة.
- عدم تحقيق الإجماع أثناء مراجعة التصميم.
- المخاوف التي أثيرت أثناء التنفيذ (على سبيل المثال: عدم القدرة على تحقيق التوافق العكسي ، مخاوف بشأن الصيانة).
إذا كانت هذه العملية تعمل بشكل جيد ، فمن المتوقع أن تفشل طلبات التعليقات في المراحل السابقة وليس اللاحقة. RFC المعتمد لا يضمن الالتزام بالتنفيذ ، ولا يزال قبول تنفيذ RFC المقترح خاضعًا لعملية مراجعة الكود المعتادة.
إذا كان لديك أي أسئلة حول هذه العملية ، فلا تتردد في طرحها على القائمة البريدية للمطورين أو تقديم مشكلة في tensorflow / community .