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

This is sensible advice. But I'd add an "R" as a separate and important item: report it. In your report, provide a clear explanation of why you think this is a bug, perhaps speculate on ways to fix it, and perhaps volunteer to help, in a way decided upon by the author.

"Cold-call" patches and pull requests can be quite disruptive to an author who might be busy with other parts of the code, or (quite likely) with this part. They may be fine for trivial bugs with simple solutions, because the author can then tell at a glance whether they are going to cause problematic ripple effects.

But for more trickier bugs with complex solutions, stitching in a patch/PR can be quite a hassle for the author. This is especially so if the new code is formatted differently than the old code, or uses a different "style" with respect to variable naming, etc.

Start by reporting the bug clearly and respectfully. Let the author know, if you see the solution. Perhaps they will ask for a patch or PR. Or perhaps they will say they need a few days to look at it. Either way, start with a conversation.



Also, if you're putting a lot of work into a pull request and it's important to you that it get merged, knowing whether you don't have a good chance of success, in advance, is going to save you and the maintainer potential sadness about your wasted effort.


That’s what the article already says is the first option - ‘Raise the issue in the bug/request tracker of choice.’




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

Search: