Gerrit/Privilege policy/cs



Práva a povinnosti
Většina úložišť Wikimedia Gerrit je nakonfigurována tak, že když uživatel provede kontrolu kódu "+2", Jenkins po provedení testů změnu automaticky sloučí. Takže právo poskytnout recenzi kódem +2 je omezeno na osoby v určitých skupinách Gerrit. Obvykle existuje skupina Gerrit pojmenovaná po každém úložišti, která uděluje oprávnění k tomuto úložišti. Některé skupiny Gerrit také udělují oprávnění na více úložištích. Nejpozoruhodnější je, že skupina  uděluje privilegia na jádro MediaWiki a všechna rozšíření a vzhledy, stejně jako některá další úložiště související s MediaWiki.

Skupiny Gerrit mohou odvodit své členy ze skupin LDAP. Většina zaměstnanců WMF je ve skupině  v LDAP, což jim automaticky uděluje členství ve skupině.

Správci Gerrit mohou přidávat a odebírat členy ze skupin Gerrit.

Sloučení změny jádra MediaWiki nebo rozšíření nasazeného Wikimedia je velký problém. Změna bude automaticky nasazena do, virtualizovaného pracovního prostředí, jakmile bude začleněna do. Bude také automaticky vyzvednuta v příštím okně nasazení jádra MediaWiki (viz Deployments), pokud nebude vráceno před přerušením větve vydání.

Vaše sloučení může způsobit selhání Wikipedie nebo jiných webů. Mohlo by to vytvořit bezpečnostní chybu, která útočníkům umožní odstranit nebo poškodit data nebo získat přístup k soukromým informacím. A v běžnějším případě by to mohlo způsobit zvýšení o, pokud kód nemá testy, je špatně implementován nebo špatně socializován. Před použitím +2 byste si měli pozorně přečíst tento dokument a všechny příslušné zásady.

+2 je silným vyjádřením důvěry a důvěra je udržována dobrým úsudkem a pečlivým jednáním.

Při kontrole kódu, diskusích o designu a komentářích k chybám mají ti, kdo mají hodnocení +2, zvláštní odpovědnost vidět z pohledu ostatních.



Sloučení bez recenze
Sloučení kódu bez kontroly je špatné pro kvalitu kódu a špatné pro morálku. Smyslem práv +2 je oddělit vývoj a kontrolu kódu. Účelem sloučení změny v Gerrit je říct světu, že "Ano, zajistil jsem, že tato změna bude v souladu s konvencemi MediaWiki, osvědčenými technickými postupy a bude rozumná." (Srov. "Recenze kódu: Prostě to udělej" od Jeffa Atwooda.) Vložené komentáře lze použít k označení problémů s kódem, které by měly být vyřešeny před jeho sloučením.

Sloučení vlastního kódu bez souhlasu recenzenta může být důvodem k odebrání oprávnění.

To není nutně totéž jako dát +2 změně Gerrit, kterou vlastníte. Například:


 * Pokud změna obdrží od recenzenta +2, ale sestavení Jenkinse se nezdaří, vlastník jí možná bude muset dát +2, aby se úloha sestavení restartovala.
 * Obnovení lze obecně sloučit samo, pokud bylo odevzdání, které vrací, nedávné. Vracíte se k verzi, která byla v té době pravděpodobně zkontrolována.
 * Ve větvích nasazení a v úložišti Puppet jsou změny sloučeny osobou provádějící nasazení, která je často také autorem. V těchto případech je kontrola kódu obvykle indikována udělením změně +1.
 * Potvrzení v Gerritu může mít dva autory: Vlastníka a recenzenta, který nahraje dodatek. Majitel a recenzent obvykle recenzují práci toho druhého. Pokud byly všechny změny zkontrolovány a schváleny, může být odevzdání sloučeno.

Velmi málo změn je natolik triviálních, aby se samo sloučilo. Samoslučování je tolerováno v některých případech, jako jsou triviální změny dokumentace nebo projekty pouze s jedním správcem.

U rozšíření (a dalších projektů), která nejsou nasazeny do clusteru Wikimedie, je politika kontroly kódu na správci nebo autorovi rozšíření. Některá rozšíření mimo Wikimedii se řídí zásadou Wikimedie zakazující samoslučování, ale není to vyžadováno. Pokud jste jedinou osobou, která píše rozšíření a nemáte nikoho, kdo by vaši změnu zkontroloval, nebo pokud je rozšíření opuštěno, je přijatelné své změny sloučit sami.



Kontrola v rámci týmu a sdílené vlastnictví
Pokud pracujete jako součást týmu, recenze členy vašeho týmu jsou nejen povoleny, ale důrazně se doporučují. To, aby váš kód průběžně kontrolovali kolegové, je skvělý způsob, jak udržet tempo vývoje v chodu a zajistit, aby vaši recenzenti byli obeznámeni s tím, co děláte.

