"Proč jako správce několika open-source projektů zavírám pull requesty"

Why I close PRs (OSS project maintainer notes) | Jeff Geerling Výtah:

• I will not merge a PR if all tests aren't passing.
• I also will not merge PRs that have large amounts of new, untested functionality.
• I will not add something that increases my maintenance burden unless it's very compelling functionality or an obvious bugfix.
• I'm not going to include code for that in my projects because (a) I don't use it, so I can't vouch for it, and (b) it adds maintenance overhead—even if it's a 'simple' addition.
• Please make sure basic things like spacing, variable naming conventions, line endings, spaces instead of tabs, and the like follow the general style of the project
• I've had PRs where the entire project architecture or test architecture was swapped out. I will never merge something like this unless it's been thoroughly discussed (and approved) in an issue first.
• Anything more than ~50 lines of changes and my brain doesn't have the capacity to do a good code review in less than an hour.

Podle mě pochopitelné důvody. A na druhé straně v komentářích padla taky dobrá připomínka:

Please respond to my pull request. Even if you don't have time to review it, please comment saying you don't have time and that it will have to wait. I feel like most of my pull requests are just ignored and I don't know why.

Jaké máte zkušenosti s přispíváním do open-source projektů vy? Já zatím veskrze pozitivní, pokud jsem nepsal obecné přání ("Bylo by užitečné, kdyby ta knihovna podporovala i tuto obrovskou novou funkci"), ale upozornil na bug, nebo přímo poslal zdůvodněnou opravu (která dodržovala zvyklosti projektu), víceméně vše bylo vyřešeno. A pokud spravujete open-source projekt, jak se na příspěvky od ostatních díváte vy? Je to přínosné? Obtěžuje vás to?

Udělal jsem pár desítek PR do Apache projektů, mohu říct, že nejvíce práce dá právě diskuze a dodržení code style, je to obrovský problém pro jednorázové úpravy, ať už myšleny dobře. Líbí se mi jejich myšlenka povinného kurátora, který je současným core vývojářem a dodržení těhle věcí zajistí. Apache projekty mají vesměs vypnuté PR na githubu právě z těhle důvodů.Občasné PR do github projektů mi povětšinou prošly v pořádku, snažím se ale dodržovat code style v projektu, dělám co nejméně změn a vše dobře komentuji. Prakticky vždy nejdříve napíši autorovi, jestli o danou feature má zájem a jestli jí do projektu příjme, až poté dělám kód. Občas se mi stalo, že jsem si forknul projekt, udělal úpravy a pak se ozval původní autor a chtěl změny asimilovat.S výše uvedeným souhlasím, někdy ti vývojáří naprosto ignorují projekt a jedou si svoje, spamují PR naprostými nesmysly, které ještě nefungují. Za mě nemůže fungovat anonymní vývoj, kdy kdokoliv dává PR, projekt tím trpí a stává se moc těžkopádným, vývoj kódu se musí řídit. Kvalita PR je povětšinou velice slabá, doplňují do projektů kde co a zavádí obrovský bordel. Nikdy nesmí být z kódu poznat, že kód psalo více lidí, to je mantra, kterou dodržuji.Zažil jsem jeden django projekt, kam člověk potřeboval něco dodělat, tak vzal php a volal si tam přes exec php kód, poté se rozčiloval, proč mu změny nikdo nechce příjmout. Komunikace autorů na PR je slabá, ale chápu je, pro ně to je ztráta času a pokud jde např. o github, dost špatně se z něho dají zpravovát emaily, osobně mi jich chodí stovky denně a nemám šanci vše přečíst.