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

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.