S VersionPressem silně zvažujeme přechod z Bitbucketu + JIRY na GitHub + GH Issues, což je docela zajímavý střet světů. Mám k tomu pár postřehů a i by mě zajímal váš názor, zkušenosti nebo případné komentáře.

Proč přechod

VersionPress, nebo minimálně jeho části, budou v dohledné době komunitní projekt a nedá se svítit, vývojáři jsou dneska na GitHubu. Tím jdou v podstatě všechny ostatní argumenty stranou, čímž neříkám, že GitHub nemá další pro – např. je cloud-hostovaný, rozumně levný, s plným API apod. Ale komunita je to, co nás “nutí”.

Přejít z JIRY je radost, ne?

Nevím. JIRA má z mého pohledu jen dva nedostatky: je pomalá a je pomalá. Jinak je to jednoduchý systém, s kanban boardem, logickým uspořádáním, moc toho v základu nechybí ani nepřebývá, zkrátka o JIŘE tak trochu platí, že pokud jste si na ni udělali špatný názor před deseti lety, dneska byste se divili.

Spolu s Bitbucketem, který používáme na pull requesty a code reviews, je to harmonický celek, který nás celkem ničím (kromě pomalosti) neštve a funguje dobře.

GitHub

Příslibem a současně problém GitHubu je, že by měl zvládnout roli JIRY, Bitbucketu a možná i ještě něčeho dalšího (lidi to např. často berou jako support kanál, viz label “question” v GH Issues). To je obecně velká výzva a je celkem jasné, že ji GitHub může v plné šíři zvládnout jen těžko.

Mé postřehy jsou následující:

1) Issue tracker doplácí na klasické “jednoduché neznamená nutně dobře použitelné”. V podstatě jediným kategorizačním mechanismem jsou labely, což by i mohlo stačit, kdyby byly udělané dobře. Ale přejmenovat label znamená udělat si v trackeru bordel (labely nemají identitu, v historii ticketů zůstanou jen jako string odkazující se na stránku k ničemu), z toho plyne nutnost je dobře navrhnout už od začátku, ale jak to má člověk bez zkušeností udělat, že jo, apod. Tohle je zcela proti konceptu don’t make me think a znovu, stačilo by, aby labely byly udělané dobře, ve stylu polí v jiných issue trackerech. Ale nejsou.

Plus to kupu věcí neumí, například varovat uživatele, že vkládá issue, která už pravděpodobně existuje, nebo ukládat historii editů, nebo přikládat libovolné soubory (docela nově umějí vedle obrázků aspoň DOCX a PDF). Něco z toho jsou menší věci, ale některé podle mě docela zásadní.

2) Issues používají stejnou číselnou řadu jako pull requesty. To je obecně hrozně zajímavý koncept – ne ta čísla, ale že PRs jsou v podstatě issues. Není to tak dávno zpátky, co mi tohle dávalo velký smysl. U nás se totiž běžně stávalo, že se ticket založil v JIŘE, nějak se tam lehce podiskutovalo, ale jak se začal psát kód a otevřel se PR, tak se komunikace přesunula tam. Ale jen částečně – pořád ještě šly nějaké komentáře k issues. Takže to bylo zbytečně a otravně rozdvojené a říkal jsem si, jak by bylo fajn, kdyby celý issue tracker byl jeden PR za druhým. A asi si to řekli i v GitHubu.

Jenže to nefunguje. Přišli na to sami, když před časem zakázali konvertovat issues do pull requestů – přinášelo to víc zmatku než užitku. Chtě nechtě, issues a PRs jsou dvě různé věci, ač relativně úzce propojené, a mělo by to být v UI i v číselné řadě oddělené. Mimochodem, na JIŘE zpětně oceňuju, že projekt má svůj klíč a číslo issue vypadá např. VP-123. Jak vidím něco takového kdekoliv (ve wiki, v mailu, …), okamžitě vím, že se jedná o VersionPress issue. #123 mi bez kontextu neříká nic, a ani v rámci kontextu projektu nevím, jestli to je PR nebo ticket :) #cognitiveLoad

3) Pull requesty by měly být pýchou GitHubu, ale upřímně, Bitbucket je má zas tak nějak ošklivější, ale funkčnější. Tam založím PR, přidám své kolegy jako reviewery, oni mi buďto dají fajfku jako že vše OK, nebo napíšou komentář, a z jedné stránky přehledně vidím, jak jsou všechny PR na tom. Dead simple. Na GitHubu to jde nasimulovat palcema nahoru nebo kdovíjak všelijak, ale podobně jako u issues, tam, kde mě tool Atlassianu vede a po applovsku mi nedává moc šanci udělat chybu, na GitHubu musím být kreativní a po androidovsku si to tak nějak vykoumat. To je přísné hodnocení, co? Zvlášť když vizuálně GitHub vypadá tak jednoduchý a cool…

Nicméně…

Statisticky na GitHubu projektu prostě fungují v pohodě. Je tam Facebook, Microsoft, Automattic (WordPress company) a mnoho dalších. Půjde to i u nás, jen asi musíme rezignovat z “čistoty” současných postupů. Ono se to asi stejně stane, až nám do našeho “svatého” issue trackeru začnou lidi valit jednu duplicitu za druhou. Jak už to bývá, u issue #5 zamrzí, že je zabraná nějakým blbým pull requestem, ale u issue #2617 je to už úplně jedno.

Prosba – zkušenosti s OSS projekty

Na závěr bych vás moc rád požádal o jakékoliv tipy, které máte k provozování OSS projektů na GitHubu, hlavně z pohledu autora / maintainera. Pro nás to bude nová zkušenost, a pokud by se daly ušetřit nějaké starosti, určitě by to neuškodilo :) Díky a konec úvahy.