В прошлый раз я публиковал пост о сложностях, с которыми сталкиваются разработчики при попытках поучаствовать в опенсорс проектах. Не хотелось оставлять эту проблему без описания возможного решения, поэтому в этот раз я перевел для вас статью известного опенсорс активиста Кента Доддса. В статье автор делится несколькими любопытными лайфхаками — надеюсь, кому-то из читателей они помогут извлечь больше пользы/получить больше удовольствия от участия в опенсорс проектах.


После моего недавнего поста «Для тех, у кого это впервые», я получил массу писем и сообщений с вопросом: «В каком открытом проекте вы посоветуете поучаствовать?». В этом посте я попробую дать ответ на этот вопрос, а также сформулировать несколько рекомендаций относительно первых шагов в опенсорсе.

В наиболее общем виде ответ звучит так:

Наилучший вклад вы сможете внести в разработку того ПО, которым пользуетесь регулярно.

Лично мне больше всего удовлетворения приносит работа над проектами, которые важны для меня и моих знакомых. Второй ключ к успеху – работа на постоянной основе. Регулярная работа над проектом потребует понимания особенностей использования ПО и тех проблем, для решения которых оно было создано — знакомство с софтом с позиции пользователя в этом очень помогает.

Какие открытые библиотеки, фреймворки или инструменты вы применяете чаще всего? Может, вы работаете с Grunt, Gulp, Webpack или Browserify, и вам кажется, что они могли бы быть улучшены или задокументированы точнее. Или, вероятно, вы применяете библиотеку React или модуль Angular – их тоже можно немного отполировать. Вы наверняка используете какое-либо опенсорс ПО — и его улучшение может вам в чем-то помочь.

Первые шаги

Как только вы определились с проектом, в котором будете участвовать, возникает второй вопрос: «А с какой стороны за него браться»? У многих проектов есть файл CONTRIBUTING. Заглянув в него, вы обнаружите инструкции по участию в проекте. Если отдельного файла нет, то соответствующие инструкции могут быть в README (обычно расположен на домашней странице проекта). А если нет ни того ни другого, то можно отправить пулл реквест на добавление хотя бы скелетного файла CONTRIBUTING.md, чтобы начать переговоры о добавлении полноценных инструкций.

Познакомьтесь с проектом ближе. Чтение документации это хорошо, но мне больше нравится узнавать проект по коду. Мой любимый способ – влезть в обращения к функциям через дебаггер. К примеру, что случиться, если обратиться angular.module?

Посмотрев код, вы поймёте многое о принципах работы библиотеки или фреймворка. То же самое вы можете делать и с локальными инструментами, используя ваш любимый отладчик узлов (или просто добавив console.logs). Не переживайте, если с ходу что-то останется непонятным. Не сдавайтесь — вам это под силу!

После того, как вы узнали стандарты и процессуальные особенности участия в проекте и познакомились с принципами его работы, настаёт пора определить необходимые проекту изменения. Рекомендую взглянуть на существующие проблемы и прокомментировать те, которые покажутся интересными. Пообщавшись с кураторами, вы сможете найти оптимальное решения — и после этого сформировать пулл реквест.

Если у вас есть собственные соображения об исправлении бага или фичи, которую вам хотелось бы претворить в жизнь, я настоятельно рекомендую сначала обсудить её с куратором(ами) на GitHub issue. Может они скажут, что она лежит вне сферы интересов проекта или уже находится в разработке, а может, подскажут, какого рода изменения они хотели бы видеть в программном коде. Вы потратите гораздо меньше времени, убедившись, что ваш пулл реквест будет принят, прежде чем браться за его оформление (точно также прежде чем сделать предложение своей жене, я сначала сделал все для того, чтобы ответ был “да”)

Ваш первый пулл реквест

Для первого пулл реквеста просто найдите любой проект с подходящим багом/фичей и попробуйте предложить свои доработки. Дайте кураторам знать, что вы новичок и не имеете ничего против их советов. Если они слишком заняты, то лучше поищите другой проект. Первая доработка опенсорс кода – это всегда непросто, поэтому вам может потребоваться помощь и ценные указания более опытных участников. На этом этапе сам привнесенный код не так важен, важно научиться работать в опенсорс проекте. Поэтому ищите проект или человека, у которых хватит времени и терпения, чтобы направить вас на путь истинный.

Также вам может быть интересна серия постов о том, как участвовать в опенсорс проектах на GitHub: https://blog.kentcdodds.com/introducing-how-to-contribute-to-open-source-be67917eb704.

Дополнительные материалы

Загляните на GitHub’s issues в поисках тикетов, отмеченных first-timers-only, good for beginners, good first bug (или good-first-bug), или help wanted. Есть и другие ресурсы для поиска простых путей участия в проектах:

• twitter.com/yourfirstpr
• twitter.com/first_tmrs_only
• 24pullrequests.com
• up-for-grabs.net/#
• github.com/MunGell/awesome-for-beginners

Моим первым пулл реквестом стал запрос на исправление опечатки в комментарии. Он был очень маленьким и относился к проекту, которым я почти не пользовался (обнаружил опечатку, шастая по коду в дебаггере). Это был хороший первый вклад, хоть он и не особо повлиял на проект, а я не особо стремился продолжать участие в нём. Я перешагнул пропасть между отсутствием и наличием первого вклада, и это главное.

Заключение

Мне очень нравится участвовать в опенсорс проектах, и я всячески советую испытать на себе этот опыт. Да, начать непросто, но после того как вы сделаете первый шаг все последующие будут даваться значительно легче. Конечно, не всегда всё идёт как по маслу. У опенсорс сообщества есть свои причуды. Не обращайте на них внимания, просто продолжайте работать. Всё обязательно получится! Удачи!

Пара слов от переводчика:

Хотел бы посоветовать ещё одну полезную статью Кента "Introducing: How to Contribute to Open Source". В ней упоминается его небольшой курс "How to Contribute to an Open Source Project on GitHub".