Każdy może wnieść swój wkład do OpenXLA. Można ją współtworzyć na kilka sposobów:
odpowiadanie na pytania na forach dyskusyjnych OpenXLA (openxla-dyskusja);
Ulepszenie lub rozszerzenie dokumentacji OpenXLA
Udział w bazie kodu OpenXLA
Włączenie wymienionych wyżej rozwiązań w szerszy ekosystem bibliotek opartych na OpenXLA.
Projekt OpenXLA jest zgodny z wytycznymi dla społeczności Google open source.
Zanim zaczniesz
Podpisz Umowę licencyjną dla współtwórców
Wkładami w ten projekt muszą towarzyszyć umowa licencyjna współtwórcy (CLA). Ty lub Twój pracodawca zachowujecie prawa autorskie do przekazanego mu zespołu. Daje nam to jedynie pozwolenie na wykorzystywanie i rozpowszechnianie tych treści w ramach projektu.
Jeśli umowa CLA została już podpisana przez Ciebie lub Twojego obecnego pracodawcy (nawet jeśli dotyczyła ona innego projektu), prawdopodobnie nie musisz robić tego ponownie.
Wejdź na <https://cla.developers.google.com/>, aby zobaczyć bieżące umowy lub podpisać nowe.
Zapoznaj się z Kodeksem postępowania
Ten projekt jest zgodny z kodeksem postępowania Tensorflow.
Proces przekazywania darowizn
Przewodnik dla programistów
Instrukcje konfigurowania środowiska programistycznego dla OpenXLA, w tym pobierania kodu, tworzenia go, przeprowadzania testów i przesyłania zmian, znajdziesz w przewodniku dla programistów.
Standardy kodowania
Styl kodowania: postępujemy zgodnie z przewodnikiem Google po stylu kodu. W szczególności zapoznaj się z przewodnikami po C/C++ i Pythonie. Każdy przesyłany kod musi być ściśle zgodny z tymi wskazówkami dotyczącymi stylu.
Kompaktowe zmiany: przestrzegamy metod inżynieryjnych Google. Szczególnie zapoznaj się ze wskazówkami dotyczącymi wprowadzania zmian kompaktowych. Dzięki temu znacznie przyspieszy to proces łączenia kodu, co usprawni jego sprawdzanie i zmniejszy ryzyko przypadkowych skutków ubocznych zmian. Nawet jeśli wprowadzasz duże zmiany, istnieje wiele strategii dzielenia ich na stopniowe zmiany.
Zakres testu: wszystkie zmiany powinny obejmować odpowiednie testy jednostkowe. Testy jednostkowe nie powinny zależeć od czasu trwania konkretnego sprzętu (procesora, GPU itp.) i w liberalny sposób korzystać z fałszywych treści, aby przeprowadzać deterministyczne i ukierunkowane testy. Zmiany mające na celu rozszerzenie istniejącego kodu, który jest obecnie trudny do przetestowania, powinny wprowadzić odpowiednie ulepszenia w zakresie testowania.
Wszystkie zmiany powinny zawierać odpowiednie wyniki testów porównawczych oraz tytuł zmiany, aby zapewnić jasne zrozumienie korzyści.
W razie wątpliwości co do konwencji zawartych w kodzie zawsze warto sprawdzić istniejący kod i skorzystać z wzorców, które są już stosowane w OpenXLA.
Sprawdź proces
Wszystkie zgłoszenia, w tym te złożone przez uczestników projektu, muszą zostać sprawdzone. Do tego celu używamy żądań pull z GitHuba. Więcej informacji o korzystaniu z żądań pull znajdziesz w Centrum pomocy GitHuba.
Przed sprawdzeniem kod musi być zgodny ze wszystkimi standardami wymienionymi powyżej. Nie są one opcjonalne. Dlatego przed wysłaniem prośby o weryfikację ważne jest, aby osoba przesyłająca prośbę o sprawdzenie zgodności jej kodu miała pewność, że zmiany zostaną zatwierdzone w odpowiednim czasie.
Wszystkie testy muszą zostać zaliczone. Jeśli okaże się, że test nie działa, a problem nie jest związany z Twoim środowiskiem kompilacji ani z innymi zmianami, skontaktuj się z obsługą techniczną.
Staraj się unikać przeskakiwania zakresu podczas procesu sprawdzania. Obowiązek ponosi zarówno osoba zgłaszająca, jak i osoba sprawdzająca. Jeśli zmiana zacznie robić się zbyt duża, rozdziel ją na kilka mniejszych.
Zanim zmiana zostanie połączona, przejdzie testy wewnętrzne z wykorzystaniem kodu wewnętrznego dla Google i innych dostawców sprzętu. Może to wymagać dodatkowych kroków procesu weryfikacji, jeśli w testach wewnętrznych wystąpią błędy, których nie wychwytuje nasza publiczna infrastruktura CI. Pracownica Google, która sprawdza zmiany, powiadomi o wszelkich błędach testów wewnętrznych i opisze, co należy poprawić.
Najczęstsze pytania
„Ta zmiana infrastruktury nie ma związku z moim PR. Dlaczego warto to zrobić?”
Zespół XLA nie ma własnego zespołu ds. infrastruktury, więc to my musimy stworzyć biblioteki pomocnicze i uniknąć długu technicznego. Uważamy, że wprowadzanie zmian w XLA jest stałym elementem uczestnictwa w programie i wszyscy mają brać udział. Zwykle podczas pisania kodu budujemy infrastrukturę, która jest potrzebna.
Weryfikatorzy XLA mogą poprosić Cię o zbudowanie infrastruktury (lub w inny sposób wprowadzenie dużej zmiany w PR) wraz z napisaną przez Ciebie treścią. To żądanie może wydawać się niepotrzebne lub ortogonalne w stosunku do zmiany, którą próbujesz wprowadzić. Wynika to prawdopodobnie z niezgodności między Twoimi oczekiwaniami co do ilości infrastruktury, którą musisz utworzyć, a oczekiwaniami recenzenta.
Niezgodność oczekiwań jest w porządku. To normalne, gdy dopiero zaczynasz pracę nad projektem (a czasem zdarza się, że zdarza się to również w przypadku starych kapeluszy). Zapewne projekty, nad którymi pracujesz w przeszłości, mają różne oczekiwania. To też normalne. Nie oznacza to, że każdy z tych projektów ma niewłaściwe podejście – są po prostu inne. Zachęcamy do przyjmowania próśb o weryfikację (w infrastrukturze) razem z innymi komentarzami dotyczącymi opinii, aby dowiedzieć się, czego oczekujemy w przypadku tego projektu.
„Czy mogę odnieść się do Twojego komentarza w przyszłości?”
Najczęstsze pytania dotyczące wniosków o infrastrukturę (lub innych dużych) w relacjach PR dotyczy tego, czy zmiany muszą zostać wprowadzone w pierwotnej wiadomości lub czy można ją wprowadzić w przyszłości.
Ogólnie rzecz biorąc, XLA nie zezwala autorom PR na przesyłanie komentarzy do opinii z dodatkowym przekazem PR. Gdy weryfikator uzna, że coś wymaga określonego PR, zwykle oczekujemy, że autorzy odniesieją się do niego w tej publikacji, nawet jeśli zmiana jest duża. Standard ten obowiązuje zarówno na zewnątrz, jak i wewnętrznie w Google.
XLA stosuje takie podejście z kilku powodów.
Zaufanie: zdobycie zaufania weryfikatora to kluczowy element. W projekcie open source współtwórcy mogą samodzielnie się pojawiać lub znikać. Po zatwierdzeniu PR weryfikatorzy nie mogą w żaden sposób zagwarantować, że obiecane kontynuacje zostaną zrealizowane.
Wpływ na innych deweloperów: jeśli wysłano PR dotyczący określonej części XLA, istnieje duże prawdopodobieństwo, że inne osoby patrzą na tę samą część. Jeśli przyjmimy dług technologiczny w Twoim interesie, będzie to miało wpływ na wszystkich, którzy będą przeglądać ten plik, do czasu przesłania dodatkowych informacji.
Przepustowość recenzenta: odroczenie zmiany na żądanie wiąże się z wieloma kosztami nałożonymi na już przeciążonych weryfikatorów. Czekając na odpowiedź, weryfikatorzy prawdopodobnie zapominają, o czym była pierwsza ocena PR, co utrudnia kolejną weryfikację. Weryfikatorzy będą też musieli śledzić spodziewane działania, aby ustalić, czy faktycznie nastąpiły. Jeśli można wprowadzić zmianę w taki sposób, aby była naprawdę ortogonalna w stosunku do pierwotnego PR, aby mógł ją sprawdzić inny weryfikator, problem z przepustowością byłby mniejszy. Z naszego doświadczenia rzadko się to zdarza.