Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Prescient - I read this right after patching [1] jekyll (static site generator) and sending mojombo a pull request on github without any mailing list or other discussion.

For quick/simple patches, I find the pull-request approach to be way less hassle. As much as I value the open source process, I simply can't be bothered to join the mailing list, post, wait for a reply etc etc for every project I write a trivial patch for, especially if it's a project I'm not planning to hack on a lot. Life's too short.

At least this way, if the project authors want my patch, they can get it easily. Otherwise I'm happy for it to just sit in my fork.

Common sense is required - sending a pull-request out of the blue for a large or structural change is asking for trouble. For trivial patches it's very convenient.

[1] https://github.com/RJ/jekyll/commit/2f9d4f5be623f37ca79adf84...



Completely agree, for small projects, or small patches of big projects, pull requests are not that bad, but neither very good IMHO as there is always a lot of background missing.

But the kind of pull requests I receive are often fairly large. New commands implemented or other large changes.


And there's the thing: not all patches are the same.

It's not even so much the size of the patch, but rather how much it gets into the design, I think. If someone sends a largish bugfix patch that doesn't touch design then that seems ok to me. Even if you don't like the actual patch, you'll probably do your own similar (but correct) patch.

But sending even a smallish patch that messes with design would have been better with discussion first. Even small tweaks to architecture, API/ABI, UX, etc. need careful consideration.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: