Общая информация:
- GitHub Repository
- Багтрекер проекта
- Форум разработки
- IRC канал разработки: #obs-dev в сети QuakeNet
Руководство для разработчиков и волонтеров:
Примечание: руководство от Jim, автора проекта OBS.
Авторский стиль сохранён насколько это возможно при переводе.
- Будьте готовы к тому, что код и коммиты проходят ревью, т.е. проверяются старшими разработчиками.
Ревью будет прямым и откровенным, и ваши изменения вполне могут не пройти в первый раз или могут быть полностью отклонены.
Может потребоваться много исправлений для того, чтобы изменения были окончательно приняты. - Если вы не хотите, чтобы проделанная вами работа была отклонена, то обсудите вашу идею для изменений через основные каналы общения разработчиков (IRC, форумы, списки рассылок) до того, как приступать к работе.
Открытый исходный код требует толстокожести. Пожалуйста, не расстраивайтесь, если ваши изменения не прошли ревью. Проанализируйте ошибки, исправляйте их и становитесь лучше 🙂 - Используемый в проекте стиль программирования: Linux-style KNF (kernel normal form, K&R):
- Максимум 80 колонок
- Предпочтительна максимальная длина функций около 42 строк
- Табуляции длиной 8 символов
- lower_case_names (имена_в_низком_регистре)
…и.т.д.
- Я выбрал это на благо проекта. Не нужно спорить, просто следуйте этому. Это не потребует вашего времени.
См. базовое руководство на kernel.org. Оно содержит много полезных рекомендаций, хотя и не является обязательной «книгой правил». - Для C++ сделано исключение насчет правила «lower_case_only». Рекомендуется использовать CamelCase, чтобы отличать его от кода на C.
Это моя персональная и субъективная часть стиля кодирования. - Коммиты — это не просто изменения в коде. Они также должны рассматриваться как аннотация к коду.
По этой причине не нужно вкладывать несвязанные изменения в один коммит. Разделяйте разные изменения на отдельные коммиты и делайте раздельные запросы на изменения(pull requests) для любых несвязанных изменений.
Заголовок коммита должен быть ограничен 50 символами, а текст описания переноситься каждые 72 символа (для этого можно настроить свой текстовый редактор).
Описания должны быть краткими и информативными.
См. этот документ для более подробной информации о том, как и почему лучше оформлять сообщения к коммитам. - Код ядра только на C. Исключение может быть сделано только в случае если для определенной ОС абсолютно необходимо использование иного языка.
- Для модулей и UI может использоваться C, C++ или Objective-C (для apple).
Однако, пожалуйста, старайтесь использовать C, кроме случаев когда используемый вами API требует использования именно C++ или Objective-C (как, например, Windows COM classes или apple Objective-C APIs). - Не используйте зависимости ради удобства. Здесь и так достаточно зависимостей. Используйте их только если это совершенно точно необходимо.
- Если вы не знаете над чем именно работать и просто хотите помочь, посмотрите багтрекер. Он содержит список того, над чем необходимо работать.
- Старайтесь уважать желания авторов и тех, кто занимается поддержкой. Для того, чтобы быть полезным, нужно всегда прислушиваться и часто интересоваться мнением других участников проекта, но не стоит ожидать полной демократии.