211–220 of 243 posts
Edit: maybe also "Poor Fit" for things that are between "someday" and "never."
"This feature is a bit out of scope"(if applicable). "Our team, aka me, has limited time for this project, and I just don't have the bandwidth. I can answer questions or possibly collaborate if you'd like to have a go at the code yourself though." "This is a personal/internal use project made available to the community as is, and adding features outside of what I need for my own company is not a priority. You're welc…
It's really important to communicate that you are distressed. Remember, it's quite likely they think they are not causing any distress, and probably would prefer to know than cause any additional harm. Banning them accomplishes this. It also has the additional benefit that if the person is not being conscientious, they no longer can annoy you.
I tag all new issues that come as “Feature Request”, “Bug”, etc. and then as far as I’m concerned, unless I’m interested in the issue, my work is done. Those then serve as an excellent roadmap for anyone who wants to contribute, but my projects are built for me and I work on the parts I want and need. I also use GH automation to auto-close issues after a year. If no one cares enough to implement the change in a year,…
Don't want the feature? Just say no, close the issue and move on. Especially if your project is MIT licensed, it's crystal clear in the license that very one thing: you don't owe anything to anyone :) You don't need to be nice, you don't need to explain. Life's too complicated to be upset about those things.
If the person keeps on insisting after that, you can block him from GitHub.
Earlier quoted context omitted.
If you would like to see an example of a polite and meaningful discussion I had with a maintainer declining my feature request, you could read this: https://github.com/nblumhardt/serilog-timings/issues/52 But I would not expect every requester to be polite and accept a NO...
Perfect example, thanks for sharing.