6 ms·

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

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.

d99kris 4y ago
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.
the_gipsy 4y ago
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".
- zimbatm 4y ago
  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.
  - the_gipsy 4y ago
    Sometimes projects "go" earlier precisely because they keep adding shit. Others are eternal because they keep a very narrow scope with high quality.
- Freak_NL 4y ago
  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.
  - tut-urut-utut 4y ago
    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“.
    - Brian_K_White 4y ago
      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.
    - atoav 4y ago
      > 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.
      - Freak_NL 4y ago
        > 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”.
- deleted 4y ago
  [deleted]
sandreas 4y ago
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 https://github.com/nblumhardt/serilog-timings/issues/52 But I would not expect every requester to be polite and accept a NO...
- dt3ft 4y ago
  Perfect example, thanks for sharing.
  - sandreas 4y ago
    You're welcome :-)
- soneil 4y ago
  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.
  - sandreas 4y ago
    Absolutely... I tend to first be polite, and then after some conversation do just nothing in this case... don't feed the troll
- nonameking2026 4y ago
  It would be a really cool feature :)
  - sandreas 4y ago
    Thanks. Hehe, yes indeed. But you can't always get what you want...
Kye 4y ago
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.
jhauris 4y ago
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-vs-guessers/340891/ https://www.theatlantic.com/national/archive/2010/05/askers-...
- animal_spirits 4y ago
  Thanks for this link. I found this a really interesting way to think about social etiquette.
- austinjp 4y ago
  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.
klenwell 4y ago
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.)
perrygeo 4y ago
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.

d99kris 4y ago

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.

the_gipsy 4y ago

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

zimbatm 4y ago
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.
- the_gipsy 4y ago
  Sometimes projects "go" earlier precisely because they keep adding shit. Others are eternal because they keep a very narrow scope with high quality.
Freak_NL 4y ago
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.
- tut-urut-utut 4y ago
  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“.
  - Brian_K_White 4y ago
    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.
  - atoav 4y ago
    > 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.
    - Freak_NL 4y ago
      > 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”.
deleted 4y ago
[deleted]

sandreas 4y ago

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 https://github.com/nblumhardt/serilog-timings/issues/52 But I would not expect every requester to be polite and accept a NO...

dt3ft 4y ago
Perfect example, thanks for sharing.
- sandreas 4y ago
  You're welcome :-)
soneil 4y ago
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.
- sandreas 4y ago
  Absolutely... I tend to first be polite, and then after some conversation do just nothing in this case... don't feed the troll
nonameking2026 4y ago
It would be a really cool feature :)
- sandreas 4y ago
  Thanks. Hehe, yes indeed. But you can't always get what you want...

Kye 4y ago

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.

jhauris 4y ago

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-vs-guessers/340891/ https://www.theatlantic.com/national/archive/2010/05/askers-...

animal_spirits 4y ago
Thanks for this link. I found this a really interesting way to think about social etiquette.
austinjp 4y ago
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.

klenwell 4y ago

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

perrygeo 4y ago

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.