161–170 of 243 posts
Hi, sorry but this is simply not something I'm interested in implementing. Further, please remember that GitHub maintainers do this for free, on their own time. Thanks! --- Anything more than that, block and move on. I've been on GH for 10 years or so and it's gotten really bad in the last few regarding pushy dickheads like this. You owe nothing to them, and if they can't behave within the OSS ecosystem then they're…
The best thing to do is to decide where your boundaries are, and then tell them. I was in your position many times. I was so frustrated to feel like the other person was entitled to my time. Then I had to fight my urges to tell them to fuck off, wasting even more time and energy in the process. Even if I replied, it wasn't helpful to anybody if I was being polite but passive-aggressive. Then I realized that it was a…
It works well for both managing people or doing customer support. It doesn't work for everyone. But as you note, it works in the vast majority of cases.
If you've read the Ask a Manager column, you'll recognize it as a core principle there. And if you've ever watched The Dog Whisperer, you quickly discover it works for dogs, too. (You just have to learn a few tricks for communicating with them.)
Earlier quoted context omitted.
And if 2. is "no" then let them know why not, but there is no need to "debate" it further either. Sometimes it's very important NOT to add features to a project. In fact I would argue that this is one of the strengths of OSS projects compared to "enterprise software".
Exactly. Each software has a shape that makes sense, in the eye of the creator. That shape might change but it has to stay internally consistent somehow. Unlike companies, we don't have to eternally grow the software to satisfy every customer and stay releavant. Projects come and go and this is a good thing.
One way to think about it: By making a FR, the user is providing free feedback. This feedback might be useful or not. Still, remember that the user has invested his/hers time to submit the explanation. Be nice if possible. Passionate users can be a bit extreme, so give them some slack. But if the user is not behaving politely, ignore him. The user has NO idea how expensive would it be to implement this FR. Even devel…
it would be interesting if github allowed the user to submit the feature request and commit x amount of dollars they are willing to pay to have it implemented. if the maintainer wants to entertain the offer, the two agree, and requestor submits the money to github to hold in escrow until the feature is implemented or the time has expired.
I think the model never took off enough to be attractive to github to implement on their end. But yea I think it would be cool and more popular if integrated directly in it.
> First of all, thank you for your support...$blah_blah_blah
> Unfortunately, I have to say no to some of your requests. $project is just a small side project of mine. My approach to its development will always be to prioritize my own use cases, while also catering to the community as much as I can. As you may have noticed, I have already implemented a bunch of new features and made quite a few changes based on community feedback. Decisions on whether to adopt a proposal from the community are made by evaluating the usefulness of the proposed feature or change for me and the wider community, and the feasibility of implementing it in my limited spare time.
> Now that I have explained my ways of doing side projects to you, let's go through your proposals:
To me it sounds you don't really know why it's not a good idea, but you are just annoyed by the phrasing of the feature request. So my advice would be: 1. Relax. 2. Take the emotion out of the equation. 3. Actually try to think about the feature request and why you will or will not implement it. 4. Calmly explain your reasoning based on rational grounds.
You don’t need to take time to rationally explain your thought process to every random dickhead on the internet.
"No" is a full sentence. You do not owe anyone an explanation beyond "I do not feel like working on this feature".
This can come off as rude if you’re trying to make a collaborative project. I’d link to a roadmap or be honest and say this doesn’t pique your interest.
You owe people politeness, but I don't think that you owe them a justification for not wanting to do things. If it's rude to say no, it's rude to ask.
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, no one cares.
Your project is yours, feel free to ignore everyone else.
I also highly recommend watching this talk by Pieter Hintjens a couple of times. It is brilliant https://m.youtube.com/watch?v=uzxcILudFWM
(I’m the creator of WTFUtil).