Comment by sitkack | Hacker News Reader

Comment by sitkack | Hacker News Reader

The pain of having a patch rejected is because of the asymmetry. No is _easy_, the submitter often put hours of work into understanding the codebase, the architecture the style of the code, figure out how to fix a bug or add a feature and then to have the response be, "No", feels like a pretty harsh rejection.

How we structure work on these projects needs to be rethought so that the majority of these don't happen. The attitude of code-or-gtfo is kinda broken with respect to how much work people put into a project with an uncertain outcome.

Maybe we should

  * submit an issue outlining new feature, or technique to fix bug
  * create a branch, reference that issue
  * update issue for a branch review, get greenlight
  * do possibly hours worth of work
  * submit PR that isn't outright rejected

Just communicating through pull requests seems very macho and wasteful to me.

> No is _easy_, the submitter often put hours of work into understanding the codebase [...]

And maintainers will put many, many more hours into maintaining it. The submitter only has to interact with us once. We have to interact with their code for a long time.

> How we structure work on these projects needs to be rethought [...]

Most projects work the way you described (including Docker). You open an issue (and/or send a mail to the mailing list) describing the problem and a proposal to fix it. We then discuss the design and once the maintainers all agree with the design (more or less) you move onto creating a PR.

Sometimes maintainers won't agree, and it'll take writing a PR to convince them that it will work (this does happen). But in most cases, the design is the important part (if it's a non-trivial change).

The only counter-example I can think of is the Linux kernel. But that's an extreme example and usually a dummy PR will be enough to convince them to discuss your idea.

The ZeroMQ founder, Pieter Hintjens, describes Optimistic Merging (OM) vs. Pessimistic Merging (PM) and how he supports merging sub-optimal patches just to encourage contributors: https://hintjens.gitbooks.io/social-architecture/content/cha...

"Submit an issue or post to the mailing list before starting a significant amount of feature work so that your work might be wasted" is a pretty common refrain in open source circles.

That said, like most tribal knowledge, it's the people who already do a lot of this kind of thing that know this kind of thing, and it's getting new people in that's the tough part.

Reply on news.ycombinator.com