A situation that has arisen several times in open source projects goes like this:
- I notice a bug in our deployment, and figure out a quick hack patch. (For example, simply commenting out code that we don't actually need.)
- I spend a little bit of extra effort to figure out the real bug, come up with a patch, and submit it via a Git pull request, or similar.
- My pull request is rejected. Perhaps the patch was imperfect (eg, included lines it shouldn't have), perhaps it violated coding style, perhaps it had other ramifications. Or maybe I did something wrong in Git - the pull request should have been rebased or something. A maintainer provides feedback about how to improve the patch, and requests that I resubmit it.
At this point I'm confused about how far I should proceed. As far as I'm concerned, I don't have a problem: I fixed it back in step 1. I've reported the issue, I've even taken steps to fix it for others. But I don't feel that it's "my" pull request, so I don't feel that responsibility for improving the patch should come to me.
One particular situation that irks me is after discussion about the failings of my patch, we reach agreement on a mailing list about what the correct patch would be (ie, how it should behave, sometimes including every line of code spelt out). Then, it is still presumed to be my responsibility to actually generate and submit the patch.
Is there a standard etiquette in these situations? How are they resolved? Is my reaction unusual? How far are you expected to go to get your bug fix accepted?
(Note when I say "open source project", some of these are very small, but may not be hobbies - simply small software projects which are of use to several organisations, who commit developer resources to working on them. In case the obvious answer is "fix the patch and resubmit", understand that I have responsibilities to my employer to work on stuff that is of benefit to them. Spending time fixing a bug that doesn't affect us would be wrong...)