Сегодня поговорим про #OpenSource.
Один твит - один совет/наблюдение исходя из моего опыта. Поехали.
Кстати, будет классно, если вы тоже будете делиться своим опытом участия в Open Source.
Open Source это не только про публикацию своих библиотек. Более того, часто это даже не самая эффективная форма участия в Open Source.
Можно принести гораздо больше пользы другими способами.
Столкнулся с багом, нашел issue в репозитории библиотеки и лайкнул его? Ты великолепен!
Если докинешь полезную для воспроизведения инфу или workaround который нашел, будет ещё лучше.
Нашёл новый баг, и вместо того чтобы писать у себя в проекте костыль со словами "ох уж этот Google" пошёл и завёл issue? Ещё лучше!
Если никто не заведёт issue, велик шанс, что о проблеме ещё долго не узнают. В конце концов ты же заинтересован, чтобы баг устранили?
Есть время и хочешь исправить баг или добавить функционал самостоятельно?
Круто! Пожалуй это самый быстрый способ получить нужные изменения, если команда разработки библиотеки сейчас занята другими задачами.
Например, мы в red_mad_robot, как и многие, плевались от реализации диплинков в androidx.navigation. А потом взяли и поправили баги которые отстреливали нам ноги:
issuetracker.google.com/issues/1840728…
issuetracker.google.com/issues/1855271…
issuetracker.google.com/issues/1855271…
Кстати, оказалось, что эти фиксы кому-то сломали диплинки :( Прямо всё как в старом меме.
xkcd.com/1172/
Перед началом работы над Pull Request'ом, обязательно согласуй изменения с командой разработки. Например, через issue.
Нет ничего хуже чем потратить время, а в итоге получить закрытый PR с комментарием типа "this feature is out of the library scope".
Изучи contribution guide, если он есть. Если нет - смотри на историю коммитов и прошлые PRы. Старайся писать код "в стиле проекта".
Всё это поможет сократить процесс ревью.
Наберись терпения. Ревью может (не)проходить долго, а может быстро. Зависит от проекта, от загруженности команды разработки, от их приоритетов, от фазы лунного цикла.
Причём нет прямой зависимости от количества изменений в PRе.
Этому PRу с одной дополнительной extension-функцией уже 8 месяцев: github.com/gradle/gradle/…
А этот PR с новым функционалом на +500 строк влили за два месяца:
github.com/Kotlin/kotlinx…
Если делаешь фикс, обязательно сначала напиши тесты, которые покажут, что проблема есть.
Желательно запушить тест отдельно, до фикса, чтобы CI упал и автор библиотеки мог это увидеть не запуская тесты самостоятельно.
Это, конечно, при условии, что в проекте есть тесты.
Если PR можно разбить на несколько - разбивай.
Несколько небольших PRов влить проще чем один большой и даже если один из PRов отклонят, остальные ещё могут влить.
Такой подход, кстати, и в работе полезен.
Проверь код стат. анализаторами и линтерами, если они есть в проекте.
Хорошо если настроен CI и вы увидите, что линтеры падают, но его может и не быть.
А ещё в последнее время CI часто запускается только "с разрешения" мейнтейнера.
Ревью может быть долгим, но можно сильно его сократить, если быстро вносить правки и реагировать на комментарии.
При добавлении нового или изменении существующего функционала не забудь изменить документацию.
Внезапный опрос. Участвуешь в open source проектах?
🤔
53.4% Нет🤔
15.1% Завожу и лайкаю issue🤔
16.4% ... и отправляю PRы🤔
15.1% Сам пишу библиотеки
Осип Фаткуллин