عملية TensorFlow RFC

تبدأ كل ميزة جديدة في TensorFlow كطلب للتعليق (RFC).

RFC هو مستند يصف المتطلبات والتغييرات المقترحة التي ستحلها. على وجه التحديد، سوف يقوم RFC بما يلي:

  • يتم تنسيقه وفقًا لقالب RFC .
  • يتم إرساله كطلب سحب إلى دليل المجتمع/rfcs .
  • تخضع للمناقشة واجتماع المراجعة قبل القبول.

الغرض من طلب TensorFlow للتعليقات (RFC) هو إشراك مجتمع TensorFlow في التطوير، من خلال الحصول على تعليقات من أصحاب المصلحة والخبراء، وإبلاغ تغييرات التصميم على نطاق واسع.

كيفية تقديم RFC

  1. قبل إرسال RFC، ناقش أهدافك مع المساهمين في المشروع والمشرفين عليه واحصل على تعليقات مبكرة. استخدم القائمة البريدية للمطورين للمشروع المعني (developers@tensorflow.org، أو القائمة الخاصة بـ SIG ذات الصلة).

  2. قم بصياغة RFC الخاص بك.

    • اقرأ معايير مراجعة التصميم
    • اتبع قالب RFC .
    • قم بتسمية ملف RFC الخاص بك YYYYMMDD-descriptive-name.md ، حيث YYYYMMDD هو تاريخ الإرسال، descriptive-name يتعلق بعنوان RFC الخاص بك. (على سبيل المثال، إذا كان RFC الخاص بك يحمل عنوان Parallel Widgets API ، فيمكنك استخدام اسم الملف 20180531-parallel-widgets.md .
    • إذا كان لديك صور أو ملفات مساعدة أخرى، فقم بإنشاء دليل بالنموذج YYYYMMDD-descriptive-name لتخزين تلك الملفات فيه.

    بعد كتابة مسودة RFC، احصل على تعليقات من المشرفين والمساهمين قبل إرسالها.

    إن كتابة كود التنفيذ ليس شرطًا، ولكنه قد يساعد في تصميم المناقشات.

  3. توظيف الراعي.

    • يجب أن يكون الراعي هو القائم على المشروع.
    • قم بتحديد الراعي في RFC، قبل نشر العلاقات العامة.

    يمكنك نشر RFC بدون جهة راعية، ولكن إذا لم يكن هناك راعي خلال شهر من نشر العلاقات العامة، فسيتم إغلاقه.

  4. أرسل RFC الخاص بك كطلب سحب إلى Tensorflow/community/rfcs .

    قم بتضمين جدول الرأس ومحتويات قسم الهدف في التعليق على طلب السحب الخاص بك، باستخدام Markdown. للحصول على مثال، يرجى الاطلاع على هذا المثال RFC . قم بتضمين مقابض GitHub للمؤلفين المشاركين والمراجعين والجهات الراعية.

    في الجزء العلوي من PR، حدد المدة التي ستستغرقها فترة التعليق. يجب أن يكون ذلك لمدة أسبوعين على الأقل من تاريخ نشر العلاقات العامة.

  5. أرسل القائمة البريدية للمطورين عبر البريد الإلكتروني مع وصف موجز ورابط للعلاقات العامة وطلب المراجعة. اتبع تنسيق المراسلات السابقة، كما ترون في هذا المثال .

  6. سيطلب الراعي عقد اجتماع للجنة المراجعة، في موعد لا يتجاوز أسبوعين بعد نشر RFC PR. إذا كانت المناقشة نشطة، فانتظر حتى تستقر قبل الذهاب للمراجعة. الهدف من اجتماع المراجعة هو حل المشكلات البسيطة؛ وينبغي التوصل إلى توافق في الآراء بشأن القضايا الرئيسية مسبقا.

  7. قد يوافق الاجتماع على 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:

  • تقديم الملاحظات في أقرب وقت ممكن لإتاحة الوقت الكافي للنظر فيها.
  • اقرأ RFCs جيدًا قبل تقديم التعليقات.
  • كن متحضرًا وبناءً .

تنفيذ الميزات الجديدة

بمجرد الموافقة على RFC، يمكن البدء في التنفيذ.

إذا كنت تعمل على تعليمات برمجية جديدة لتنفيذ RFC:

  • تأكد من أنك تفهم الميزة والتصميم المعتمد في RFC. اطرح الأسئلة وناقش النهج قبل بدء العمل.
  • يجب أن تتضمن الميزات الجديدة اختبارات وحدة جديدة تتحقق من أن الميزة تعمل كما هو متوقع. إنها فكرة جيدة أن تكتب هذه الاختبارات قبل كتابة الكود.
  • اتبع دليل نمط كود TensorFlow
  • قم بإضافة أو تحديث وثائق API ذات الصلة. قم بالرجوع إلى RFC في الوثائق الجديدة.
  • اتبع أي إرشادات أخرى منصوص عليها في ملف CONTRIBUTING.md في مستودع المشروع الذي تساهم فيه.
  • قم بإجراء اختبارات الوحدة قبل إرسال الكود الخاص بك.
  • اعمل مع راعي RFC للحصول على الرمز الجديد بنجاح.

الحفاظ على ارتفاع الشريط

في حين أننا نشجع كل مساهم ونحتفل به، إلا أن مستوى قبول RFC يظل مرتفعًا عن عمد. قد يتم رفض ميزة جديدة أو تحتاج إلى مراجعة كبيرة في أي من هذه المراحل:

  • محادثات التصميم الأولية على القائمة البريدية ذات الصلة.
  • الفشل في تجنيد الراعي.
  • الاعتراضات الحرجة خلال مرحلة ردود الفعل.
  • الفشل في التوصل إلى توافق في الآراء أثناء مراجعة التصميم.
  • المخاوف التي أثيرت أثناء التنفيذ (على سبيل المثال: عدم القدرة على تحقيق التوافق مع الإصدارات السابقة، والمخاوف بشأن الصيانة).

إذا كانت هذه العملية تعمل بشكل جيد، فمن المتوقع أن تفشل طلبات RFC في المراحل السابقة، وليس اللاحقة. لا يعد RFC المعتمد ضمانًا للالتزام بالتنفيذ، ولا يزال قبول تنفيذ RFC المقترح خاضعًا لعملية مراجعة التعليمات البرمجية المعتادة.

إذا كانت لديك أي أسئلة حول هذه العملية، فلا تتردد في طرحها على القائمة البريدية للمطورين أو تقديم مشكلة في Tensorflow/community .