4 ms·

I've not found a good heuristic for saying "no". Most issues are valid issues. I can see the benefits, they might even benefit future me. The hardest part for

I've not found a good heuristic for saying "no". Most issues are valid issues. I can see the benefits, they might even benefit future me. The hardest part for me is actually saying no, because it's never that black/white. I might work on it later because I want to help. I might stumble into a use case where I now need this feature and then do it. Someone might make a PR. But each "open ended issue" is still bandwidth, brain capacity, effort.

ChrisMarshallNY 5y ago
I've learned the skill. I had to. However, you are correct about that "using bandwidth" thing. If we publish something, then I think it behooves us to make it clear what users/adopters of our work can expect from us. I tend to use the MIT license ("You can do what you want, but don't come crying to me."). I also make every effort to make the project as understandable and well-documented as possible. I appreciate feedback, and apply it, if I deem it fitting. I have only had one project "go viral," so to speak. It's a fairly big deal, nowadays. It was taken over by a new team, and they had very little trouble getting up to speed on it, because of the quality of the code and documentation. Thousands of folks around the world, use it every day. It's become a fairly vital infrastructure component, for a certain demographic. The best thing I ever did, with that project, was get the hell away from it, as soon as I was confident the new team was good.