About three years ago I decided I was going to start contributing to open source. I'd used open source software for years, benefited from it enormously, and wanted to give something back. I also thought it would be good for my resume — which, to be honest, was probably the bigger motivation at the time.
I found a popular Python testing library with a GitHub issue I thought I could fix. The fix involved adding a configuration option that several users had requested. I spent two weeks on it: reading the codebase, writing the implementation, adding tests, writing documentation. I was thorough. I was careful. I was proud of it.
The PR was closed after three days with a comment from the maintainer explaining that the project had a deliberate philosophy against adding configuration options and that the right approach was different from what I'd implemented.
What I Did Wrong
I read the open issue as an invitation and started building. I didn't do what you're supposed to do before any significant contribution: comment on the issue and ask if this approach would be welcome. That five-minute conversation would have saved two weeks of work and the disappointment of a rejection.
The maintainer wasn't being unfair. They'd clearly articulated the project's design philosophy in the README. I'd read the code but not thought carefully about whether my change aligned with how the project wanted to evolve.
What the Maintainer Taught Me
The maintainer, to their credit, wrote a genuinely thoughtful response explaining why the change didn't fit. They also pointed me toward a different issue — a documentation improvement — that would be a good first contribution. It was a smaller change, but it got merged, and I was in the contributor list.
The lesson: the best first contribution to any project is rarely the most technically interesting one. It's the one where the maintainer's response to your proposal is "yes, please."
The Process That Works
- Find an issue that interests you
- Comment: "I'd like to work on this. Here's my proposed approach: [brief description]. Does this align with the project's direction?"
- Wait for a maintainer response before writing code
- If they say yes, build it. If they redirect you, listen.
This process feels slower. It's actually faster because you don't build things that won't be merged. And it builds the relationship with maintainers that eventually makes larger contributions possible.
