ПЕРЕВОД: http://www.softwarequalityconnection.com/2012/03/14-ways-to-contribute-to-open-source-without-being-a-programming-genius-or-a-rock-star/
Множество людей хотели бы иметь отношение к открытому ПО, но не знают, как начать. Есть несколько путей для этого, даже если Вы не уверены в своих технических навыках.
Автор: Andy Lester | 11 марта 2012
Открытое программное обеспечение изменило не только компьютерный мир, и сейчас многие хотели бы принять участие в его создании. К несчастью, многих людей устрашает воображаемый барьер, который, как им кажется, надо пересечь, чтобы подключиться к проекту. Я (Andy Lester – прим. пер.) нередко слышу, как люди говорят, что с радостью что-нибудь сделали бы, но не могут.
Обычно они называют три причины:
- “Я не очень хороший программист”;
- “У меня нет времени, чтобы посвятить себя такой серьёзной задаче”;
- “Я не знаком с внутренней организацией проекта”.
Вот три основных принципа, если Вы хотите помочь:
- Проектам нужна помощь ото всех, независимо от их навыков и профессионализма;
- Самая маленькая помощь лучше, чем никакой;
- Проект, который Вы используете – лучший выбор для начала.
Самая вредная мысль среди тех, которые я встретил среди новичков в открытом программном обеспечении – это уверенность в том, что надо быть гением, чтобы писать программное обеспечение с исходным кодом. Это заблуждение. Конечно, в мире открытого программного обеспечения есть те, кто выглядят на фоне остальных рок-звёздами, и они действительно могут быть гениальными программистами. Тем не менее, большая часть нас, разработчиков, таковыми не является. Мы просто люди, которые что-то делают. Иногда мы делаем немного, иногда больше. В одних случаях это подразумевает непосредственно написание кода, а в других – что-то другое.
Что заставляет открытое ПО работать – это работа над ним, время потраченное на что-то для проекта. И большинство задач не требуют быть создателем Perl – Ларри Уоллом или создателем Rails – Давидом Ханссоном. Проектирование нового языка или фреймворка может потребовать вдохновения, но всё остальное – то, что делает такие проекты, как Perl и Rails успешными – это труд. Эта работа, возможно, не принесёт славы, но она необходима и Ваши усилия определённо будут замечены.
Прислушайтесь
В проекты с открытым исходным кодом вовлечены другие люди. Вы собираетесь войти в команду, а это означает понимание сообщества и того, как оно устроено. Навряд ли Вас примут серьёзно, если Вы просто придёте и скажете: “Эй, этот проект должен работать вот так”. Некоторые проекты могут приветствовать подобный подход, но если проект уже некоторое время существует и без Вашего участия, шансы на то, что Вас после подобного приветствия примут с распростёртыми объятиями, малы. Если же Вы некоторое время послушаете – Вы поймёте, что действительно надо этому проекту.
Подпишитесь на рассылку: Для многих проектов рассылка – это главный канал обсуждения процесса разработки проекта. На больших проектах может быть даже не одна рассылка. Например, у PostgreSQL не менее двенадцати пользовательских рассылок и шести рассылок для разработчиков. Я бы рекомендовал подписаться на основные рассылки для пользователей и разработчиков.
Читайте блоги: Блоги ключевых разработчиков проекта также часто дают информацию о том, что планируется включить в будущих версиях, и что ещё надо для этого сделать. Есть специальные сайты-”планеты”, которые собирают новости и записи из блогов, имеющих отношение к проекту. Если для проекта, с которым Вы хотели бы работать, есть “планета” (например, http://planet.gnome.org или http://planet.mysql.com) – начните здесь. Просто поищите в Google “planet <название проекта>”.
Подключитесь к каналу IRC: Многие проекты заводят собственные IRC-каналы, на которых разработчики и пользователи могут обсудить проблемы и процесс разработки. Проверьте сайт проекта, чтобы узнать, как к такому каналу подключиться.
Работа с заявками
Сердцем каждого проекта с открытым исходным кодом, конечно, является сам исходный код, но не думайте, что единственный способ внести в проект что-то своё – это писать [новый] код. Поддержка существующего кода, а также его инфраструктуры зачастую остаются забыты ради новых возможностей и решения насущных проблем. Обратите внимание на эту область, и Вы легко найдёте, с чего начать.
Большинство проектов держат открытые обществу баг-трекеры (bug tracker). Вы можете найти их адреса как на официальной странице проекта, так и в документации к проекту. Как правило, баг-трекинговая система является основным каналом коммуникации между пользователями и разработчиками. Поддержка её в актуальном состоянии – это замечательный способ оказать проекту помощь. Возможно, Вам придётся получить специальные права на работу с заявками в трекинговой системе, но их Вам с удовольствием дадут, если Вы предложите помочь с уходом за разбором заявок.
Диагностируйте проблемы: Зачастую заявки о проблемах (tickets) плохо оформлены и/или содержат неполную информацию. Вы можете попробовать оценить важность проблемы и идентифицировать настоящие условия её возникновения. Тем самым Вы поможете разработчикам быстрее решить проблему. Например, если пользователь оставил заявку с текстом: “Программа не работает, когда я делаю …” – изучите условия возникновения проблемы: воспроизводится ли она, можете ли Вы описать последовательность шагов к воспроизведению проблемы, можете ли Вы уточнить условия возникновения проблемы (в каких браузерах/на каких дистрибутивах она проявляется, а где всё работает).
Даже если Вы не знаете причину возникновения проблемы, Ваши усилия по сужению сферы поиска сделают задачу легче для того, кто будет ею заниматься. Просто добавьте всю новую информацию, которую Вы смогли обнаружить, в заявку.
Закрывайте решённые проблемы: Очень часто проблемы могут быть уже решены в коде, но ещё существовать в трекинговой системе. Чистка трекера от такого “хлама” может занять некоторое время, но будет весьма ценна для проекта.
Начните с заявок старше одного года и проверьте, существуют ли ещё эти проблемы. Также, Вы можете проверить логи релизных изменений (в проектах с открытым исходным кодом такие, как правило, есть) – возможно, там уже есть указание о решении проблемы, но до трекинговой системы это просто не дошло. В таком случае перед закрытием заявки пометьте в ней версию, в которой проблема была решена.
Если проблема среди решённых не упоминалась – попробуйте воспроизвести её на последней версии. В результате либо заявка будет помечена как актуальная и для последней версии (укажите номер), либо закрыта с указанием версии, в которой проблема уже не воспроизводится.
Работа с кодом
Опытные программисты могут помочь и в написании кода для любимого проекта. И для этого не надо быть гением.
Если Вы планируете вносить модификации в код – сначала разберитесь, как в проект принимается код от сторонних разработчиков. У каждого проекта свой рабочий процесс. Например, PostgreSQL подходит к этому процессу строго: Они принимают патчи, оправленные в рассылку разработчиков, где они проходят проверку основными разработчиками перед тем, как кто-нибудь перенесёт патч в основной код. С другой стороны, можно отметить проект Parrot, для котором сравнительно легко получить права на внесение комиттов прямо в основную ветку. Если же проект базируется на GitHub, рабочий процесс может основываться на возможности запроса внесения изменений в основную ветку средствами самого Git.
При внесении изменений в код, всегда сохраняйте стиль, принятый именно в этом проекте. Ваш код не должен выделяться среди остального. Возможно, Вам не нравится используемая идентация или практика размещения фигурных скобок, но вставка кода, не соответствующего принятым стандартам была бы грубым поступком. Как будто Вы говорите: “Мне не нравится ваш стиль, вам следует использовать мой”.
Протестируйте бета-релиз/релиз-кандидат: Любой кроссплатформенный код может содержать различные проблемы переносимости. По мере приближения к выпуску следующей версии, лидер проекта всегда надеется, что код будет протестирован разными людьми на как можно большем количестве платформ. Вы можете быть одним из этих людей и помочь убедиться, что на Вашей системе всё работает.
Как правило, нет необходимости скачивать исходные коды, собирать их и тестировать проект, но если Вы являетесь владельцем какой-то редкой платформы, ценность Вашего тестирования для проекта будет значительной.
Решайте проблемы: С решения проблем обычно и начинают новички на проекте. Это просто: Найдите проблему, которую Вам интересно было бы решить и попробуйте. Если принято, документируйте Ваше решение в коде.
Хорошей идеей будет добавить соответствующий тест на решённую проблему; некоторые проекты даже требуют добавлять тесты на решения с целью исключения возможности возврата проблемы в будущем. Сохраняйте заметки по архитектуре проекта, пока Вы в нём разбираетесь. Даже если у Вас не вышло решить проблему, распишите в заявке, в чём Вы уже разобрались – Ваши успехи помогут следующему не начинать с чистого листа.
Пишите тесты: Большинство проектов используют тесты для проверки кода, но сложно представить набор тестов, в который уже нельзя добавить новых. Используйте специальные пакеты, например gcov для C и Devel::Cover для Perl,чтобы определить области проекта, не покрытые тестами. Затем напишите тесты, чтобы закрыть эти области.
Отфильтруйте предупреждения компилятора: Сборочный процесс многих проектов, основанных на языке C, выводит на экран избыточные предупреждения во время компиляции. Ведь не все предупреждения являются симптомами наличия проблемы, но многие могут выглядеть как таковые.Слишком большое количество предупреждающих сообщений может привести к повторению известной присказки про мальчика, который часто кричал “Волк!”.
Проверьте, действительно ли в коде, для которого выводится предупреждение, может быть скрыта проблема. Если нет – просто внесите необходимые изменения, чтобы убрать ложные срабатывания. (Если не понимаете код в этом месте досконально, лучше оставьте как есть, чтобы не скрыть реальную проблему. – прим. пер.)
Пишите комментарии: Пока Вы разбираетесь в коде, некоторые места могут показаться Вам странными или не очевидными. Есть шанс, что раз Вам это место не было сразу понятно, других оно также может запутать. Напишите комментарий к этому месту и предоставьте патч сообществу.
Работа с документацией
Документация – это та часть проекта, которой обычно уделяется недостаточно внимания. Также проблемой документации может стать то, что она скорее будет написана с точки зрения тех, кто знаком с проектом, а не тех, кто только с ним знакомится. Если Вы когда-либо, читая документацию, ловили себя на мысли: “Тут пишут, как будто я уже должен знать, как этим пользоваться,” – Вы понимаете, о чём я. Зачастую свежий взгляд может обратить внимание на пробелы в документации, которых непосредственный разработчик и не заметит.
Пишите примеры: Чем больше примеров использования – тем лучше. Нет проекта, к которому существовало бы слишком много примеров. Независимо от того, что это: фреймворк для web-разработок, или библиотека, или приложение с пользовательским интерфейсом (как Gimp, например), или консольная утилита, хороший пример правильного использования может яснее и быстрее документации объяснить, как его надо использовать.
Для API или библиотеки напишите программу, которая будет их использовать. Вы можете даже извлечь для этого часть кода, который вы уже написали для работы с библиотекой, из своего проекта, лишь оставив необходимое. Для утилиты укажите примеры, как Вы используете её в своей повседневной жизни. Также Вы можете записать скринкаст, например, по установке приложения.
Сообщество
Открытые программы – это только отчасти об исходном коде этих программ. Работает ПО с открытым кодом благодаря сообществу. И Вы можете помочь в построении сообщества вокруг проекта.
Отвечайте на вопросы: Лучший способ помочь в построении сообщества – это помогать другим. Отвечая на вопросы, особенно тем, кто только начинает пользоваться проектом, Вы помогаете проекту расти и развиваться. Если Вы поможете новичку, даже если можете просто отправить читать документацию, возможно, в будущем проект получит нового активного участника. Все когда-то начинают с нуля, а проектам постоянно нужны новые люди для того, чтобы расти.
Напишите пост в блоге: Если у Вас есть технический блог, описывайте в нём Ваши решения с использованием проекта. Рассказывайте о проблемах, которые Вы встречаете, и какие решения помогли. Так Вы повысите узнаваемость проекта, а также оставите записи для всех, кто в будущем встретит подобную проблему и будет искать решение в глобальной сети (Дополнительный плюс от ведения блога – это то, что вы потом можете ссылаться на него при поиске работы, как показатель Вашего опыта).
Улучшите сайт проекта: Большинство программистов всё-таки не является прирождёнными дизайнерами, и редко можно встретить сайт проекта, которому не нужна помощь специалиста. Если у Вас есть навыки в дизайне, и Вы можете улучшить сайт – лицо проекта – то это будет время, потраченное с пользой. Возможно, проекту следовало бы отполировать внешний вид или спроектировать логотип. Подобные навыки были бы полезны сообществу. Я бы с удовольствием воспользовался помощью для улучшения дизайна сайтов моих проектов.
Ну и главное: обращайте внимание на то, что обсуждают пользователи проекта. Возможно, Вы сможете распознать, что надо от проекта в первую очередь. Как пример, приведу недавний случай: в рассылке разработчиков проекта Parrot было решено использовать GitHub в качестве трекера заявок вместо устаревшего Trac. Некоторые люди были против переезда, потому что не было возможности перенести заявки с Trac на GitHub. После дня споров, я предложил написать такой конвертер. Людям идея понравилась, и я потратил некоторое время на непосредственно написание кода, а в результате проект полностью сохранил историю своих заявок. Я просто выступил с предложением, а основные разработчики проекта продолжали работать над самим Parrot. Существует множество путей помочь сообществу открытого кода, если просто видеть немного больше, чем очевидную задачу программирования новых функций. Любой, кто использует ПО с открытым исходным кодом, может привнести свой вклад сообществу и поддержать свободное программное обеспечение как важную часть компьютерного мира.
