Správa žádostí o přijetí změn

Tento článek popisuje, jak spravujeme žádosti o přijetí změn v úložišti PowerShell-Docs. Tento článek je navržený tak, aby byl pracovní podporou pro členy PowerShell-Docs týmu. Publikuje se tady, aby poskytovala transparentnost procesů pro naše veřejné přispěvatele.

Osvědčené postupy

  • Osoba, která žádost o přijetí změn odesílá, by neměla sloučit žádost o přijetí změn bez kontroly partnerského vztahu.
  • Při odeslání žádosti o přijetí změn přiřaďte revidujícímu. Včasné zadání umožňuje revidujícím odpovědět dříve s redakčními poznámkami.
  • Použijte komentáře k popisu povahy změny nebo typu požadované kontroly. Nezapomeňte @mention revidovat. Pokud je například změna menší a nepotřebujete úplnou technickou revizi, vysvětlete ji v komentáři.

Kroky procesu žádosti o přijetí změn

  1. Zapisovač: Vytvoření žádosti o přijetí změn
    • Propojení všech problémů vyřešených žádostí o přijetí změn
    • Pokud chcete problém zavřít pomocí funkce automatického zaklárání GitHub
  2. Zapisovač: Přiřazení partnerského revidujících
  3. Revidujícím: kontroly pravopisu a komentáře (podle potřeby)
  4. Zapisovač: Začlenění zpětné vazby k recenzi
  5. Obojí: Kontrola vykreslování ve verzi Preview
  6. Obojí: Kontrola sestavy ověření – oprava upozornění a chyb
  7. Zapisovač: Přidání komentáře k odhlášení (včetně informací o Acrolinxu)
  8. Revidujícím: Označit recenzi "Schváleno"
  9. Správce úložiště: Sloučení žádostí o přijetí změn (viz níže uvedená kritéria)

Kontrolní seznam revidujících obsahu

Podrobnější seznam najdete v redakčním kontrolním seznamu .

  • Kontrola pravopisu pro gramatiku, styl, zřetězení, technická přesnost
  • Ujistěte se, že příklady stále platí pro cílovou verzi.
  • Kontrola vykreslování náhledu
  • Kontrola metadat – ms.date, odebrání ms.assetid, zajištění požadovaných polí
  • Ověření správnosti markdownu
    • Viz průvodce stylem pro pravidla formátování specifického pro obsah
  • Příklady reorganizujte následujícím způsobem:
    • Úvodní věty
    • Kód a výstup
    • Podrobné vysvětlení kódu (podle potřeby)
  • Kontrola přesnosti hypertextových odkazů
    • Nahrazení nebo odebrání odkazů TechNet nebo MSDN
    • Zajištění minimálního počtu přesměrování na cíl
    • Ujistěte se, že HTTPS
    • Správný typ odkazu
      • Odkazy na soubory pro místní soubory
      • Odkazy na adresu URL pro soubory mimo sadu docset
    • Odebrání národních prostředí z adres URL
    • Zjednodušení adres URL směřujících na docs.microsoft.com

Proces sloučení větví

Větev main je jediná větev, která je sloučena do live. Slučování z krátkodobých (pracovních) větví by mělo být zmáčkováno.

Sloučení z/do release-branch main Live
pracovní větev squash a slučování squash a slučování Nepovolené
release-branch Sloučit Nepovolené
main rebase Sloučit

Kontrolní seznam pro sloučení žádostí o přijetí změn

  • Kontrola obsahu je dokončená.
  • Správná cílová větev pro změnu
  • Žádné konflikty při slučování
  • Všechna ověření a předání kroku sestavení
    • Upozornění a návrhy by se měly opravit (viz Poznámky pro výjimky)
    • Žádné nefunkční odkazy
  • Sloučení podle tabulky

Poznámky

Následující upozornění můžete ignorovat:

Can't find service name for `<version>/<modulepath>/About/About.md`
Metadata with following name(s) are not allowed to be set in Yaml header, or as file level
metadata in docfx.json, or as global metadata in docfx.json: `locale`. They are generated by
Docs platform, so the values set in these 3 places will be ignored. Please remove them from all
3 places to resolve the warning.

Při sloučení žádosti o přijetí změn se změní head cílové větve. Všechny otevřené žádosti o přijetí změn založené na předchozí verzi HEAD jsou nyní zastaralé. Zastaralé žádosti o přijetí změn je možné sloučit pomocí práv správce k přepsání upozornění sloučení v GitHub. To je bezpečné udělat, pokud se dříve sloučené žádosti o přijetí změn nedotkly stejných souborů. Kliknutím na tlačítko Aktualizovat větev je ale nejbezpečnější možnost. Možná máte nevyřešené konflikty, které je potřeba opravit.

Publikování do živého provozu

Pravidelně se změny kumulované ve main větvi musí publikovat na živém webu.

  • Větev main se sloučí do live každého dne v týdnu v 3:00 PST.
  • main Větev by se měla sloučit po live jakékoli významné změně.
    • Změny v 50 nebo více souborech
    • Po sloučení větve vydané verze
    • Změny konfigurace úložiště nebo sady docset (docfx.json, konfigurace OPS, skripty sestavení atd.)
    • Změny souboru přesměrování
    • Změny obsahu
    • Po sloučení větve "project" (obsah reorg, hromadná aktualizace atd.)