سواء كنت تقوم بإضافة دالة خسارة، أو تحسين تغطية الاختبار، أو كتابة RFC لتغيير كبير في التصميم، فإن هذا الجزء من دليل المساهم سيساعدك على البدء. شكرًا لك على عملك واهتمامك بتحسين TensorFlow.
قبل أن تبدأ
قبل المساهمة بالكود المصدري لمشروع TensorFlow، يرجى مراجعة ملف CONTRIBUTING.md في مستودع GitHub الخاص بالمشروع. على سبيل المثال، راجع ملف CONTRIBUTING.md في مستودع TensorFlow الأساسي. يُطلب من جميع المساهمين في الكود التوقيع على اتفاقية ترخيص المساهم (CLA).
لتجنب تكرار العمل، يرجى مراجعة طلبات التعليقات الحالية أو المقترحة والاتصال بالمطورين في منتديات TensorFlow ( Developers@tensorflow.org ) قبل بدء العمل على ميزة غير تافهة. نحن انتقائيون إلى حد ما عندما نقرر إضافة وظائف جديدة، وأفضل طريقة للمساهمة ومساعدة المشروع هي العمل على المشكلات المعروفة.
قضايا للمساهمين الجدد
يجب على المساهمين الجدد البحث عن العلامات التالية عند البحث عن المساهمة الأولى في قاعدة تعليمات TensorFlow البرمجية. نوصي بشدة بأن يقوم المساهمون الجدد بمعالجة مشاريع "الإصدار الأول الجيد" و"الترحيب بالمساهمات" أولاً؛ وهذا يساعد المساهم على التعرف على سير عمل المساهمة، ويساعد المطورين الأساسيين على التعرف على المساهم.
إذا كنت مهتمًا بتعيين فريق للمساعدة في معالجة مشكلة واسعة النطاق أو ميزة جديدة، فيرجى إرسال بريد إلكتروني إلى مجموعة Developers@ ومراجعة قائمتنا الحالية لطلبات RFC.
مراجعة الكود
تخضع الميزات الجديدة وإصلاحات الأخطاء وأي تغييرات أخرى في قاعدة التعليمات البرمجية لمراجعة التعليمات البرمجية.
تعد مراجعة التعليمات البرمجية التي ساهمت في المشروع كطلبات سحب عنصرًا حاسمًا في تطوير TensorFlow. نحن نشجع أي شخص على البدء في مراجعة التعليمات البرمجية المقدمة من المطورين الآخرين، خاصة إذا كانت هذه الميزة من المحتمل أن تستخدمها.
فيما يلي بعض الأسئلة التي يجب وضعها في الاعتبار أثناء عملية مراجعة الكود:
- هل نريد هذا في TensorFlow؟ هل من المحتمل أن يتم استخدامها؟ هل يعجبك هذا التغيير، كمستخدم لـ TensorFlow، وتنوي استخدامه؟ هل هذا التغيير في نطاق TensorFlow؟ هل ستكون تكلفة صيانة ميزة جديدة تستحق فوائدها؟
- هل يتوافق الكود مع TensorFlow API؟ هل الوظائف والفئات والمعلمات العامة جيدة التسمية ومصممة بشكل حدسي؟
هل يشمل التوثيق؟ هل تم تسمية جميع الوظائف العامة والفئات والمعلمات وأنواع الإرجاع والسمات المخزنة وفقًا لاتفاقيات TensorFlow وتوثيقها بوضوح؟ هل تم وصف الوظيفة الجديدة في وثائق TensorFlow وتوضيحها بالأمثلة، كلما أمكن ذلك؟ هل يتم تقديم الوثائق بشكل صحيح؟
هل الكود قابل للقراءة من قبل الإنسان؟ هل هو منخفض في التكرار؟ هل يجب تحسين أسماء المتغيرات من أجل الوضوح أو الاتساق؟ هل يجب إضافة التعليقات؟ هل يجب إزالة أي تعليقات باعتبارها غير مفيدة أو غريبة؟
هل الكود فعال؟ هل يمكن إعادة كتابتها بسهولة لتعمل بكفاءة أكبر؟
هل الكود متوافق مع الإصدارات السابقة من TensorFlow؟
هل سيضيف الكود الجديد تبعيات جديدة إلى المكتبات الأخرى؟
اختبار وتحسين تغطية الاختبار
يعد اختبار الوحدة عالي الجودة حجر الزاوية في عملية تطوير TensorFlow. لهذا الغرض، نستخدم صور Docker. يتم تسمية وظائف الاختبار بشكل مناسب، وهي مسؤولة عن التحقق من صحة الخوارزميات بالإضافة إلى الخيارات المختلفة للتعليمات البرمجية.
يجب أن تتضمن جميع الميزات الجديدة وإصلاحات الأخطاء تغطية اختبارية كافية. نرحب أيضًا بمساهمات حالات الاختبار الجديدة أو التحسينات على الاختبارات الحالية. إذا اكتشفت أن اختباراتنا الحالية ليست كاملة - حتى لو لم يكن ذلك يسبب خطأً حاليًا - فيرجى تقديم مشكلة وطلب سحب، إن أمكن.
للحصول على تفاصيل محددة حول إجراءات الاختبار في كل مشروع TensorFlow، راجع ملفات README.md و CONTRIBUTING.md في مستودع المشروع على GitHub.
من المخاوف الخاصة في الاختبار المناسب :
- هل تم اختبار كل وظيفة عامة وفصل دراسي ؟
- هل تم اختبار مجموعة معقولة من المعلمات وقيمها وأنواعها ومجموعاتها؟
- هل تتحقق الاختبارات من صحة الكود ، وأنه يفعل ما تقول الوثائق أن الكود يهدف إلى القيام به؟
- إذا كان التغيير إصلاحًا للأخطاء، فهل تم تضمين اختبار عدم الانحدار ؟
- هل تجتاز اختبارات بناء التكامل المستمر ؟
- هل تغطي الاختبارات كل سطر من التعليمات البرمجية؟ إذا لم يكن الأمر كذلك، فهل الاستثناءات معقولة وصريحة؟
إذا وجدت أي مشاكل، يرجى النظر في مساعدة المساهم على فهم تلك المشاكل وحلها.
تحسين رسائل الخطأ أو السجلات
نحن نرحب بالمساهمات التي تعمل على تحسين رسائل الخطأ والتسجيل.
سير عمل المساهمة
مساهمات التعليمات البرمجية - إصلاحات الأخطاء، التطوير الجديد، تحسين الاختبار - تتبع جميعها سير عمل يتمحور حول GitHub. للمشاركة في تطوير TensorFlow، قم بإعداد حساب GitHub. ثم:
شوكة الريبو الذي تخطط للعمل عليه. انتقل إلى صفحة مستودع المشروع واستخدم زر Fork . سيؤدي هذا إلى إنشاء نسخة من الريبو، تحت اسم المستخدم الخاص بك. (لمزيد من التفاصيل حول كيفية تفرع المستودع، راجع هذا الدليل .)
استنساخ الريبو لنظامك المحلي.
$ git clone git@github.com:your-user-name/project-name.gitقم بإنشاء فرع جديد لعقد عملك.
$ git checkout -b new-branch-nameاعمل على الكود الجديد الخاص بك. كتابة الاختبارات وتنفيذها.
ارتكب التغييرات الخاصة بك.
$ git add -A$ git commit -m "commit message here"ادفع تغييراتك إلى GitHub repo الخاص بك.
$ git push origin branch-nameافتح طلب السحب (PR). انتقل إلى مستودع المشروع الأصلي على GitHub. ستكون هناك رسالة حول الفرع الذي تم دفعه مؤخرًا، تسألك عما إذا كنت ترغب في فتح طلب سحب. اتبع المطالبات، وقارن بين المستودعات ، وأرسل العلاقات العامة. سيؤدي هذا إلى إرسال بريد إلكتروني إلى الملتزمين. قد ترغب في التفكير في إرسال بريد إلكتروني إلى القائمة البريدية لمزيد من الرؤية. (لمزيد من التفاصيل، راجع دليل GitHub حول العلاقات العامة .
سيقوم المشرفون والمساهمون الآخرون بمراجعة العلاقات العامة الخاصة بك . يرجى المشاركة في المحادثة، ومحاولة إجراء أي تغييرات مطلوبة . بمجرد الموافقة على طلب الشراء، سيتم دمج الرمز.
قبل العمل على مساهمتك التالية ، تأكد من تحديث مستودعك المحلي.
ضبط جهاز التحكم عن بعد المنبع. (ما عليك سوى القيام بذلك مرة واحدة لكل مشروع، وليس كل مرة.)
$ git remote add upstream git@github.com:tensorflow/project-repo-nameالتبديل إلى الفرع الرئيسي المحلي.
$ git checkout masterهدم التغييرات من المنبع.
$ git pull upstream masterادفع التغييرات إلى حساب GitHub الخاص بك. (اختياري، ولكنه ممارسة جيدة.)
$ git push origin masterقم بإنشاء فرع جديد إذا كنت تبدأ عملاً جديدًا.
$ git checkout -b branch-name
موارد git وGitHub الإضافية:
قائمة مرجعية للمساهم
- اقرأ المبادئ التوجيهية المساهمة .
- اقرأ مدونة قواعد السلوك .
- تأكد من توقيعك على اتفاقية ترخيص المساهم (CLA) .
- تحقق مما إذا كانت تغييراتك متوافقة مع الإرشادات .
- تحقق مما إذا كانت تغييراتك متوافقة مع نمط ترميز TensorFlow .
- قم بإجراء اختبارات الوحدة .