Google 致力于为黑人社区推动种族平等。查看具体举措
Ta strona została przetłumaczona przez Cloud Translation API.
Switch to English

Proces TensorFlow RFC

Każda nowa funkcja TensorFlow zaczyna istnieć jako prośba o komentarz (RFC).

Dokument RFC to dokument opisujący wymaganie i proponowane zmiany, które go rozwiązują. W szczególności RFC:

Celem żądania TensorFlow Request for Comments (RFC) jest zaangażowanie społeczności TensorFlow w programowanie poprzez uzyskiwanie opinii od interesariuszy i ekspertów oraz szerokie informowanie o zmianach w projekcie.

Jak przesłać RFC

  1. Przed przesłaniem RFC omów swoje cele ze współtwórcami projektu i opiekunami oraz uzyskaj wczesną informację zwrotną. Skorzystaj z listy mailingowej deweloperów dla danego projektu (developers@tensorflow.org lub listy dla odpowiedniego SIG).

  2. Przygotuj swoje RFC.

    • Postępuj zgodnie z szablonem RFC .
    • Nazwij swój plik RFC YYYYMMDD-descriptive-name.md , gdzie YYYYMMDD to data przesłania, a descriptive-name odnosi się do tytułu Twojego RFC. (Na przykład, jeśli twój dokument RFC ma tytuł Parallel Widgets API , możesz użyć nazwy pliku 20180531-parallel-widgets.md .
    • Jeśli masz obrazy lub inne pliki pomocnicze, utwórz katalog w postaci YYYYMMDD-descriptive-name w którym będą przechowywane te pliki.

    Po napisaniu projektu RFC, przed przesłaniem uzyskaj opinie od opiekunów i współpracowników.

    Pisanie kodu implementacji nie jest wymagane, ale może pomóc w projektowaniu dyskusji.

  3. Zwerbuj sponsora.

    • Sponsor musi być opiekunem projektu.
    • Zidentyfikuj sponsora w RFC, przed wysłaniem PR.

    Zamieścić RFC bez sponsora, ale jeśli w ciągu miesiąca od opublikowania PR nadal nie ma sponsora, zostanie ona zamknięta.

  4. Prześlij swój RFC jako żądanie ściągnięcia do tensorflow / community / rfcs .

    Dołącz tabelę nagłówków i zawartość sekcji Cel w komentarzu do żądania ściągnięcia, używając Markdown. Na przykład zobacz ten przykład RFC . Dołącz uchwyty GitHub współautorów, recenzentów i sponsorów.

    U góry PR określ, jak długi będzie okres komentowania. Powinno to zająć co najmniej dwa tygodnie od wysłania PR.

  5. Wyślij e-mail do listy mailingowej deweloperów z krótkim opisem, linkiem do PR i prośbą o sprawdzenie. Postępuj zgodnie z formatem poprzednich wysyłek, jak widać w tym przykładzie .

  6. Sponsor poprosi o spotkanie komitetu weryfikacyjnego, nie wcześniej niż dwa tygodnie po opublikowaniu RFC PR. Jeśli dyskusja jest ożywiona, poczekaj, aż się uspokoi, zanim przejdziesz do przeglądu. Celem spotkania przeglądowego jest rozwiązanie drobnych problemów; konsensus w głównych kwestiach powinien zostać osiągnięty wcześniej.

  7. Spotkanie może zatwierdzić RFC, odrzucić je lub wymagać zmian, zanim będzie można je ponownie rozważyć. Zatwierdzone dokumenty RFC zostaną scalone ze społecznością / rfcs , a odrzucone dokumenty RFC będą miały zamknięte żądania PR.

Uczestnicy RFC

W proces RFC zaangażowanych jest wiele osób:

  • Autor RFC - jeden lub więcej członków społeczności, którzy piszą RFC i są zobowiązani do promowania go w trakcie całego procesu

  • Sponsor RFC - opiekun, który sponsoruje RFC i poprowadzi go przez proces przeglądu RFC

  • komitet ds. przeglądu - grupa opiekunów, którzy są odpowiedzialni za rekomendowanie przyjęcia RFC

  • Każdy członek społeczności może pomóc, udzielając opinii na temat tego, czy specyfikacja RFC spełni ich potrzeby.

Sponsorzy RFC

Sponsor jest opiekunem projektu odpowiedzialnym za zapewnienie możliwie najlepszego wyniku procesu RFC. To zawiera:

  • Opowiadanie się za proponowanym projektem.
  • Prowadzenie RFC do przestrzegania istniejących konwencji projektowych i stylowych.
  • Kierowanie komitetem weryfikacyjnym do osiągnięcia produktywnego konsensusu.
  • Jeśli komisja weryfikacyjna zażąda zmian, upewnij się, że zostały one wprowadzone i poproś o późniejszą zgodę członków komisji.
  • Jeśli RFC przechodzi do implementacji:
    • Zapewnienie zgodności proponowanej realizacji z projektem.
    • Koordynuj działania z odpowiednimi stronami, aby skutecznie wprowadzić grunt.

Komitety przeglądowe RFC

Komisja rewizyjna decyduje na zasadzie konsensusu, czy zatwierdzić, odrzucić lub zażądać zmian. Odpowiadają za:

  • Zapewnienie uwzględnienia istotnych elementów opinii publicznej.
  • Dodawanie notatek ze spotkania jako komentarzy do PR.
  • Uzasadnienie swoich decyzji.

Skład komisji rewizyjnej może ulec zmianie w zależności od stylu zarządzania i przywództwa każdego projektu. W przypadku podstawowego TensorFlow komitet będzie składał się z osób uczestniczących w projekcie TensorFlow, którzy mają doświadczenie w danej dziedzinie.

Członkowie społeczności i proces RFC

Celem specyfikacji RFC jest zapewnienie, że społeczność jest dobrze reprezentowana i obsługiwana przez nowe zmiany w TensorFlow. Obowiązkiem członków społeczności jest udział w przeglądaniu specyfikacji RFC, jeśli są zainteresowani wynikiem.

Członkowie społeczności zainteresowani RFC powinni:

  • Przekaż opinię tak szybko, jak to możliwe, aby zapewnić odpowiednią ilość czasu na rozważenie.
  • Przeczytaj uważnie specyfikacje RFC przed przesłaniem opinii.
  • Bądź uprzejmy i konstruktywny .

Wdrażanie nowych funkcji

Po zatwierdzeniu RFC można rozpocząć wdrażanie.

Jeśli pracujesz nad nowym kodem, aby zaimplementować RFC:

  • Upewnij się, że rozumiesz funkcję i projekt zatwierdzony w specyfikacji RFC. Zadawaj pytania i omawiaj podejście przed rozpoczęciem pracy.
  • Nowe funkcje muszą obejmować nowe testy jednostkowe, które sprawdzają, czy funkcja działa zgodnie z oczekiwaniami. Warto napisać te testy przed napisaniem kodu.
  • Postępuj zgodnie z Przewodnikiem po stylach kodu TensorFlow
  • Dodaj lub zaktualizuj odpowiednią dokumentację API. Odwołaj się do RFC w nowej dokumentacji.
  • Postępuj zgodnie z innymi wytycznymi określonymi w pliku CONTRIBUTING.md w repozytorium projektu, w którym uczestniczysz.
  • Uruchom testy jednostkowe przed przesłaniem kodu.
  • Współpracuj ze sponsorem RFC, aby pomyślnie wylądować nowy kod.

Utrzymanie poprzeczki wysoko

Chociaż zachęcamy i świętujemy każdego współtwórcę, poprzeczka akceptacji RFC jest celowo utrzymywana wysoko. Nowa funkcja może zostać odrzucona lub wymagać znacznych zmian na którymkolwiek z tych etapów:

  • Wstępne rozmowy projektowe na odpowiedniej liście mailingowej.
  • Brak rekrutacji sponsora.
  • Krytyczne zastrzeżenia w fazie informacji zwrotnej.
  • Brak konsensusu podczas przeglądu projektu.
  • Obawy zgłaszane podczas wdrażania (na przykład: niemożność osiągnięcia wstecznej kompatybilności, obawy o utrzymanie).

Jeśli ten proces działa dobrze, oczekuje się, że specyfikacje RFC zawiodą na wcześniejszych, a nie późniejszych etapach. Zatwierdzony dokument RFC nie jest gwarancją zobowiązania do wdrożenia, a akceptacja proponowanej implementacji RFC nadal podlega zwykłemu procesowi przeglądu kodu.

Jeśli masz jakiekolwiek pytania dotyczące tego procesu, możesz je zadać na liście mailingowej programistów lub zgłosić problem w tensorflow / community .