Comment by zimbatm | Hacker News Reader

Comment by zimbatm | Hacker News Reader

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 huge misunderstanding. How can people know what my limits are if I don't tell them? We don't all share the same sensibilities and background. Instead of getting upset, it's possible to tell people and move on. 99% of the time people understand and respect that.

Since then, I adopt the following classification:

1. Is the feature interesting to me? Let them know

2. If not, would I accept a PR for it? Let them know, with also some criteria for inclusion. No half-baked attempts please.

That's it.

One surprising thing I discovered is that I wasn't entirely clear where my limits were. Going through that process over and over again helped me figure that out. And become better at communicating clearly.

This is great communication advice. Your original state sounds a lot like the "asker" vs. "guesser" cultural problem [1]. I've found putting a label on those two outlooks to be very helpful.

1: https://www.theatlantic.com/national/archive/2010/05/askers-...

Thanks for this link. I found this a really interesting way to think about social etiquette.

I'd add "teller" to that list, distinct from "asker". I certainly have friends and family who will tell me in no uncertain terms that we're joining them for a meal, or even that they are joining us for our holiday, etc. Brazen barely describes it. They're rare, fortunately, but they exist.

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...

That really is a great example, but it's very noticeable that you both went into it with the perfect attitude (and maintained an awareness that each had different needs & goals).

It's the "Veruca Salt" case that's much more difficult to solve for.

Absolutely...

I tend to first be polite, and then after some conversation do just nothing in this case... don't feed the troll

Perfect example, thanks for sharing.

You're welcome :-)

It would be a really cool feature :)

Thanks. Hehe, yes indeed. But you can't always get what you want...

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.

Sometimes projects "go" earlier precisely because they keep adding shit. Others are eternal because they keep a very narrow scope with high quality.

Along with the 'no' it may help to point out that they are free to fork the project and add the feature to their own fork, or hire someone to build it for them. That won't stop the most extreme class of complainers, but it'll shave of another few.

Why pointing out something that is a distinguishing feature of open source?

I don’t need your permission to fork off the license allow me to, but telling me that I’d like putting a comment like „btw, did you know that 2+2=4“.

This whole question in the first place is about people that showed that they don't know such things and so need to be told such things, by the nature of their demands.

> Why pointing out something that is a distinguishing feature of open source?

Because users exist who are:

- clever enough to use github and open an issue

- not clever enough to know this is a possibility

- care about their problem enough to complain, but not enough to do something about it

By basically telling users "if you really care, you could do $labori tensivething" often they realize that they do in fact not care enough. And if they do, you could still use the fruit of their labour if it really turns out good.

> By basically telling users "if you really care, you could do $laborintensivething" often they realize that they do in fact not care enough.

That's the trick. Instead of offering no way to get the feature they want (which means they'll try to convince you to do it anyway), you show that they can in fact get that feature — for a price probably beyond their reach, but that's not something you can remedy, so hopefully they'll leave it at “I can't do/afford that”.

You are a more advanced user. It’s obvious a lot of the users like the one in the OPs example are not. They don’t know the nuances of how things work. They may think things like people are being properly compensated in some way for open source code projects. They may not know about forking or it’s possible to hire someone to add the feature you need. Bounties etc.

Sometimes people get upset about their project being forked. Explicitly offering it as an option assuages any concerns the requester may have about that.

Because not everyone gets it.

Excellent advice. This is like the golden rule of dealing with people. Well, the other golden rule. The professional one, I guess you could call it. Be explicit, polite but firm.

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.)

In the same vein, it helps to have publicly-stated design goals and constraints on the project. Often the most frustrating feature requests go against the grain of the software's original intent or architecture. To the extent you can articulate that in your software's docs, you can avoid much the misunderstanding.

I see this often with feature requests for backwards incompatible changes, code that would increase the complexity or burden of maintenance, introduce inappropriate dependencies, break APIs, or hurt performance. Often the requester simply never considered these things, either due to inexperience or lack of attention to detail. It helps to have a pre-canned response that you can link quickly.

Responding with RTFM can feel passive-aggressive to some people. But the alternative - writing out a full response to every request - is stressful and time consuming. The subtle shift from "my personal boundaries" to "the project's boundaries" makes communication a bit less strained.

I think this is a good advice.

To add on, for some of my projects I explicitly list out-of-scope areas in the README to give users a better idea on where the project boundaries lies.

This is especially true because the closer you are to limits, the more a reasonable and politely written request can look like a demanding screed from an asshole. It's safer to assume good intentions than risk blowing up on some innocent person.

Reply on news.ycombinator.com