مشارکت در OpenXLA

همه می توانند به OpenXLA کمک کنند و ما برای مشارکت همه ارزش قائل هستیم. راه های مختلفی برای مشارکت وجود دارد، از جمله:

  • پاسخگویی به سوالات در تالارهای گفتگوی OpenXLA (openxla-discuss)

  • بهبود یا گسترش اسناد OpenXLA

  • مشارکت در پایگاه کد OpenXLA

  • کمک به هر یک از روش‌های بالا در اکوسیستم گسترده‌تر کتابخانه‌های ساخته شده بر روی OpenXLA

پروژه OpenXLA از دستورالعمل‌های جامعه منبع باز Google پیروی می‌کند.

قبل از اینکه شروع کنی

قرارداد مجوز مشارکت کننده را امضا کنید

مشارکت در این پروژه باید با موافقتنامه مجوز مشارکت (CLA) همراه باشد. شما (یا کارفرمایتان) حق چاپ را برای مشارکت خود حفظ می کنید. این به سادگی به ما اجازه استفاده و توزیع مجدد مشارکت های شما را به عنوان بخشی از پروژه می دهد.

اگر شما یا کارفرمای فعلی شما قبلاً Google CLA را امضا کرده اید (حتی اگر برای پروژه دیگری بوده است)، احتمالاً نیازی به انجام مجدد آن ندارید.

برای دیدن قراردادهای فعلی خود یا امضای قرارداد جدید به < https://cla.developers.google.com/ > مراجعه کنید.

قوانین رفتاری را مرور کنید

این پروژه از آیین نامه رفتار تنسورفلو پیروی می کند.

فرآیند مشارکت

راهنمای توسعه دهنده

برای راهنمایی در مورد نحوه تنظیم یک محیط توسعه برای OpenXLA، از جمله دریافت کد، ساخت آن، اجرای آزمایش‌ها و ارسال تغییرات، لطفاً به راهنمای توسعه‌دهنده مراجعه کنید.

استانداردهای کد

  • سبک کدنویسی : ما از راهنمای سبک کد گوگل پیروی می کنیم. به طور خاص راهنمای C/C++ و Python را ببینید. تمام کدهای ارسالی باید کاملاً با این راهنماهای سبک مطابقت داشته باشند.

  • تغییرات فشرده : ما از شیوه های مهندسی Google پیروی می کنیم. به ویژه، لطفاً راهنمای نوشتن تغییرات فشرده را رعایت کنید. انجام این کار به دلیل بهبود قابلیت بازبینی و کاهش احتمال عوارض جانبی ناخواسته تغییر، سرعت ادغام کد خود را تا حد زیادی افزایش می دهد. حتی اگر تغییر بزرگی دارید، استراتژی های زیادی برای تقسیم آن به تغییرات تدریجی تر وجود دارد.

  • پوشش تست : همه تغییرات باید شامل تست های واحد مناسب باشد. تست‌های واحد نباید به زمان‌بندی‌های سخت‌افزاری خاص (CPU، GPU و غیره) وابسته باشند و باید از تقلب‌ها و جعلی‌ها برای انجام تست‌های قطعی و متمرکز استفاده کنند. تغییراتی که به دنبال گسترش کدهای موجود هستند که در حال حاضر آزمایش آن دشوار است، باید بهبودهای مناسبی را در قابلیت آزمایش ایجاد کند.

    همه تغییرات باید شامل نتایج معیار مناسب و همچنین در عنوان تغییر باشد تا اطمینان حاصل شود که مزایا به وضوح درک می شوند.

  • هنگامی که در مورد قراردادهای درون کد شک دارید، همیشه ایده خوبی است که کدهای از قبل موجود را بررسی کنید و سعی کنید از الگوهای موجود در OpenXLA پیروی کنید.

فرآیند بررسی

همه ارسال ها، از جمله ارسالی توسط اعضای پروژه، نیاز به بررسی دارند. برای این منظور از درخواست های کششی GitHub استفاده می کنیم. برای اطلاعات بیشتر در مورد استفاده از درخواست های کشش، با راهنمای GitHub مشورت کنید.

  • کد باید قبل از بررسی از تمام استانداردهای ذکر شده در بالا پیروی کند. این موارد اختیاری نیستند و بسیار مهم است که ارسال‌کننده قبل از درخواست بازبینی از مطابقت کد خود اطمینان حاصل کند تا از پذیرش به موقع تغییرات اطمینان حاصل شود.

  • همه آزمون ها باید قبول شوند . اگر متوجه شدید که یک تست خراب است و مشکل به محیط ساخت شما یا تغییرات دیگری مربوط نمی شود، لطفاً با نگهبانان تماس بگیرید.

  • سعی کنید از خزش دامنه در طول فرآیند بررسی جلوگیری کنید. این مسئولیت هم بر عهده ارسال کننده و هم بر عهده داور است. اگر تغییر شروع به بزرگ شدن کرد، آن را به چند تغییر تقسیم کنید.

  • قبل از اینکه تغییری ادغام شود، تحت آزمایش داخلی قرار می‌گیرد که از کدهای داخلی Google و سایر فروشندگان سخت‌افزار استفاده می‌کند. این به طور بالقوه می‌تواند مراحل بیشتری را به فرآیند بازبینی اضافه کند، در صورتی که در تست‌های داخلی خطاهایی وجود داشته باشد که CI عمومی ما متوجه آن نشود. کارمند Google که تغییر شما را بررسی می‌کند، هرگونه نقص تست داخلی را با شما در میان می‌گذارد و مواردی را که باید اصلاح شود توضیح می‌دهد.

