يمكن للجميع المساهمة في OpenXLA، ونحن نقدّر مساهمات الجميع. هناك عدة طرق للمساهمة، بما في ذلك:
الإجابة عن أسئلة في منتديات المناقشة في OpenXLA (openxla-discuss)
تحسين وثائق OpenXLA أو توسيعها
المساهمة في قاعدة رموز OpenXLA
المساهمة بأي من الطرق المذكورة أعلاه في المنظومة المتكاملة للمكتبات التي تعتمد على OpenXLA
يتّبع مشروع OpenXLA إرشادات منتدى البرامج المفتوحة المصدر من Google.
قبل البدء
توقيع اتفاقية ترخيص المساهم
ويجب أن تكون المساهمات في هذا المشروع مصحوبةً باتفاقية ترخيص المساهمين (CLA). تحتفظ أنت (أو صاحب العمل) بحقوق الطبع والنشر لمساهمتك، وهذا ببساطة يمنحنا الإذن باستخدام مساهماتك وإعادة توزيعها كجزء من المشروع.
إذا سبق لك أو لصاحب العمل الحالي التوقيع على اتفاقية ترخيص المحتوى من Google (حتى لو كانت متعلّقة بمشروع مختلف)، لن تحتاج على الأرجح إلى توقيعها مرة أخرى.
يمكنك الانتقال إلى <https://cla.developers.google.com/> للاطّلاع على اتفاقياتك الحالية أو لتوقيع اتفاقيات جديدة.
مراجعة مدوّنة السلوك
يتبع هذا المشروع مدوّنة السلوك الخاصة بـ Tensorflow.
عملية المساهمة
دليل المطوّر
للحصول على دليل حول كيفية إعداد بيئة تطوير لـ OpenXLA، بما في ذلك الحصول على رمز وإنشاءه وإجراء الاختبارات وإرسال التغييرات، يُرجى الرجوع إلى دليل المطوّر.
معايير التعليمات البرمجية
أسلوب الترميز: نتّبع دليل أسلوب الترميز من Google. يمكنك الاطّلاع على وجه التحديد على دليلَي C/C++ وPython. يجب أن تتوافق كل التعليمات البرمجية التي يتم إرسالها بشكل صارم مع أدلة النمط هذه.
تغييرات صغيرة: نتّبع الممارسات الهندسية في Google. وعلى وجه الخصوص، يُرجى الاطّلاع على الدليل الخاص بكتابة التغييرات المكثفة. سيؤدي ذلك إلى زيادة سرعة دمج الرموز بشكل كبير بسبب تحسين إمكانية المراجعة، وتقليل احتمال حدوث أي آثار جانبية غير مقصودة. حتى لو كان لديك تغيير كبير، فهناك العديد من الاستراتيجيات لتقسيمه إلى تغييرات تدريجية أكثر.
تغطية الاختبار: يجب أن تشمل جميع التغييرات اختبارات الوحدات المناسبة. يجب ألا تعتمد اختبارات الوحدات على توقيتات أجهزة محددة (وحدة المعالجة المركزية (CPU) ووحدة معالجة الرسومات وما إلى ذلك)، ويجب أن تستخدم بشكل حرية نماذج تجريبية ومواد مزيّفة من أجل إجراء اختبارات حاسمة ومركزة. إن التغييرات التي تسعى إلى توسيع نطاق التعليمات البرمجية الحالية التي يصعب اختبارها حاليًا يجب أن تؤدي إلى إجراء تحسينات مناسبة على قابلية الاختبار.
يجب أن تتضمن جميع التغييرات نتائج قياس أداء مناسبة أيضًا في عنوان التغيير لضمان فهم الفوائد بوضوح.
عندما تكون في شكوك بشأن الاصطلاحات داخل التعليمات البرمجية، من الأفضل دائمًا فحص التعليمات البرمجية الموجودة مسبقًا ومحاولة اتباع الأنماط الموجودة بالفعل في OpenXLA.
عملية المراجعة
يجب مراجعة جميع التقديمات، بما في ذلك ما قدمه أعضاء المشروع. نحن نستخدم طلبات سحب GitHub لهذا الغرض. ارجع إلى مساعدة GitHub لمزيد من المعلومات عن استخدام طلبات السحب.
يجب أن تتبع التعليمة البرمجية جميع المعايير المذكورة أعلاه قبل المراجعة. هذه ليست اختيارية، ومن المهم أن يتأكد مقدّم الشكوى من توافق الرمز الخاص به قبل طلب المراجعة، وذلك لضمان قبول التغييرات في الوقت المناسب.
يجب اجتياز جميع الاختبارات. إذا تبيّن لك أن الاختبار معطّل وأن المشكلة غير مرتبطة ببيئة الإصدار أو التغييرات التي أجريتها، يُرجى التواصل مع المشرفين.
حاول تجنب اتساع النطاق أثناء عملية المراجعة. وهذه مسؤولية كل من مقدم الشكوى والمراجع. إذا بدأ التغيير في أن يصبح كبيرًا جدًا، ففكر في تقسيمه إلى تغييرات متعددة.
قبل دمج التغيير، سيخضع للاختبار الداخلي الذي يستخدم رمزًا داخليًا في Google ومورِّدي الأجهزة الآخرين. ومن المحتمل أن يؤدي ذلك إلى إضافة خطوات إضافية إلى عملية المراجعة إذا كانت هناك أخطاء في الاختبارات الداخلية لم ترصدها أداة CI العامة. سيبلغ موظف Google الذي يراجع التغيير الذي أجريته أي إخفاقات في الاختبار الداخلي ويصف ما يجب إصلاحه.
الأسئلة الشائعة (FAQ)
"إنّ تغيير البنية الأساسية هذا غير مرتبط بعلاقات عامة. لماذا يجب أن أفعل ذلك؟"
ليس لدى فريق XLA فريق مخصّص للبنية الأساسية، لذا فالأمر متروك لنا جميعًا لبناء مكتبات مساعِدة وتجنُّب الديون التقنية. نعتبر ذلك جزءًا منتظمًا من إجراء تغييرات على XLA، ومن المتوقع أن يشارك الجميع فيها. عند كتابة التعليمات البرمجية، ننشئ بشكل عام بنية أساسية حسب الحاجة.
قد يطلب منك مراجعو XLA إنشاء بعض البنية التحتية (أو إجراء تغيير كبير على PR) بالإضافة إلى النسخة PR التي كتبتها. قد يبدو هذا الطلب غير ضروري أو متعامد مع التغيير الذي تحاول إجراؤه. من المحتمل أن يرجع هذا إلى عدم تطابق توقعاتك حول مقدار البنية الأساسية التي تحتاج إلى إنشائها وتوقعات المراجع بشأن ذلك.
لا بأس في عدم تطابق التوقعات! هذا أمر متوقع عندما تكون جديدًا في مشروع (ويحدث أحيانًا لنا قبعات قديمة). من المحتمل أن تكون المشروعات التي عملت عليها في الماضي لها توقعات مختلفة. هذا أيضًا جيد ومتوقع! لا يعني ذلك أن أيًا من هذه المشروعات يتبع نهجًا خاطئًا؛ فهم مختلفون فقط. ندعوك إلى تلقي الطلبات الواردة أدناه إلى جانب جميع تعليقات المراجعة الأخرى كفرصة لمعرفة ما نتوقعه في هذا المشروع.
"هل يمكنني مخاطبة تعليقك في مقالة عامة في المستقبل؟"
هناك سؤال شائع يتعلق بطلبات البنية الأساسية (أو الطلبات الكبيرة الأخرى) في "تقارير العلاقات العامة" (PR) ما إذا كان يجب إجراء التغيير في "PR" الأصلي أم لا، أو ما إذا كان يمكن إجراء ذلك كمتابعة في "PR" المستقبلي أم لا.
بشكل عام، لا تسمح XLA لمؤلفي العلاقات العامة بمعالجة تعليقات المراجعة باستخدام علاقات عامة للمتابعة. عندما يقرر المراجع أن شيئًا ما يحتاج إلى معالجة في علاقات عامة معينة، نتوقع بشكل عام من المؤلفين أن يناقشه في العلاقات العامة، حتى لو كان ما هو مطلوب هو تغيير كبير. ينطبق هذا المعيار خارجيًا وداخليًا أيضًا داخل Google.
وهناك بضعة أسباب تبنّي XLA لهذا المنهج.
الثقة: يُعدّ اكتساب ثقة المُراجع عنصرًا أساسيًا. في مشروع مفتوح المصدر، يمكن للمساهمين الظهور أو الاختفاء حسب الرغبة. بعد أن نتفق على العلاقات العامة، لا يكون لدى المراجعين أي وسيلة لضمان إنجاز أي متابعات موعودة.
التأثير في المطوّرين الآخرين: إذا أرسلت مقالة عامة حول جزء معيّن من XLA، فهناك احتمالٌ كبير أن ينظر أشخاص آخرون إلى الجزء نفسه. إذا قبلنا الديون التقنية في العلاقات العامة، سيتأثر كل من يطّلع على هذا الملف به إلى أن يتم إرسال طلب المتابعة.
معدّل نقل بيانات المراجع: يؤدي تأجيل أي تغيير في المتابعة إلى فرض تكاليف متعددة على المراجعين الذين سبق أن تم تحميلهم بشكل زائد. من المحتمل أن ينسى المراجعون ما كان موضوع العلاقات العامة الأول أثناء انتظار المتابعة، مما يجعل المراجعة التالية أكثر صعوبة. أيضًا، سيتعين على المراجعين تتبع المتابعات المتوقعة، والتأكد من حدوثها بالفعل. إذا كان من الممكن إجراء التغيير بحيث يكون متعامدًا حقًا مع العلاقات العامة الأصلية بحيث يمكن لمراجع آخر أن يراجعه، فلن يمثل معدل نقل البيانات مشكلةً. من واقع خبرتنا، نادرًا ما يكون هذا هو الحال.