О докладчике
1. Хостинг Git репозиториев.
2. Система управления проектами.
3. Социальная сеть для разработчиков.
Уровень 0: архивный и музейный код.
Исходники доступны публично под одной из open-source
или «source-available» лицензий.
Развитие продукта не предполагается.
Участие сообщества не обязательно.
Примеры:
— id-Software/DOOM;
— microsoft/MS-DOS;
— vk-com/kphp-kdb;
Важно для сохранения культурного наследия.
Уровень 0: архивный и музейный код.
Примеры:
— заброшенные проекты;
— проекты с оконченным циклом развития;
— демонстрационный код в рамках исследования;
— вынужденный open-source для соответствия лицензии;
— проекты по сохранению культурного наследия,
представляющего исторический интерес;
Уровень 1: «кафедральная разработка».
Исходники доступны публично.
Продукт развивается без участия сообщества.
Пример 1:
— SQLite: разработка командой небольшого размера;
патчи принимаются в исключительных случаях
и обычно переписываются.
Пример 2:
— разработка внутри корпораций
с периодической публикацией снепшотов кода.
Уровень 2:
Исходники доступны публично.
Патчи от сообщества принимаются.
Закрытые процессы разработки.
Процессы разработки:
— правила разработки (contribution guidelines);
— таск-трекер;
— система code review;
— планы разработки (development roadmap);
— система тестирования и CI;
— релизный цикл;
— поддержка пользователей;
— документация;
Уровень 3:
Исходники доступны публично.
Патчи от сообщества принимаются.
Открытые процессы разработки.
Максимальное поощрение и вовлечение сообщества.
GitHub — это социальная сеть для разработчиков.
Вопрос: может ли GitHub вместить в себя все процессы разработки,
чтобы максимально использовать его преимущества?
Пример 1: torvalds/linux
Возможно крупнейшее и самое развитое сообщество.
Недавно начали использовать GitHub для хостинга кода.
Изменения принимаются через списки рассылки,
pull requests на GitHub не используются
(как будто используются, но по факту, содержат мусор).
Для issue tracker используется Bugzilla,
Issues на GitHub не предусмотрены.
Для CI используется отдельный продукт kernelci.org.
Никакие процессы не интегрированы с GitHub.
Пример 2: llvm/llvm-project
Один из наиболее активных open-source C++ продуктов.
Недавно перешли с SVN и своего хостинга на Git и GitHub.
Все pull requests на GitHub автоматически закрываются роботом.
Патчи рассматриваются в Phabricator: https://reviews.llvm.org/
Для issue tracker используется Bugzilla: https://bugs.llvm.org/
Никакие процессы не интегрированы с GitHub.
Пример 3: mongodb/mongo
В качестве issue tracker используется JIRA
Изменения публикуются в виде pull requests.
Code review и merge производится вне GitHub.
Участие сообщества в разработке минимально.
Для CI системы используется собственная разработка Evergreen: https://evergreen.mongodb.com/
Публично доступны только результаты тестов, но не логи и артифакты.
Пример 4: arangodb/arangodb
Используются issues и pull requests на GitHub.
Активные обсуждения и code review в рамках GitHub.
Закрытый CI: ссылки ведут на недоступную страницу.
Пример 5: tensorflow/tensorflow
Используются issues и pull requests на GitHub.
Активные обсуждения и code review в рамках GitHub.
Открытый CI: используется собственная система,
логи и артифакты доступны публично.
Низкий порог входа:
— простота и понятность кода, наличие design docs;
— хорошо документированный код — как учебник.
Открытый не только код, но и процессы:
— разработка open-source продукта может быть реалити-шоу!
Основные разработчики используют те же инструменты, что и внешние:
— отправляют pull requests и мержат их по одинаковым правилам.
Обсуждения и планы доступны снаружи:
— контрибьютор может выбрать для реализации крупную задачу,
и обсудить способы её реализации.
Минимальные усилия для внесения изменений:
— наличие code style и guidelines;
— отсутствие необходимости регистрации на внешнем сервисе;
— отсутствие заполнения сложных форм;
— максимально простой процесс согласия с CLA или DCO.
Быстрая обратная связь в pull requests:
— публично доступная, автоматизированная система CI:
быстро сообщает о тех ошибках, которые автор может исправить сам.
— сборки, линтеры, форматирование кода, статический анализ,
тесты и тестовое покрытие, фазинг...
Дружелюбный процесс code review:
— быстрое назначение ревьюеров;
— совместная работа над кодом и доведение до мержа.
Вовлечение и поощрение контрибьюторов:
— обязательные credits в changelog, списке авторов;
— конкурсы и хакатоны; сувениры, подарки;
— вовлечение в конференции и мероприятия;
— обучающие проекты и взаимодейтсвие с институтами;
— технические статьи, интересные для разработчиков;
Нельзя в чём-либо обвинять контрибьюторов:
— если вы приняли недоделанный код — это ваша проблема;
— вклад в ваш продукт должен быть поводом для гордости.
Время и внимание:
— в развитие сообщества придётся вкладывать много усилий.
Изначально разрабатывался в Яндексе.
Применяем на практике все указанные рекомендации :)
Работа с сообществом — существенная часть
должностных обязанностей моей команды.
Сейчас 46%* изменений — сообщество.
:) SELECT * FROM system.contributors ┌─name──────────────────────────────────┐ │ Olga Khvostikova │ │ abdrakhmanov │ │ Mikhail Filimonov │ │ Jason │ │ achulkov2 │ │ Veniamin Gvozdikov │ ... │ Artemeey │ │ ivanzhukov │ │ Ilya Khomutov │ └───────────────────────────────────────┘ 855 rows in set.
