4 ms·

Do you only object to the entitled tone of certain feature requests people have written, or do you see all issues created on your project without a correspondin

Do you only object to the entitled tone of certain feature requests people have written, or do you see all issues created on your project without a corresponding code change as entitled? If it’s the latter, you can disable Issues on your project, leaving only Pull Requests as an option. If you disable Issues, I suggest also briefly explaining why you did that in the README to ensure you don’t get do-nothing Pull Requests asking how you’d like bug reports submitted.

josephg 4y ago
The opposite - I prefer it when an issue is opened before the PR is written. That way I have a chance to respond / give feedback on the approach. I can respond with things like: "Oh, that problem? Yeah there's already code to work around it - here's what you need to do." Or: "You want that feature? I can see why thats valuable to you. I'm sorry but I'm never going to accept a PR from a stranger adding that. I don't need that feature for my workflow, and its complex, so the payoff isn't there for me to maintain the code. Fork my code, or implement that feature in an external library." I'd much rather turn down a feature request in an issue tracker than turn down work in a PR, after someone has done all the work already for something I'm not going to merge. That feels bad for everyone. If you write a good issue and take part in the discussion, that signals that you aren't taking my work for granted. Work with me to make a good repro case, and I'll work with you to fix the bug you're running in to.