> Steps 5..41: have an angry and emotional discussion with the devs who refuse to accept your PR because broken binary compatibility / regression tests / coding style / your choice of variable names etc. Fix all these issues and resubmit the PR until it's accepted.
As a maintainer, I can completely see where you're coming from here and some of nits that I have against PRs probably seem quite trivial. However, if you have a fairly large project then as a maintainer the onus is on us to make sure that things don't break (and that the project remains manageable). Not to mention that the argument people use (that we should just make a follow-up commit that fixes the PR so it's actually acceptable) doesn't _really_ work if you're someone who has to do bisects often -- I'm not going to merge code that is clearly wrong in several places (unless the code is returning a "not implemented" error).
It's not a pride thing, as maintainers we have much less time than the contributors (there are fewer of us than there are of you) so we can't carry every PR that someone drops on our issue tracker.
Of course, for runC we have automated testing that verifies that things like golint and gofmt succeed (so we don't have to waste time going back-and-forth with contributors about it). Lots of smaller projects don't do this, which leads to nothing but annoyances for contributors.
Also, in general when reviewing a change I try to state whether or not the idea is sound. If I am commenting on your choice of variables or how you've structured your algorithm, that means that I like the idea (and is an implicit "I will merge this once you fix <these set of nits>"). Not all maintainers do this, but most learn to do this quite quickly.