Как новичку поучаствовать в опенсорс разработке?

https://blog.kentcdodds.com/what-open-source-project-should-i-contribute-to-7d50ecfe1cb4
  • Перевод
В прошлый раз я публиковал пост о сложностях, с которыми сталкиваются разработчики при попытках поучаствовать в опенсорс проектах. Не хотелось оставлять эту проблему без описания возможного решения, поэтому в этот раз я перевел для вас статью известного опенсорс активиста Кента Доддса. В статье автор делится несколькими любопытными лайфхаками — надеюсь, кому-то из читателей они помогут извлечь больше пользы/получить больше удовольствия от участия в опенсорс проектах.


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

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

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

Какие открытые библиотеки, фреймворки или инструменты вы применяете чаще всего? Может, вы работаете с 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. Есть и другие ресурсы для поиска простых путей участия в проектах:


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

Заключение


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

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


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

Ну. И что?
Реклама
Комментарии 19
  • +2
    Зачем? Лучше новичку какой-то проект сделать, чтобы от и до прочувствовать стек, нежели пилить какую-то штуку непонятную допиливать. Например, сделать небольшой MVP-клон чужого проекта.
    • –1
      Если новичок уже нащупался стек, а свой проект (даже клон) не потянуть из-за отсутствия навыков построения архитектуры. А тут: «На других посмотреть, себя показать.»
      Да и делать что-то реально полезное приятнее, чем унылый TODO-лист в консоли.
      • 0
        Я не против основ. Но ведь каждому очевидно, что работа в команде для новичка резко поднимает кривую обучения. А подходящие неложные задачки/баги найдутся в любом проекте. И, опять же, навык чтения чужого кода здорово выпрямляет руки.
      • +2
        Если к вам приходит на работу джуниор, вы же не говорите ему «сначала запилишь свой проект». Работая в opensource-проекте новичок может быстро получить обратную связь и получить опыт правильного gif-flow. Я знаю многих преподавателей университетов, которые в качестве зачета предлагают править баги в крупных промышленных opensource-продуктах, и считают это хорошим началом практической разработки.
        • 0
          а расскажите как git-flow работает с пуллреквестами гитхаба?
          • 0
            В промышленных проектах по долгу висят баги которые сложно пофиксить. Если к вам приходит на работу джуниор, вы же не говорите ему «сначала пофикси тот баг, который мы два года исправить не можем».
            • 0
              По-моему вы передёргиваете, часто баги висят не потому что их не могут исправить, а потому что руки не доходят у разработчиков, особенно если баг не блокирующий. Для джуниора это очень хороший способ разобраться с внутренностями проекта, с орг. вопросами, с код-ревью. Это гораздо лучше, чем браться за новый проект.
        • 0
          Большинство проектов заинтересованы в комюнити. Можно найти проект с парой контрибуторов (или вообще одним) где майнтайнер будет посговорчивей.
          • 0
            Если контрибутор один, то резонный вопрос — а нужен ли этот проект кому-либо еще, кроме этого единственного контрибутора?
            • +9
              есть масса полезных проектов (как правило всякого рода библиотеки) где один контрибутор. Не говоря уже что большинство проектов начинает именно один контрибутор а не сразу целая команда
              • 0
                kmmbvnr бы вам рассказал что большинство проектов пилит единственный контрибутор либо команда из нескольких знакомых друг с другом человек
                • +1
                  о, привет, не узнал по нику — богатым будешь.

                  Кто действительно пилит проект можно легко увидеть на закладке Contributors. Вот например django-rest-framework — github.com/encode/django-rest-framework/graphs/contributors

                  Половина загрузок django, приходится на проекты с rest-framework. Что наблюдаем? Единственный автор проекта сделал на порядок (буквально) больше коммитов чем ближайщий контрибутор. Статистика по измененным строкам, тоже отличается на порядок. И это важнейший проект в экосистеме django.

                  В более мелких проектах распределение по статистике похожее, только там вклад контрибутров сокрашается пропорционально размеру проекта до мизерного.

                  Это просто сухая статистика. Подавлющее большинство open source проектов тащит автор или знакомые по работе/тусовке core team.

                  Но это не значит, что коммьюнити совсе бесполезно. Комьюнити находит ошибки, предлагает решение проблемы. Мотивирует, так или иначе автора. Просто надо понимать, если вы начинаете опен-сорс проект, то кодером на этом проекте будете вы.
                  • 0
                    Ну если говорить про Django-rest-Framework, то чувак устраивал сбор бабла под лозунгом, вы мне платите, я вам выкатываю новую версию с фиксом багов и фичами, которые вы простите. И ему забашляли. Т.е. фактически мужик сделал проект своей работой, вот и делает его.

                    Я если честно не люблю использовать в своей работе какие-то тулзы или open-sourse проекты, за которыми не стоит финансовая выгода. Т.е. например, ребята делают плагин для админки Django и продают лицензию под её коммерческое использование (весьма успешно) — это норм штука, и есть такой же плагин, от какого-то индуса, который непонятно как финансируется. Я возьму первую, ибо надежней.

                    У нас когда на работе предлагают в более менее критичекие микросервисы пихать плагины, которые имеют непонятных авторов и контрибьюторов с гулькин нос, у меня душа кровью обливается.
                • 0
                  Это лучше, чем когда проект нужен остальным, но не нужен контрибьютеру.
                  • 0
                    Эту проблему решает опенсорс и возможность форков «из коробки» на гитхабе/гитлабе/битбакете.
                  • 0

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

                    • 0
                      А какая разница? Новичку ведь опыт участия нужен, а не всенародная слава.
                    • +1
                      я один контрибутор, у меня есть небольшая библиотека для мониторинга, вроде как её качают, раз так 10-15 в неделю. Мне несколько раз даже исправления присылали, хотя я думаю, что там ещё куча ошибок.
                    • 0

                      Как это должно выглядеть со стороны мейнтейнера (англ): Линус Торвальдс на этот счёт

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое