Seen from the other side

I really agree with many of James' observations and points. Sometimes you're yourself on the side of the one having to accept changes that you don't like much, and you know by being used to that, that your comments might give you a label of PA or manipulator. This often happens when you disagree with something for various reasons but try to to hurt the submitter, so you keep your dissatisfaction for you and take the patch, but the problem is that it creates a precedent, with something imperfect that serves as an example of how to properly contribute. It can be small issues like coding style etc for example, or an approach that you're not certain how it will evolve over the long term.

What I found in this case is to address yourself the small unimportant stuff (e.g. fix typos or indent), mentioning it when taking the change and presenting it as something normal, so that the person is not surprised to see their contribution modified, and if there's nothing to fix but you're not much happy with the change, but have no technical argument against it (often we're driven by feeling itself driven by experience), just openly mention it: "I sense something might go wrong by proceeding like this, but I can't tell what; since I have no technical argument, let's merge it, and if later we figure it really causes a problem, we can revert it". It generally makes the contributor more careful in the future about the goals of the project, and if the suspected problem finally happens and something needs to be changed, the person doesn't perceive it as something bad since it was already envisioned. Usually that makes that contributor feel trusted and come back with more contributions. And even the problems you envisioned are often related to a slight change of direction that was clashing with your approach, but the contributor can continue that change and finally replace an older approach with something much better in the end.

This is a good example of long-term win/win driven by trust. It's difficult though because as a project leader you're also the one responsible for the project not to steer in directions that don't match the community's expectations, but by making public statements like this, you bring the community with you, or the community will contest your decision and you can roll it back if there are good reasons.