Google is committed to advancing racial equity for Black communities. See how.
ترجمت واجهة Cloud Translation API‏ هذه الصفحة.
Switch to English

عملية TensorFlow RFC

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

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

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

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

كيفية إرسال RFC

  1. قبل إرسال طلب طلب تقديمي ، ناقش أهدافك مع المساهمين في المشروع والمشرفين عليه واحصل على تعليقات مبكرة. استخدم القائمة البريدية للمطورين للمشروع المعني (developer@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 ، قبل نشر PR.

    تستطيع الرد على RFC بدون كفيل، ولكن إذا غضون شهر من نشر PR لا يوجد حتى الآن الراعي، سيتم إغلاقه.

  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 ، يمكن أن يبدأ التنفيذ.

إذا كنت تعمل على كود جديد لتطبيق RFC:

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

إبقاء الشريط عالياً

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

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

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

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