Каждый может внести свой вклад в OpenXLA, и мы ценим вклад каждого. Есть несколько способов внести свой вклад, в том числе:
Отвечаем на вопросы на дискуссионных форумах OpenXLA (openxla-discuss)
Улучшение или расширение документации OpenXLA.
Вклад в кодовую базу OpenXLA
Вклад любым из вышеперечисленных способов в более широкую экосистему библиотек, построенных на OpenXLA.
Проект OpenXLA следует принципам сообщества открытого исходного кода Google .
Прежде чем вы начнете
Подпишите лицензионное соглашение для участников
Вклад в этот проект должен сопровождаться Лицензионным соглашением участника (CLA). Вы (или ваш работодатель) сохраняете авторские права на свой вклад; это просто дает нам разрешение использовать и распространять ваш вклад в рамках проекта.
Если вы или ваш нынешний работодатель уже подписали Google CLA (даже если оно было для другого проекта), вам, вероятно, не нужно делать это снова.
Посетите < https://cla.developers.google.com/ >, чтобы просмотреть текущие соглашения или подписать новое.
Ознакомьтесь с Кодексом поведения
Этот проект следует Кодексу поведения Tensorflow .
Процесс внесения вклада
Руководство разработчика
Руководство по настройке среды разработки для OpenXLA, включая получение кода, его сборку, запуск тестов и отправку изменений, см. в Руководстве разработчика .
Стандарты кода
Стиль кодирования : мы следуем руководству по стилю кода Google . В частности, см. руководства по C/C++ и Python . Весь представленный код должен строго соответствовать этим руководствам по стилю.
Компактные изменения : мы следуем инженерным практикам Google . В частности, обратите внимание на руководство по написанию компактных изменений . Это значительно увеличит скорость объединения вашего кода за счет улучшения возможности проверки и снижения вероятности непреднамеренных побочных эффектов изменений. Даже если у вас есть большое изменение, существует множество стратегий, позволяющих разбить его на более постепенные изменения.
Тестовое покрытие : все изменения должны включать соответствующие модульные тесты. Модульные тесты не должны зависеть от таймингов конкретного оборудования (ЦП, графического процессора и т. д.) и должны широко использовать макеты и подделки для проведения детерминированных и целенаправленных тестов. Изменения, направленные на расширение существующего кода, который в настоящее время трудно тестировать, должны внести соответствующие улучшения в тестируемость.
Все изменения должны включать соответствующие результаты тестов, а также в название изменения, чтобы обеспечить четкое понимание преимуществ.
Если у вас есть сомнения относительно соглашений внутри кода, всегда полезно изучить уже существующий код и попытаться следовать шаблонам, уже имеющимся в OpenXLA.
Обзор процесса
Все материалы, включая материалы участников проекта, требуют рассмотрения. Для этой цели мы используем запросы на извлечение GitHub. Обратитесь к справке GitHub для получения дополнительной информации об использовании запросов на включение.
Перед рассмотрением код должен соответствовать всем стандартам, перечисленным выше. Это не является обязательным, и очень важно, чтобы отправитель убедился, что его код соответствует требованиям, прежде чем запрашивать проверку, чтобы обеспечить своевременное принятие изменений.
Все тесты должны пройти . Если вы обнаружите, что тест не работает и проблема не связана с вашей средой сборки или другими изменениями, обратитесь к сопровождающим.
Постарайтесь избежать расширения объема работ в процессе проверки. Это ответственность как автора, так и рецензента. Если изменение становится слишком большим, рассмотрите возможность разбить его на несколько изменений.
Прежде чем изменение будет объединено, оно пройдет внутреннее тестирование с использованием внутреннего кода Google и других поставщиков оборудования. Это потенциально может добавить дополнительные шаги к процессу проверки, если во внутренних тестах возникают сбои, которые наш общедоступный CI не обнаруживает. Сотрудник Google, рассматривающий ваше изменение, сообщит обо всех ошибках внутреннего тестирования и опишет, что необходимо исправить.
Часто задаваемые вопросы (FAQ)
«Это изменение инфраструктуры не связано с моим пиаром. Зачем мне это делать?»
У команды XLA нет специальной команды по инфраструктуре, поэтому мы все должны создавать вспомогательные библиотеки и избегать технического долга. Мы считаем, что это обычная часть внесения изменений в XLA, и ожидается, что каждый будет в ней участвовать. Обычно мы создаем инфраструктуру по мере необходимости при написании кода.
Рецензенты XLA могут попросить вас создать некоторую инфраструктуру (или иным образом внести значительные изменения в PR) вместе с написанным вами PR. Этот запрос может показаться ненужным или противоречащим изменению, которое вы пытаетесь внести. Вероятно, это связано с несоответствием между вашими ожиданиями относительно того, сколько информации вам нужно создать, и ожиданиями вашего рецензента на этот счет.
Несовпадение ожиданий – это нормально! Это ожидаемо, когда вы новичок в проекте (и иногда это случается даже с нами, старыми шляпами). Вполне вероятно, что проекты, над которыми вы работали в прошлом, имеют другие ожидания. Это тоже нормально и ожидаемо! Это не означает, что ни один из этих проектов имеет неправильный подход; они просто другие. Мы приглашаем вас принять инфраструктурные запросы вместе со всеми другими отзывами, чтобы узнать, чего мы ожидаем от этого проекта.
«Могу ли я рассмотреть ваш комментарий в будущем пиаре?»
В отношении запросов на инфраструктуру (или других крупных запросов) в ОР часто возникает вопрос: необходимо ли вносить изменения в первоначальный ОР или можно ли это сделать в качестве дополнения к будущему ОР?
Как правило, XLA не позволяет авторам PR отвечать на комментарии к отзывам с помощью последующих PR. Когда рецензент решает, что что-то необходимо исправить в данном PR, мы обычно ожидаем, что авторы учтут это в этом PR, даже если то, что требуется, является большим изменением. Этот стандарт применяется как снаружи, так и внутри Google.
Есть несколько причин, по которым XLA использует такой подход.
Доверие. Ключевым компонентом является завоевание доверия рецензента. В проекте с открытым исходным кодом участники могут появляться или исчезать по своему желанию. После того как мы одобряем PR, у рецензентов нет возможности гарантировать, что обещанные последующие действия действительно будут выполнены.
Влияние на других разработчиков: если вы отправили PR, касающееся определенной части XLA, велика вероятность, что другие люди просматривают ту же часть. Если мы признаем технический долг в вашем PR, то этот долг будет затрагивать всех, кто просматривает этот файл, до тех пор, пока не будут отправлены последующие действия.
Пропускная способность рецензентов. Отсрочка внесения изменений в последующие действия влечет за собой многочисленные затраты для наших и без того перегруженных рецензентов. Рецензенты, вероятно, забудут, о чем был первый PR, ожидая продолжения, что усложнит следующую рецензию. Кроме того, рецензентам придется отслеживать ожидаемые последующие действия, чтобы убедиться, что они действительно происходят. Если бы изменение можно было внести так, чтобы оно действительно было ортогональным исходному PR и чтобы его мог просмотреть другой рецензент, проблема с пропускной способностью была бы меньшей. По нашему опыту, такое бывает редко.