سوالات متداول (سؤالات متداول)

تیم XLA یک تیم زیرساخت اختصاصی ندارد، بنابراین ساخت کتابخانه های کمکی و اجتناب از بدهی های فنی بر عهده همه ماست. ما آن را بخشی منظم از ایجاد تغییرات در XLA می‌دانیم و انتظار می‌رود همه در آن شرکت کنند. ما عموماً در هنگام نوشتن کد زیرساخت‌های مورد نیاز را ایجاد می‌کنیم.

بازبینان XLA ممکن است از شما بخواهند که زیرساختی بسازید (یا تغییر بزرگی در یک PR ایجاد کنید) همراه با PR که نوشته اید. ممکن است این درخواست برای تغییری که می‌خواهید ایجاد کنید غیر ضروری یا متعامد به نظر برسد. این احتمالاً به دلیل عدم تطابق بین انتظارات شما در مورد میزان زیرساختی است که باید بسازید و انتظارات بازبینی کننده شما برای همان.

عدم تطابق در انتظارات اشکالی ندارد! زمانی که شما در یک پروژه جدید هستید، انتظار می رود (و گاهی اوقات حتی برای ما کلاه های قدیمی هم اتفاق می افتد). این احتمال وجود دارد که پروژه هایی که در گذشته روی آنها کار کرده اید، انتظارات متفاوتی داشته باشند. این نیز اشکالی ندارد و انتظار می رود! این بدان معنا نیست که هیچ کدام از این پروژه ها رویکرد اشتباهی دارند. آنها فقط متفاوت هستند ما از شما دعوت می‌کنیم که درخواست‌های زیر را در کنار سایر نظرات بررسی به عنوان فرصتی برای یادگیری آنچه در این پروژه انتظار داریم، بپذیرید.

"آیا می توانم نظر شما را در روابط عمومی آینده بیان کنم؟"

یک سوال متداول در رابطه با درخواست‌های زیرساخت (یا سایر درخواست‌های بزرگ) در روابط عمومی این است که آیا این تغییر باید در روابط عمومی اصلی انجام شود یا خیر، یا اینکه آیا می‌توان آن را به عنوان یک پیگیری در روابط عمومی آینده انجام داد.

به طور کلی، XLA به نویسندگان روابط عمومی اجازه نمی دهد تا نظرات مروری را با روابط عمومی بعدی مورد بررسی قرار دهند. هنگامی که یک بازبین تصمیم می گیرد که چیزی باید در یک PR مشخص مورد توجه قرار گیرد، ما معمولاً از نویسندگان انتظار داریم که در آن روابط عمومی به آن بپردازند، حتی اگر آنچه درخواست شده یک تغییر بزرگ باشد. این استاندارد به صورت خارجی و همچنین داخلی در Google اعمال می شود.

چند دلیل وجود دارد که XLA این رویکرد را اتخاذ می کند.

  • اعتماد: جلب اعتماد داور یک جزء کلیدی است. در یک پروژه منبع باز، مشارکت کنندگان می توانند به میل خود ظاهر یا ناپدید شوند. پس از تأیید روابط عمومی، بازبین‌ها راهی برای اطمینان از اینکه پیگیری‌های وعده داده شده واقعاً انجام می‌شوند، ندارند.

  • تأثیر بر توسعه دهندگان دیگر: اگر یک روابط عمومی را برای لمس بخش خاصی از XLA ارسال کرده اید، این احتمال وجود دارد که دیگران به همان قسمت نگاه کنند. اگر بدهی فنی را در روابط عمومی شما بپذیریم، هرکسی که به این فایل نگاه می کند تا زمانی که پیگیری ارسال شود تحت تأثیر این بدهی قرار می گیرد.

  • پهنای باند بازبین: به تعویق انداختن تغییر به یک پیگیری، هزینه‌های متعددی را بر بازبین‌های ما تحمیل می‌کند. بازبین‌ها احتمالاً فراموش می‌کنند که اولین روابط عمومی درمورد آن چه بوده است، در حالی که منتظر پیگیری هستند، و این کار بررسی بعدی را دشوارتر می‌کند. همچنین، بازبینان باید پیگیری‌های مورد انتظار را پیگیری کنند و مطمئن شوند که واقعاً اتفاق می‌افتند. اگر بتوان این تغییر را به گونه‌ای انجام داد که واقعاً متعامد با PR اصلی باشد تا بازبینی‌کننده دیگری بتواند آن را بررسی کند، پهنای باند مشکل کمتری خواهد داشت. در تجربه ما، به ندرت چنین است.