Это перевод заметки Брайана Форда .
Я написал это руководство, чтобы помочь любому присоединяться или выкладывать свои (contributing) open source проекты на GitHub. Одна из причин крутости open source - в желании людей помогать друг другу.
Не важно - программируете ли вы много лет или только начали, есть несколько моментов, которые вам нужно знать, чтобы продуктивно использовать GitHub. Гайдов "как" сделать что-то с технической точки зрения на GitHub множество: на какую кнопку нажать, какие команды запустить и подобное.
В начале публикация своей работы на GitHub пугает. Существует мало руководств, посвященных этикету, практическим приёмам и ожиданиям. Этот гайд направлен заполнить пробелы.
Читая этот гайд, помните, что нормально (и даже ожидаемо!) делать ошибки. Не нужно запоминать каждую мелочь. Делайте всё возможное и учитесь в процессе.
Гайд предполагает, что вы работаете с JavaScript-модулем, установленным через npm или bower , который размещён на GitHub. Кроме команд, предназначенных для npm или bower , большая часть этого гайда применима к другим платформам и языкам.
Перед тем, как спрашивать, поищите и почитайте существующие записи. Загляните в документы, Google, GitHub, и StackOverflow. Если на ваш вопрос уже отвечали раньше много раз, то разработчики, ответственные за проект, возможно, устали повторять ответ.
Если проект маленький, обычно принято задавать вопросы через отправку issue (см. ниже). Если большой - у них скорее всего есть рассылка или IRC-канал, через которые лучше всего обращаться с вопросами. StackOverflow - также очень хороший ресурс. Когда есть возможность, задавайте вопросы на публичном форуме. Таким образом ответить на вопрос сможет кто угодно, а ответ будет доступен любому человеку с таким же вопросом. Если ничего не работает, можно написать в твиттер или на почту поддержки проекта.
На GitHub уведомления о багах или улучшениях называются "issues".
Перед тем как отправить уведомление, нужно поискать существующие issues. Не забывайте проверять и открытые issues и закрытые. Если вы найдёте issue, который подобен вашему, прочтите всё о нём.
Если issue такой же как у вас, вы можете прокомментировать с дополнениями, чтобы помочь ответственным за проект разработчикам (maintainers) сделать отладку. Добавление комментария автоматически подпишет вас на уведомления по почте, что может быть полезным, когда будут появляться обновления, касающиеся этого issue. Если вам нечего добавить, но вы хотите получать уведомления об обновлениях на почту, вы можете нажать кнопку "watch", которая находится под комментариями.
Если вы не можете ничего найти в существующих issues, не стесняйтесь отправить свой.
Нужно проверить, что указана версия проекта, так же как и версии связанных с ним приложений. Например, удостоверьтесь, что включили номера версий, выводимые командами node --version и npm list . Если вы заметите, что у вас установлена не последняя версия, используйте npm update и подтвердите, что issue всё ещё присутствует.
Разработчики проекта очень приветствуют тщательные разъяснения. Обычно это помогает им быстрее справиться с проблемой и всем это на руку.
Лучший способ - сделать "Fork" (копию) репозитория на GitHub. Это создаст экземпляр-клон репозитория в вашем GitHub аккаунте.
Перед тем как улучшать код, стоит сфокусироваться на том, что вы хотите конкретно сделать.
Каждый коммит должен выполнять что-то одно, а на каждый PR (см. ниже) должно быть одно специфическое улучшение.
Ок, теперь вы готовы к исправлению кода? Не совсем! Перед тем, как начать редактировать, вам нужно создать ветку (branch). Branch - как альтернативная временная линия. Можете почитать о git ветках .
Делаем ветку: git checkout -b something
Если вы пытаетесь починить баг, возможно вам стоит назвать ветку "fix-short-description". Если вы добавляете функциональность, "feat-short-description" - хорошее название. Когда вы меняете что-то в коде, возможно, вам захочется испытать его внутри какого-нибудь приложения или более крупного проекта.
В отношении стиля кода - просто пытайтесь имитировать стиль существующего. Не пыхтите над ним слишком сильно. Если владельцам не понравится внешний вид вашего кода, они предложат изменения.
Большая часть проектов пользуется наборами тестов, для уверенности в том, что имеющаяся функциональность кода не меняется из-за вносимых изменений. Это помогает поддерживать софт в стабильном состоянии.
Хоть это и не очевидно, вы можете начать использовать код в своих проектах сразу же.
Вы сделали изменения, протестировали их с git commit и хотите отправить обратно в проект, чтобы они были включены в следующие версии.
На GitHub это делается с помощью отправки "pull request" (PR).
Золотое правило отправки pull request - всё выполнять так, как задумали владельцы проекта. Вы не можете читать мысли ответственных за проект, но можете посмотреть, что они делали в прошлом. Оценка этих действий заранее может повысить вероятность принятия ваших изменений.
Проще выражаясь: попытайтесь сымитировать стиль существующего кода. Обращайте внимание на отступы и стиль фигурных скобок в коде. Содержит стиль ранние инструкции return или там их избегают?
Код - не единственное, на что стоит обращать внимание. Заметьте какое время и формат имеют коммиты сообщений. Некоторые проекты используют настоящее время: "fixes the bug". А некоторые прошедшее: "fixed the bug".
Хороший способ проверить это - использовать git log и прочитать последние коммиты.
Что ещё стоит помнить:
Не меняйте номер версии софта (в package.json или bower.json). Владельцы проекта сами позаботятся об этом, когда будут выпускать новую версию.
Если проект поддерживается корпорацией, возможно у них есть Contributor License Agreement (CLA) для избежания проблем с законом.
Владельцы проекта могут быть заняты, так что дайте им немного времени. Разработчики, вовлечённые в open source, часто участвуют во множестве проектов. Нередко разработчик получает десятки нотификаций о неисправностях в день, так что будьте терпеливым.
Если они не отвечают в течение 2 недель, вы можете прокомментировать это, чтобы вынести тему наверх. Чего-нибудь, вроде, "ping @ProjectMaintainer" обычно достаточно. Если даже после этого от них ничего не слышно, электронная почта - хороший способ выйти на контакт.
Команда может ответить тремя возможными способами:
Когда команда просит внести изменения в PR, новички ошибочно закрывают существующий и создают новый. Не стоит так делать! Существующий PR легко обновляется.
Во-первых, внесите изменения в соответствующие файлы. Добавьте файл с помощью git add , как вы уже делали:
git add some-file
Затем можете изменить свой предыдущий коммит вот так:
git commit --amend
Эта команда помещает ваши поэтапные изменения в предыдущий коммит.
Чтобы обновить коммит в вашем PR, вам нужно выполнить force push:
git push --force
Команда --force сообщает git , что вы хотите перезаписать предыдущий коммит.
Другая распространенная ошибка - создание нескольких коммитов, вместо внесения изменений в один.
Хорошие новости : даже если ваше изменение не будет принято в репозиторий контрибьютора, вы в любом случае сможете его использовать. npm позволяет установить из репозитория GitHub
$ npm install user/repo
А ещё вы можете использовать свои изменения и одновременно видеть изменения исходного кода репозитория. Обычно это называется "maintaining a fork" (поддержка копии) проекта. Для этого потребуется добавить ещё один remote .
Перед тем как начинать свой проект, пожалуйста хорошо изучите существующие - нет ли сильно похожего на ваш.
Иногда вы находите старый проект, который больше не поддерживается, но он решает ваши проблемы. Как делать форк смотрите выше.
Бонус : Составляйте список заметок по ходу работы. Если найдете понравившийся модуль, можете использовать заметки, чтобы улучшить секцию «See Also» в тех модулях, которые вам встретились, пока вы вели поиск, отправив им PR. Если не найдёте нужный модуль и не создадите свой собственный, можете превратить эти заметки в секцию «See Also» для своего модуля!
Начало нового open source проекта должно быть крайней мерой. Почему?
Практический опыт: Не публикуйте ничего в npm пока у проекта не будет обоснованной минимальной функциональности.
Помните: вы всегда можете использовать npm link или npm install user/repo
Если ваш модуль - это плагин, обычно лучший способ - сделать для него префикс, в зависимости от того для чего этот плагин. В некоторых проектах есть гайды или соглашения как это делать. Например компоненты AngularJS обычно называются "angular-something", плагины Gulp -"gulp-something", а плагины Karma - "karma-something".
Хороший readme должен состоять из следующих частей:
Это правда важно . Если существуют другие модули с аналогичной функциональностью, ваш модуль должен объяснять, чем он отличается от других. Эта секция должна быть связана с другими модулями. Это поможет другим решить когда использовать ваш.
Есть много способов писать тесты. Их важность в том, что если они провалятся, процесс будет существовать с кодом ошибки. Вы можете использовать для этого assert или if (condition) { process.exit(1) } .
Бонус: вы используете инструмент CI вроде TravisCI .
Перед публикацией:
Бонус: Найдите кого-нибудь, кто будет содействовать в поддержке проекта. Отлично, если кто-то может помочь делать ревью issues и мёрджить PR. Невозможно угадать, как много свободного времени у вас будет в будущем. Обидно иметь непочиненные баги или несмёрженные PR в полезном проекте.
Обычно люди покидают сообщества, которые кажутся им недоброжелательными. Чтобы быть уверенным, что все ощущают гостеприимство, важно относиться ко всем мягко и с уважением.
Чаще всего - это не проблема. Но иногда у разработчиков случаются срывы, эмоции зашкаливают, они оскорбляются.
эта задача должна быть очевидной для решения! почему её никто не решил?
Возможно у владельца проекта есть другие важные дела в жизни, которыми ему нужно заниматься. Ставить в приоритет жизненные задачи - не значит быть лентяем. Здоровье, счастье и благополучие реального человека на другом конце интернета намного более важны, чем любой баг.
Одна из мощных сторон open source как раз в том, что вы всегда можете сделать копию и отладить ошибки сами.
вы очевидно не понимаете, о чём я говорю!
Такой тип комментария особенно отталкивает новичков. Совершать ошибки должно быть абсолютно приемлемым.
Это проблематично ещё и потому, что на окружающих участников тоже распространяется чувство вины. Возможно, вы могли бы объяснить недочёт понятнее.
Абсолютно нормально злиться из-за бессилия. Программирование - это одна из самых сложных деятельностей человека. Но, несмотря на это, нужно не упускать точки зрения других людей. Сообщество намного более ценный компонент, чем код, а быть уважительным важнее, чем быть правым.
Спасибо за то, что прочитали. Надеюсь этот гайд поможет вам получить то, чего вы хотели от open source.
Многие разработчики стремятся попасть в проекты на «open source», но не знают, с чего начать. Причина этому – неуверенность в собственных силах. На самом деле open source-проекты предоставляют массу возможностей специалистам различного профиля. Программное обеспечение с открытым кодом, или «open source», существенно повлияло на развитие информационных технологий и заинтересовало многих разработчиков. Однако зачастую специалисты видят ряд препятствий для своего участия в open source-проектах. Вот основные из них:
Полгода назад мне пришла идея создания своего open source проекта. Вместо тестовых задач на интервью мне было бы достаточно отправить ссылку на репозиторий, а перспектива помочь коллегам с решением их повседневных проблем еще больше зарядила меня энергией.
Мне всегда не нравились гемы для создания административных панелей, любое лишнее движение требует переопределения классов, для изменения полей нужно делать изменения в файлах. После размышлений и беседой с коллегами было принято решение создать новую библиотеку, которая была бы гибкой и не требовала бы дашбордов или файлов конфигурации.
Одним из ценных советов, который я получил на данном этапе, это обратить внимание в первую очередь на документацию проекта. У вас может быть очень хороший проект, но никто не будет читать исходники и пытаться понять как это работает.
Самый важный аспект, без которого дальнейшие этапы невозможны это мотивация. Идея проекта должна цеплять в первую очередь вас. Чаще всего люди привыкают к тем инструментам с которыми работают и попадают в зону комфорта.
Выбор определенного таск менеджера вопрос вкуса. Я использую pivotal tracker, основное преимущество является наличие бесплатной версии для open source проектов, присутствует сортировка задач по типу (feature, bug, chore, release), задачи можно группировать в релизы и определять дедлайн.
Еще одной приятной возможностью у pivotal tracker является интеграция с github. Если вы соблюдаете определенную конвенцию в именовании комитов, то внутри задачи будут автоматически отображены все связанные изменения с этой задачей.
Лицензия гарантирует, что другие могут использовать, копировать и модифицировать исходный код проекта. Вам необходимо добавлять этот файл в каждый репозиторий с вашим open source проектом. MIT, Apache 2.0 GPLv3 самые популярные лицензии для open source проектов, если не уверены какую выбрать можете воспользоваться удобным сервисом .
Файл CONTRIBUTING поможет другим разработчикам сделать вклад в проект. На первых шагах проекта не обязательно уделять этому файлу пристальное внимание, можно воспользоваться уже готовым шаблоном из другого проекта.
У меня было просто много желания и отсутствие четкого плана
Так же почитав историю других проектов, не только open source, я заметил, что на раннем этапе имеются слишком оптимистичные планы и переоценка своих сил и возможностей. Не так просто находить время каждый день на написание новой фичи в проект. Большую часть задач пришлось в итоге отсеять и оставить необходимый минимум для
Ниже я расскажу о том, как собрать Хромиум в домашних условиях, как выбрать задачу из системы баг-трекинга и как сделать так, чтобы ваш код оказался в репозитории.
Для начала хочу сказать, что по адресу www.chromium.org/Home находятся подробнейшие инструкции на все случаи жизни - начиная от получения исходного кода и заканчивая инструкциями по отправке ваших патчей на коммит. Кроме того, рекомендую прочитать этот документ и пройтись по ссылкам в нем.
Процесс для независимого разработчика состоит из следующих шагов:
Теперь немного о моем личном опыте. Все цифры будут приведены ориентировочно и исключительно по памяти, записей, к сожалению, не делал.
Мне удалось собрать Хром под Windows и Linux. Под Mac OS не удалось провести линковку, хотя компиляция прошла успешно.
Для сборки под Windows использовался компьютер пятилетней давности с двухядерным процессором и 3 Гб памяти. Полная сборка заняла около 6 часов (не могу сказать точнее, я ставил билд на ночь), плюс линковка - более получаса (на 32 битах оказалось невозможным включить инкрементальную линковку).
Для сборки версии под Линукс был арендован виртуальный сервер в облаке у одного из российских хостеров. Ресурсы там выделяются по запросу и при билде использовалось около 8 Гб памяти и 8 ядер процессора. Оплата там снимается за использованные ресурсы и билд с нуля обошелся, кажется, в 35 рублей. Время полного билда - около часа.
Для сборки под Mac OS использовался хакинтош в виртуальной машине, компиляция заняла больше десяти часов. Я не стал тестировать сборку под этой ОС, лишь убедился, что мои изменения не сломали билд.
Как сказал мне один из работников Google, разработчики, работающие над Хромом, используют два билд бокса с разными операционными системами на их собственный выбор. Он также добавил, что Chrome отличается от Chromium лишь наличием нескольких проприетарных модулей и логотипом. Процесс работы сотрудника Google над Chrome полностью совпадает с процессом работы независимого контрибьютора за исключением того, что сотрудник Google имеет доступ к некоторым закрытым записям в баг-трекере, связанным, например, с безопасностью.
Начинающим разработчикам рекомендуется выбирать баги с меткой GoodFirstBug . Предполагается, что задачи с этой меткой проще и человек, имеющий слабое представление о коде, сможет достаточно быстро с ними разобраться.
К счастью, некоторые несоответствия кода гайдлайнам находятся автоматически утилитой gcl, которая используется для создания чейнджлиста перед отправкой на ревью (так, у меня она нашла пробелы в конце строки, которые я не заметил).
Если это ваш первый фикс бага в проекте, то помимо изменений в коде вам необходимо внести ваше имя в файл AUTHORS и включить это изменение в ваш коммит.
С удовольствием отвечу на вопросы в комментариях.
Теги:
С помощью open source проектов можно усовершенствовать свои навыки, исправляя чужие ошибки и создавая что-то новое. Можно найти проект, который будет полезен и для собственного бизнеса, например, в медицине или e-commerce. Кроме того, как практикующие программисты, один из лучших способов мотивировать себя на занятия программированием - это работа с open source проектами. Специально для читателей блога Geekbrains мы собрали список таких проектов из разных сфер деятельности:
Пакет программного обеспечения для работы с медицинскими изображениями. 3D Slicer доступен на нескольких платформах, в числе которых Windows, Linux и OS X.
Инструмент, который позволяет распределять обработку больших массивов данных по кластерам компьютеров с помощью простых моделей программирования.
Популярный пакет программного обеспечения для работы с текстом, создания электронных таблиц, презентаций, графики, баз данных и т.д. Полностью открытый процесс разработки означает, что кто угодно может сообщать об ошибках, запрашивать новые возможности или улучшать программное обеспечение. Он написан в международном open standard формате, поэтому воспринимает файлы из других открытых офисных программных пакетов.
Платформа для управления контентом, на которой работают миллионы веб-сайтов и приложений.
Менеджер для работы с медиаданными, предназначенный для создания больших централизованных медиа-библиотек.
Свободная операционная система типа Unix.
Офисный пакет для совместной разработки с функционалом, как у Microsoft Office или OpenOffice.org.
Система для создания курсов. Бесплатное веб-приложение, которое преподаватели могут использовать для создания эффективных Интернет-сайтов для обучения. Moodle стала очень популярной среди педагогов по всему миру в качестве инструмента для создания динамических веб-сайтов для своих студентов.
ПО для создания и управления обучающим аудио и видео контентом.
Мультиплатформенная система управления корпоративным контентом написанная на Java. Работает с несколькими базами данных (в том числе MySQL, Oracle, PostgreSQL, SQLLite, и другие), а также поддерживает несколько методов аутентификации.
Софт для создания частных и общественных облаков.
Сервис позволяет создавать опросы и делиться с контактами на сайте. Удобный способ собирать данные для их последующего анализа.
DICOM-сервер для здравоохранения и медицинских исследований. Предназначен для облегчения управления данными медицинских изображений. Хороший инструмент для автоматизации медицинских задач визуализации, специфических для каждого медучреждения.
Проект создан силами Open Source сообщества и предназначен для обеспечения лучших решений для предприятий с помощью бизнес аналитики.
Основные области применения:
Java™ разработчики могут использовать компоненты проекта для быстрого создания собственных решений для бизнес аналитики.
Модульная open source система управления цифровыми данными.
Бесплатный софт для e-commerce.
Библиотека для быстрого фильтрования и сортировки больших коллекций - до 100000 элементов в браузере.
Языки c open source
Язык программирования с открытым исходным кодом и среда разработки для людей, которые хотят создавать изображения и анимацию.
R - открытый язык программирования и программная среда для статистических расчетов и графики. Язык R широко используется среди статистов для разработки статистического программного обеспечения и анализа данных.
Где найти больше open source проектов?
Один из самых крупных веб-сервисов для совместной разработки IT-проектов. Абсолютно бесплатен для open source проектов. Девиз сервиса “Social coding” можно перевести, как “Кодим вместе”.
Предназначен популяризовать open source проекты. С помощью инструментов, которые там предоставлены, разработчики создали мощное программное обеспечение в более чем 430,000 проектах; на ресурсе более 3,7 млн зарегистрированных пользователей. Популярный каталог объединяет более 41,8 млн клиентов с проектами open source и обслуживает более 4800000 скачиваний в день.
Цель Fossdroid - продвигать open source приложения на Android с помощью проекта F-Droid. Fossdroid берет свои данные из F-Droid и организует приложения в порядке, похожем на Google Play, с возможностью просмотра их по популярности.
Как узнать является ли ПО open source и каковы правила его использования?
Необходимо понимать, что не все open source проекты могут быть использованы в коммерческих целях или свободно модифицированы.Чтобы узнать, является ли ПО open source и каковы правила его использования, нужно посмотреть его лицензию . Обычно полный ее текст находится непосредственно в коде.