The etiquette of saying no in open source

Open source runs on volunteers saying no well. As a contributor, I've had PRs declined. As a maintainer of my own small projects, I've declined others. Both sides of that exchange have etiquette, and both took me practice.

Receiving a no

The declined PR isn't a rejection of you — it's a decision about the project. The worst responses: arguing, resubmitting unchanged, or vanishing bitterly. The best: read the reason, ask one clarifying question if it's unclear, and either adapt or move on. Maintainers remember contributors who take direction gracefully. That memory is worth more than any single merged patch.

Giving a no (even to a small project of your own)

• fast is kind. A clear decline today beats a maybe for three months
• reason, specifically. "This duplicates the utility in utils/date.ts" is actionable. "Not a priority" is fog
• point at the door, not just the wall. When possible: what would make this acceptable? Sometimes the answer is a fork, and that's a legitimate outcome to name
• thank the work. A declined PR still cost someone an evening. Acknowledge the effort separately from the decision

The deeper point

Every polite no protects the project's focus, and focus is what makes open projects worth contributing to. Etiquette isn't softness — it's the maintenance of a system where strangers can collaborate without burning each other out.