Proposing changes

Open source is built on ideas. Someone has an idea, shares it, and others build on it. But how you present a change can decide whether people welcome it or push back. A change proposed as a command feels like an order. A change proposed as a suggestion feels like an invitation to collaborate.

When you want to change something in a project, remember that the maintainers care about the project and have reasons for their choices. Your job is to explain your idea clearly and to show that you are open to their perspective.

Start with the problem, not the solution

People understand a change better when you first explain why it matters. Describe the problem you see, and only then offer your idea. This gives everyone a shared starting point.

Bad: "Change the API to use camelCase."

Good: "The current naming style is inconsistent across the codebase, which makes it easy to make mistakes. What do you think about switching to camelCase everywhere?"

Frame it as a suggestion

Use language that invites discussion. Words like "maybe", "what do you think", and "one option could be" signal that you are open to feedback, not forcing your way.

Bad: "Fix this now."

Good: "What do you think about trying a different approach here? For example, we could refactor this function to make it easier to test."

Be ready to discuss

A proposal is the start of a conversation, not the end. The maintainers might disagree, or they might know something you do not. Stay curious. If your idea is rejected, that is not a personal failure — it is part of the process.

Good: "I see your point about keeping the old behavior for compatibility. Would it help if I prepared a version that keeps both options behind a flag?"

Ready-to-use phrases

"I was thinking we could improve this by ..."

"What do you think about ...?"

"One option could be to ..., but I'm open to other ideas."

"Would it make sense to ...?"

A simple rule

Present your idea as a contribution to a shared effort, not as a demand. Explain the problem, offer your solution, and stay open to other opinions. That is how good changes get accepted and how strong projects are built.