Přijetí žádosti o revizi pull requestu¶

Vaše žádost o stažení byla odeslána a prošla CI. Nyní je připravena k posouzení.

tl;dr – Proces přezkumu¶

Stručný popis procesu přezkoumání:

Počkejte na recenzi.
Reagujte na zpětnou vazbu.
Pokud jsou požadovány změny:
Proveďte požadované změny.
Odešlete všechny požadované změny.
Po provedení všech požadovaných změn požádejte o nové posouzení.
Opakujte část tři, dokud nebudou potřeba žádné další změny.
Počkejte, až bude váš pull request schválen a sloučen.

Gratulujeme! Právě jste přispěli do BeeWare!

Odeslal jsem svůj pull request, co dál?¶

Po odeslání žádosti o stažení budete muset počkat na posouzení vašeho příspěvku. Proces posouzení má dvě stránky: poskytnutí posouzení a přijetí posouzení.

Ověřte očekávání

Měli byste očekávat, že každý, kdo bude posuzovat vaše příspěvky, bude dodržovat tyto pokyny, včetně recenzí od členů hlavního týmu. Tyto pokyny byste měli dodržovat také při posuzování příspěvků od ostatních.

Pokud máte pocit, že váš recenzent tyto očekávání nesplňuje, a cítíte se pohodlně vznést tuto otázku sami v žádosti o stažení, můžete tak učinit. Pokud se na to necítíte, obraťte se na BeeWare Code of Conduct Response Team. Vaši zprávu prověříme a budeme ji dále řešit s vaším recenzentem. Následné kroky budou odrážet nahlášené jednání; menší prohřešek může vést k diskusi, zatímco závažnější porušení může mít vážnější následky.

Poskytnutí recenze¶

Každý může poskytnout recenzi na jakýkoli pull request. Tyto pokyny popisují naše očekávání ohledně recenze, bez ohledu na to, zda je poskytuje člen hlavního týmu nebo člen komunity.

Konečné hodnocení vždy provede člen hlavního týmu, ale hodnocení členů komunity může být užitečným způsobem, jak celý proces zefektivnit – v ideálním případě by hodnocení hlavního týmu bylo pouze formalitou poté, co komunitní hodnocení identifikovalo všechny hlavní problémy.

Přijetí recenze¶

Přijetí recenze zahrnuje tři základní kroky:

Počáteční zpětná vazba a otázky.
Žádosti o změnu.
Schválení a sloučení.

Každý krok je podrobně popsán níže. Pokud budete mít během procesu jakékoli dotazy, neváhejte se zeptat! Rádi vám pomůžeme.

Časový harmonogram a první zpětná vazba¶

Hlavní tým se snaží zajistit, aby každá žádost o stažení byla zkontrolována do deseti pracovních dnů. V případě složitějších žádostí nebo pokud je žádost o stažení podána v době, kdy jsou někteří členové týmu na dovolené, může se tato lhůta prodloužit.

Obvykle zachováváme kontinuitu s recenzenty u každého požadavku na stažení – to znamená, že budete pravděpodobně spolupracovat se stejným recenzentem po celou dobu recenze. To znamená, že váš recenzent bude mít přehled o celém procesu a vy se budete moci naučit, co můžete očekávat, pokud jde o kadenci odpovědí a styl recenze. Pokud váš původní recenzent zjistí, že nemá potřebné odborné znalosti k recenzi vašich žádostí o stažení, nebo ví, že z nějakého důvodu nebude k dispozici, může odpovědnost za vaši žádost o stažení předat jinému členovi týmu.

Můžete očekávat, že na každou komunikaci odpovíme do deseti pracovních dnů. Reagování na zpětnou vazbu a dotazy je nezbytnou součástí procesu přezkumu. Před přechodem k dalšímu kroku v procesu očekáváme vaši odpověď.

Žádosti o změnu¶

Ve většině případů bude váš recenzent požadovat změny ve vaší žádosti o stažení. To nutně neznamená, že vaše práce není dobrá, je to prostě součást procesu.

Pokud počáteční kontrola odhalí značný počet problémů, nemusí být první kontrola komplexní. Místo toho se zaměří na poskytnutí obecných pokynů k práci, která je nutná k tomu, aby byl pull request připraven ke sloučení. Kontrolní proces může zahrnovat otázky k objasnění účelu a rozsahu provedené práce.

Proveďte požadované změny¶

Váš recenzent zveřejní komentáře k vaší žádosti o stažení. Tyto komentáře mohou být obecné, týkající se konkrétního souboru nebo konkrétního řádku či řádků kódu. Někdy budou obsahovat přímo navrhované změny, které můžete aplikovat na svou žádost o stažení prostřednictvím uživatelského rozhraní GitHub. Obvykle se bude jednat o otázky, žádosti o vysvětlení nebo pokyny k aktualizacím.

Označení konverzace jako vyřešené

Během diskuzní části procesu zpětné vazby byste nikdy neměli označit konverzaci zahájenou vaším recenzentem jako „vyřešenou“. Označení konverzace jako vyřešené je odpovědností recenzenta. Je na něm, aby určil, zda byl identifikovaný problém vyřešen.

Pokud revize odhalí systematický problém (např. nesrovnalost v názvech v kódu), recenzent nemusí zdůrazňovat každý výskyt tohoto problému. Místo toho může vybrat několik příkladů problému a naznačit, že by měly být opraveny i další případy. Pokud revize zdůrazní problém na jednom místě a vy si myslíte, že by se mohl vyskytovat i jinde, měli byste tento problém opravit všude, kde se vyskytuje. Pokud si nejste jisti, požádejte recenzenta o vysvětlení.

Odeslat všechny požadované změny¶

Jakmile provedete všechny požadované změny, můžete odeslat aktualizaci do svého pull requestu. Tím se spustí nový běh CI; jakmile potvrdíte, že CI stále prochází, zveřejněte komentář s žádostí o aktualizovanou revizi a hlavní tým se na váš pull request podívá znovu.

Tlačte, nenuťte ani nepřesazujte

Při aktualizaci žádosti o stažení během kontroly je důležité ponechat historii commitů beze změny. Nezáleží na tom, zda je seznam commitů dlouhý; při sloučení žádosti o stažení se všechny sloučí. Pokud během kontroly vynutíte push nebo rebase žádosti o stažení, můžete odstranit důležitý kontext, který recenzent potřebuje.

Znovu požádat o přezkoumání¶

Jakmile vyřešíte všechny požadované změny v dané revizi a CI opět projde, můžete požádat recenzenta o novou revizi. Pokud je problém obzvláště složitý a jeho řešení bude mít dopad na jinou věc, můžete požádat o revizi konkrétní části, kterou jste aktualizovali. Předpokládá se, že jakákoli žádost o revizi je žádostí o úplnou revizi. Pokud nejste připraveni na úplnou revizi, uveďte přesně, co požadujete.

Schválení a sloučení žádosti o stažení¶

Jakmile odpovíte na všechny požadavky na změnu, bude pull request schválen. Ve většině případů bude pull request po schválení okamžitě sloučen. V některých případech mohou nastat polehčující okolnosti, jako například závislost na jiném, dosud nesloučeném pull requestu, které povedou ke zpoždění. O tom vás budeme informovat v komentářích, abyste byli o situaci informováni.