Open Source
Работа с мейнтейнерами
Patak - один из главных maintainers Vite. Он получает десятки PR в неделю. В интервью он рассказал: «Самые приятные PR - те где contributor сначала открывал issue, мы обсуждали direction, а потом приходил готовый код. Я уже знал что принять». Вот как работает система.
- React имеет RFC процесс - все major фичи (Hooks, Concurrent Mode) прошли через public discussion
- Rust RFC репозиторий: каждое языковое изменение проходит публичное обсуждение месяцами
- Vue 3 migration guide создан на основе feedback от contributors - maintainers попросили помочь
- Node.js использует GitHub Projects для прозрачного roadmap - можно видеть что планируется
Почему PR не принимают
Принятый PR - не право, а привилегия. Maintainers несут ответственность за каждую строчку кода навсегда. Понимание причин отказа - ключ к тому чтобы следующий PR был принят.
**«Won't fix» - не обида.** Это архитектурное решение maintainer'а. React годами отказывался добавлять built-in state management - и это правильное решение для их видения. Если функция действительно нужна - fork или отдельный пакет.
Вы написали 500 строк кода для новой фичи и открыли PR - без предварительного issue. Maintainer закрыл PR: «This doesn't align with our roadmap». Что нужно было сделать иначе?
Синхронизация с roadmap и contribution guide
**Contribution guide - ваш лучший друг.** Maintainers потратили время на его написание чтобы вы не делали PR которые они не примут. Не читать contribution guide - это как не читать документацию, а потом жаловаться что что-то не работает.
**Как правильно пинговать:** Через 2 недели после PR без ответа напишите один вежливый комментарий: «Gentle ping - is there anything I can do to help move this forward?». Не пишите каждые 2 дня. Не пингуйте в Discord и issue одновременно. Один канал, один раз.
Вы хотите добавить поддержку нового bundler в крупный OSS-проект. Что сделать ПЕРВЫМ?
Ключевые идеи
- PR могут не принять по 7 причинам: vision mismatch, нет предварительного issue, scope, тесты, дубликат, поддерживаемость, timing
- Сначала issue → обсуждение → approval → код. Это экономит время всех
- CONTRIBUTING.md, roadmap, открытые PRs - читать перед первым вкладом
- Один вежливый ping через 2 недели - стандарт. Не чаще, не по нескольким каналам
- «Won't fix» - не обида, это архитектурное решение
Связанные темы
Понимаем как работать с людьми - теперь переходим к публикации собственных пакетов.
- Следующий урок курса — Логическое продолжение
Вопросы для размышления
- Возьмите любой крупный OSS-проект который вы используете. Найдите их CONTRIBUTING.md и roadmap. Что вы узнали что изменило бы ваш подход к вкладу?
- Как вы думаете, почему maintainers иногда закрывают технически правильный PR без принятия?