7 вредных советов: как не надо контрибьютить в open source

Хочешь заявить о себе в мировом IT-сообществе, но ты начинающий программист или даже студент? Цель амбициозная и вполне достижимая, если контрибьютить в open source. Код такого ПО распространяют бесплатно, а предложить свой патч и внести свой вклад может каждый. Ещё open source разработчики общаются с единомышленниками со всего мира, прокачивают скилы и получают ценный опыт для старта карьеры.

Для успешной работы над открытым ПО одного желания недостаточно: патч должен быть полезным, правильно работать и, что важно, его должны заметить и принять. Своим опытом контрибьюта в open source поделился Егор Чиндяскин, инженер по тестированию компании Postgres Professional. В первый год работы, ещё студентом, он сообщил о важных багах в СУБД PostgreSQL и получил медаль сообщества — символический знак отличия за вклад в развитие проекта.

Итак, 7 вредных советов, как не нужно контрибьютить в open source. Спойлер — если делать наоборот, все получится.

Работать в одиночку

Помощь наставников составляет 90% успеха. Опытный специалист знает, где код «плохо лежит» и направит новичка в зону уязвимости, которую можно улучшить. Самостоятельно найти ошибку, исправление которой было бы востребовано, не так просто. Баги, лежащие на поверхности, в популярном open source-проекте уже исправлены, так что придется копнуть глубже. В компании с наставником работа над собственным патчем будет проходить быстрее. Коллеге можно лично задать вопрос, и даже если он не сможет помочь, то направит к другим экспертам.

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

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

Однако у них есть свой недостаток — заносчивость участников. В крупных форумах эта проблема давно решена за счет внутренних правил. Например, в сообществе PostgreSQL нет ситуаций, когда вместо ответа на вопрос над новичком начинают подшучивать — это запрещено регламентом общения — Code of Conduct.

Быть в стороне от сообщества

Участники open source-проекта часто работают над ним в формате хобби, поэтому не стоит ожидать, что патч примут быстро. Ревьюеров и коммитеров высокого уровня мало — это добровольцы, которые работают на энтузиазме. Скорость принятия патча зависит от того, насколько критичную проблему он решает: вероятность принятия у bug fix выше, у критичного bug fix ещё выше, у security fix приблизительно на таком же уровне.

Если проблема, которую решает патч, не критичная, придется подождать. В PostgreSQL ежедневно приходит очень много доработок: в рассылке около 1000 писем в день и в массиве сообщений легко затеряться. Поэтому быть в стороне от сообщества — значит совершать большую ошибку.

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

В год проходит 5 коммитфестов, и прикрепить патч на рассмотрение нужно успеть до начала каждого из них.

В обычной ситуации волонтер, который следит за патчами, может что-то пропустить или не понять, а на commit fest такого не произойдет. Каким бы не был патч, в конце феста на нем поставят отметку: отклонен (rejected), принят (committed) или перенесен на следующий месяц (moved to next CF). Его в любом случае посмотрят, и по итогам феста будет понятно, что делать дальше — улучшать или просто прекратить над ним работу.

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

Оставлять ревьюеров в догадках

Без внятного пояснения и описания у патча не остается шансов на выживание в потоке чужих доработок. В первую очередь заголовок и описание патча должны быть конкретными. Например, мой патч называется «добавить несколько проверок, чтобы избежать переполнения данных». Чётко и понятно.

Правильным названием все не ограничивается. Иногда важно привести тест-кейс — пример воспроизведения ошибки, которую патч исправляет. Возможно, для демонстрации найденной ошибки понадобится загрузить большие базы данных в дополнение к pull request, но такие случаи бывают редко. Вслепую исправлять проблему в сообществе не будут. Коммитеры должны убедиться, что ошибка есть.

Хороший тон — писать комментарии в коде с объяснением нюансов его работы.

Комментарии составляют до половины исходного кода. Они отвечают на вопрос «зачем» что-то добавлено в код. Не менее важно соблюдать code style — стандарт оформления кода проекта, для которого создается патч.

Переусердствовать на старте

Кажется, что лучше изучить всю доступную информацию о ПО, для которого вы создаете патч, чтобы принести пользу и улучшить его. Это не так. Изучить все на старте невозможно. Такой подход будет только тормозить развитие и стимулировать страх ошибки. Но определенный уровень знаний быть должен.

В случае с PostgreSQL понадобится сильная база: навыки работы и написания скриптов в терминале Linux, умение писать скрипты на Python, основные моменты языка SQL. Получается, нужно лавировать между перфекционизмом, который стопорит любые действия, и саморазвитием, изучением языков программирования и скриптов.

Недооценивать документацию

Документация даёт понимание, как проект работает, а в PostgreSQL (или других проектах, где ей уделяют должное внимание) содержит ответ почти на любой вопрос. При этом её можно не только изучать, но и писать самостоятельно, ревьюить и дорабатывать. Наличие документации не всегда обязательно, но часто она нужна для удобства других программистов, которым предстоит работать с вашим патчем. При необходимости те самые увлеченные энтузиасты улучшат то, что вы написали, например, если английский хромает. В уже созданных документах часто есть что довести до идеала.

Во-первых, тонкости перевода создают поле для неточностей. Только у слова «кластер» в районе постгреса есть как минимум три значения, несколько синонимов. И если в разных ошибках и разных местах документации кластер по-разному упоминается — это зона проблем. Сохранить консистентность при адаптации на другой язык — сложная задача. С приличным уровнем английского можно начать с патчей именно в документацию, разбираться с нюансами перевода, этим вы очень поможете сообществу.

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

Отправлять патч без теста

Перед отправкой патча нужно не только подготовить заголовок, описание и комментарии в коде. Большую роль играет поведение патча. Ваша доработка может исправлять одну проблему и добавлять другую или просто менять поведение ПО. Утрированный пример: команда делала insert, а теперь она делает update. К таким патчам относятся негативно, но, если на ваш взгляд, изменение поведения оправдано, по крайней мере, обозначьте в описании нюансы его работы.

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

Не верить в себя

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

Независимо от того, как давно и успешно вы работаете над open-source проектом, помните, что open source не столько про быстрый и персональный результат, сколько про плавный путь и работу на общее благо. Мы говорим, что это марафон, а не спринт. Если вы на старте, работайте не ради быстрой отдачи. Кейсы, когда уже за первые баг-репорты новичок получает медаль, не так уж редки. Однако и другой вариант развития событий тоже будет вполне нормальным.

Вместо заключения — напутственные слова

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