Участие в разработке

Общая информация:

Руководство для разработчиков и волонтеров:

Примечание: руководство от 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).
  • Не используйте зависимости ради удобства. Здесь и так достаточно зависимостей. Используйте их только если это совершенно точно необходимо.
  • Если вы не знаете над чем именно работать и просто хотите помочь, посмотрите багтрекер. Он содержит список того, над чем необходимо работать.
  • Старайтесь уважать желания авторов и тех, кто занимается поддержкой. Для того, чтобы быть полезным, нужно всегда прислушиваться и часто интересоваться мнением других участников проекта, но не стоит ожидать полной демократии.