Když provádíte kontrolu v rámci týmu, buďte obzvláště citliví na slepá místa, kognitivních zkreslení a na potřebu získat podporu pro velké změny mimo skupinu lidí, se kterou spolupracujete. Většina projektů s otevřeným zdrojovým kódem, včetně MediaWiki, je plná opuštěných snah o vytvoření efektních nových abstraktních vrstev, systémů zobrazování, testovacích rámců atd. Zvažte dopad svých změn na ekosystém jako celek a zapojte se do konverzací prostřednictvím žádostí o vyjádření, wikitech-l, IRC a dalších míst. Sdílené vlastnictví kódu (ve větší či menší míře) pomáhá zajistit, že to, co děláte, bude mít dlouhodobou hodnotu.



Musí si přečíst pro recenzenty kódu

 * - a podstránky
 * - a související stránky
 * - mějte to na paměti při provádění změn schématu (které by měly být implementovány po tomto procesu)
 * - a související stránky
 * - mějte to na paměti při provádění změn schématu (které by měly být implementovány po tomto procesu)
 * - mějte to na paměti při provádění změn schématu (které by měly být implementovány po tomto procesu)



Žádost o oprávnění Gerrit
Poté pošlete e-mail na seznam e-mailů wikitech-l.

V obou případech by úloha Phabricator měla specifikovat:


 * Uživatelské jméno na Gerritu
 * Úložiště, ke kterým je vyžadován přístup
 * Zdůvodnění, včetně odkazů na napsané a zkontrolované opravy

Vývojáři, kteří komentují žádost o privilegia, by měli zvážit, zda žadatel přispěl vysoce kvalitními záplatami, dobře uplatnil práva +1 a prokázal způsobilost. Negativní komentáře by měly být psány s taktem, neměly by být přehnaně ostré.

Pokud existuje shoda důvěryhodných vývojářů na úloze Phabricator, může požadavek vyřešit kterýkoli z administrátorů Gerrit. Úkol musí zůstat otevřený alespoň týden, aby se k němu mohli vyjádřit zainteresovaní vývojáři. Pokud je žádost otevřena během cestování nebo prázdnin, měl by být poskytnut další čas.

Pokud v Phabricatoru nedojde ke shodě ohledně požadavku, může být za posouzení odkázán na TechCom.

Dříve dostali někteří správci rozšíření vlastnická práva na příslušný projekt v Gerritu, takže mohli přidávat nové členy skupiny, aniž by o to museli ve Phabricatoru žádat. Tento model by se neměl používat pro nová rozšíření. Správci Gerritu by neměli udělovat vlastnictví úložiště běžným vývojářům. Před prvním nasazením rozšíření do clusteru Wikimedie by měla být práva auditována a práva staršího vlastnictví by měla být snížena na přístup +2.



Zrychlený proces pro důvěryhodné organizace
Správci Gerritu mohou okamžitě reagovat na žádosti následujících důvěryhodných organizací o udělení a zrušení členství v jimi spravovaných skupinách, konkrétně:

Není nutné zadávat úlohu Phabricatoru nebo prokazovat shodu.

Tento postup je určen k tomu, aby těmto organizacím umožnilo rychle začlenit zaměstnance, o kterých se předpokládá, že jsou důvěryhodní na základě procesu náboru. Důvěryhodným organizacím také umožňuje udělit přístup dobrovolníkům, které tyto organizace dobře znají a důvěřují jim.

Zaměstnanci WMF, když jsou najati, mohou být přidáni do skupiny  v LDAP. Zaměstnanci Wikimedia Deutschland, když jsou najati, mohou být přidáni do skupiny  v LDAP.

TechCom nebo CTO po konzultaci s TechCom může nařídit správci Gerrit, aby přidal jakoukoli osobu do skupiny Gerrit.

Revocation
Revocation of Gerrit rights is permitted in the following circumstances:


 * In an emergency, such as a compromised account, Gerrit administrators may revoke access immediately, at their discretion. Reversal of emergency revocation may be done at the administrator's discretion if the emergency is judged to have passed. TechCom, or the CTO in consultation with TechCom, may review an emergency revocation and direct its reversal.
 * Revocation of privileges of a WMF employee may be directed by that employee's manager, in consultation with WMF Talent and Culture, as discussed in the Staff Handbook.
 * Revocation of privileges from any person may be directed by TechCom, or by the CTO in consultation with TechCom.

The reasons for revocation may include:


 * Merging bad code
 * Merging your own code without review
 * Failing to socialise high impact changes within the development community
 * Not following the guidelines above
 * Inappropriate behaviour, in particular, violating the Code of Conduct
 * Termination of employment or contract

It is WMF policy to revoke all privileges when staff members depart, even if those privileges were granted prior to the beginning of employment by virtue of volunteer work. Consistent application of this policy helps to protect the privacy of departing staff members: no fault is implied. If departed staff members wish to continue to contribute in a volunteer capacity, they may reapply for access by the usual process.

Requesting revocation
Emergency revocation should be requested by directly contacting a Gerrit administrator, for example using IRC. Revocation for reasons of competence or behaviour should generally be handled in private, following a defined escalation path. For more details, refer to the following table:

Amendments to this policy
Amendments to this policy must be approved by the CTO, in consultation with TechCom.

Definitions

 * CTO : The Chief Technology Officer of the Wikimedia Foundation.
 * TechCom: The Wikimedia Technical Committee. For TechCom to decide or direct something means that a meeting of the committee, by remote audio/video conference or in person, with the attendance of a quorum of at least half of TechCom's members, passes a resolution by simple majority or unanimous consent.