Open Source
Working with Maintainers
Patak - one of Vite's core maintainers - described his favorite PRs in an interview: «The ones where the contributor opened an issue first, we discussed direction, and then clean code arrived. I already knew I'd accept it.» That's how the system works.
- React has an RFC process - all major features (Hooks, Concurrent Mode) went through public discussion
- Rust RFC repository: every language change goes through months of public debate
- Vue 3 migration guide was co-created with contributors - maintainers specifically asked for help
- Node.js uses GitHub Projects for a transparent roadmap - anyone can see what's planned
Why PRs Get Rejected
A merged PR is a privilege, not a right. Maintainers are responsible for every line of code forever. Understanding why PRs get rejected is the key to getting your next one accepted.
**«Won't fix» is not an insult.** It's the maintainer's architectural decision. React declined to add built-in state management for years - and it was the right call for their vision. If a feature is truly needed - fork or a separate package.
You wrote 500 lines of code for a new feature and opened a PR - without a prior issue. The maintainer closed it: «This doesn't align with our roadmap». What should you have done differently?
Syncing with the Roadmap and Contribution Guide
**The contribution guide is your best friend.** Maintainers spent time writing it so you don't submit PRs they won't accept. Not reading it is like not reading documentation, then complaining things don't work.
**How to ping correctly:** After 2 weeks with no PR response, post one polite comment: «Gentle ping - is there anything I can do to help move this forward?». Don't write every 2 days. Don't ping in Discord and the issue simultaneously. One channel, once.
You want to add support for a new bundler in a large OSS project. What should you do FIRST?
Key Ideas
- PRs can be rejected for 7 reasons: vision mismatch, no prior issue, scope, tests, duplicate, maintainability, timing
- Issue first → discussion → approval → code. This saves everyone's time
- CONTRIBUTING.md, roadmap, open PRs - read these before your first contribution
- One polite ping after 2 weeks is standard. Not more frequently, not in multiple channels
- «Won't fix» is not an insult - it's an architectural decision
Related Topics
Understanding how to work with people - now moving on to publishing your own packages.
- Next Lesson — Logical continuation
Вопросы для размышления
- Pick any major OSS project you use. Find their CONTRIBUTING.md and roadmap. What did you learn that would change your approach to contributing?
- Why do maintainers sometimes close technically correct PRs without accepting them?