Skip to content

Latest commit

 

History

History
178 lines (128 loc) · 26.1 KB

C4.ru.md

File metadata and controls

178 lines (128 loc) · 26.1 KB
Raw
slug title name status editor
42
42/C4
Collective Code Construction Contract
stable
Pieter Hintjens <ph@imatix.com>

Collective Code Construction Contract (C4) — это эволюция модели github.com Fork + Pull Model, целью которой является создание оптимальной модели сотрудничества для проектов свободного ПО. Это 2 версия спецификации C4 и она обесценивает RFC22.

Лицензия

Copyright © 2009-2016 Pieter Hintjens

Эта спецификация — бесплатное программное обеспечение; вы можете перераспределить его и/или изменить его в соответствии с общедоступной лицензией GNU, опубликованной Фондом свободного программного обеспечения; либо третьей версии Лицензии, либо (по вашему выбору) любой более поздней версии.

Эта спецификация распространяется в надежде, что она будет полезна, но БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ; даже без подразумеваемой гарантии КОММЕРЧЕСКОЙ ЦЕННОСТИ или ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ. Дополнительную информацию см. В GNU General Public License. Вы должны были получить копию GNU General Public License вместе с этой программой; если нет, см. http://www.gnu.org/licenses.

Аннотация

Спецификация C4 описывает стандартные процессы внесения изменений в проект по разработке ПО, их обсуждения и оценки. Она определяет конкретные технические требования для составляющих проекта, таких как: руководство по стилю кода, модульных тестов, git или аналогичных систем. Она также устанавливает роли для работающих над проектом, указывая им четкие обязанности. В C4 описывается процесс документирования и обсуждения вопросов, включая поиск консенсуса и четких описаний, использование «Pull requests» и систематических ревью.

Язык

Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «СЛЕДУЕТ», «НЕ СЛЕДУЕТ», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» в этом документе следует интерпретировать так, как описано в RFC 2119.

RFC 2119

RFC 2119

Ключевые слова для обозначения уровня требований в RFC

Статус документа

Этот документ относится к категории документов BCP (Best Current Practice) для сообщества Internet. Принимаются поправки и предложения, направленные на совершенствование документа. Допускается свободное распространение документа.

Тезисы

Во многих документах, описывающих стандарты, используются модальные глаголы для обозначения уровня требований. Такие слова часто выделяются заглавными буквами1. В данном документе определяется толкование этих глаголов и производных от них слов в документах IETF. Авторам документов, следующих приведенным здесь требованиям, рекомендуется помещать в начале документов приведенный ниже текст:

The key words «MUST», «MUST NOT», «REQUIRED», «SHALL», «SHALL NOT», «SHOULD», «SHOULD NOT», «RECOMMENDED», «MAY», and «OPTIONAL» in this document are to be interpreted as described in RFC 21192. Отметим, что «сила» этих глаголов зависит от уровня требований использующего их документа.

  1. MUST — необходимо Это слово, а также термины требуется (REQUIRED) и нужно (SHALL) используется для требований, которые являются абсолютно необходимыми в данной спецификации.

  2. MUST NOT — недопустимо Эта фраза или слова SHALL NOT (не позволяется) означают абсолютный запрет в рамках спецификации.

  3. SHOULD — следует Это слово, а также глагол рекомендуется (RECOMMENDED) используется для обозначения требований, от выполнения которых можно отказаться при наличии разумных причин. Однако при таком отказе следует помнить о возможных проблемах в результате отказа и принимать взвешенное решение.

  4. SHOULD NOT — не следует Эта фраза и глагол не рекомендуется (NOT RECOMMENDED) используются применительно к особенностям или функциям, которые допустимы и могут быть полезными, но могут вызывать проблемы. При реализации таких опций следует учитывать возможность возникновения проблем и принимать взвешенное решение.

  5. MAY — возможно Это слово, а также прилагательное необязательный (OPTIONAL) обозначают элементы, реализация которых является необязательной. Одни разработчики могут включать такие опции в свою продукцию для расширения возможностей, а другие -опускать в целях упрощения. Реализация, не включающая ту или иную опцию, должна быть готова к работе с реализациями, которые используют эту опцию (возможно совместная работа будет обеспечиваться за счет некоторого ущерба функциональности). Включающие опцию реализации должны быть готовы (естественно, без использования такой опции) к взаимодействию с реализациями, которые такую опцию не поддерживают.

  6. Рекомендации по использованию Приведенные в этом документе определения следует использовать очень аккуратно. В частности, необходимо применять их лишь там, где это действительно диктуется требованиями интероперабельности или для предотвращения ситуаций, когда может быть нанесен вред (например, для ограничения избыточных повторов передачи). Например, такие обозначения недопустимо использовать для обозначения преимуществ одной реализации по сравнению с другой, если это не продиктовано соображениями интероперабельности.

  7. Вопросы безопасности Рассматриваемые здесь термины часто используются при обсуждении вопросов безопасности. Отказ от выполнения необходимых (MUST) или рекомендуемых (SHOULD) требований или реализация недопустимых (MUST NOT)/нерекомендуемых (SHOULD NOT) может существенно влиять на безопасность. Авторы документов должны уделить внимание вопросам безопасности, чтобы не появлялись реализации с невыполненными требованиями или рекомендациями.

  8. Благодарности Определения терминов даны на основе использования этих терминов во множестве RFC. Кроме того, при подготовке документа были учтены предложения многих людей, включая Robert Ullmann, Thomas Narten, Neal McBurnett, Robert Elz.

  9. Адреса авторов Scott Bradner Harvard University 1350 Mass. Ave. Cambridge, MA 02138 phone — +1 617 495 3864 email — sob@harvard.edu Перевод на русский язык Николай Малых nmalykh@bilim.com 1 В переводах на сервере http://rfc.com.ru/ используется выделение жирным шрифтом. Прим. перев. 2 Ключевые слова необходимо, недопустимо, требуется, следует, не следует, рекомендуется, не рекомендуется, возможно, необязательно в данном документе должны интерпретироваться в соответствии с требованиями RFC 2119.

http://rfc.com.ru/

1. Цели

Спецификация C4 предназначена для обеспечения оптимальной неоднократной модели сотрудничества для проектов с открытым исходным кодом. Она преследует следующие цели:

  1. Расширение сообщества, формируемого вокруг проекта, уменьшение порога вхождения для новых участников и создание масштабируемой модели партнерства с позитивной обратной связью;
  2. Уменьшение зависимости от ключевых лиц путем распределения требуемых наборов навыков по разным специалистам, чтобы на любую область приходился высокий уровень компетенции;
  3. Обеспечение более быстрой и точной разработки проекта путем развития процесса принятия решений;
  4. Поддержание жизненных циклов версий проекта от экспериментальной до стабильной, путем проведения безопасных экспериментов, быстрого реагирования на неполадки и изолированием стабильного кода;
  5. Уменьшение внутренней сложности репозиториев, что приводит к облегчению для участия контрибьюторов и уменьшению объема ошибок;
  6. Обеспечение статуса коллективной собственности проекту, что увеличивает финансовую мотивацию контрибьюторов и снижает риск плагиата со стороны враждебных организаций.

2. Разработка

2.1. Основные положения

  1. Проект ДОЛЖЕН использовать распределенную систему управления версиями git.
  2. Проект ДОЛЖЕН быть размещен на github.com или его эквиваленте, называемом здесь «Платформа».
  3. Проект ДОЛЖЕН использовать систему регистрации проблем, предоставляемую Платформой.
  4. Проект ДОЛЖЕН иметь четко документированные рекомендации по стилю кода.
  5. «Контрибьютор» — это человек, который хочет предоставить патч, являющийся набором коммитов, которые решают четко определенные проблемы.
  6. «Мейнтейнер» — это человек, который объединяет патчи в проекте. Мейнтейнеры не являются разработчиками; их работа заключается в соблюдении процесса разработки.
  7. Контрибьюторы НЕ ДОЛЖНЫ иметь возможность коммитить в репозиторий, если они не являются также Мейнтейнерами.
  8. Мейнтейнеры должны иметь возможность коммитить в репозиторий.
  9. Каждый, без различия или дискриминации, ДОЛЖЕН иметь равное право на возможность стать Контрибьютором в соответствии с условиями этого контракта.

2.2. Лицензирование и собственность

  1. Проект ДОЛЖЕН использовать такую же лицензию, как MPLv2, или вариант GPLv3 (GPL, LGPL, AGPL).
  2. Все вклады в исходный код проекта («патчи») ДОЛЖНЫ использовать ту же лицензию, что и проект.
  3. Все патчи принадлежат их авторам. НЕ ДОЛЖЕН присутствовать никакой процесс присвоения авторских прав.
  4. Каждый Контрибьютор ДОЛЖЕН быть ответственным за идентификацию в списке Контрибьюторов проекта.

2.3. Требования к патчу

  1. Мейнтейнеры и Контрибьюторы ДОЛЖНЫ иметь учетную запись Платформы и ДОЛЖНЫ использовать свое настоящее имя или известный псевдоним.
  2. Патч ДОЛЖЕН представлять из себя минимальное решение конкретной идентифицированной и согласованной проблемы.
  3. Патч ДОЛЖЕН придерживаться правил стиля кода проекта, если они определены.
  4. Патч ДОЛЖЕН придерживаться руководящих принципов «Разработка публичных Интерфейсов», определенных ниже.
  5. Патч НЕ ДОЛЖЕН включать нетривиальный код из других проектов, если только Контрибьютор не является оригинальным автором этого кода.
  6. Патч ДОЛЖЕН компилироваться и проходить самотестирование проекта, по крайней мере, на основной целевой платформе.
  7. Сообщение коммита ДОЛЖНО состоять из одной короткой (менее 50 символов) строки, в которой задается проблема («Проблема: ...»), за которой следует пустая строка, а затем предлагаемое решение («Решение: ...») ).
  8. «Корректный патч» — это патч, который удовлетворяет вышеуказанным требованиям.

2.4. Процесс разработки

  1. Изменения в проекте ДОЛЖНЫ регулироваться алгоритмом точного выявления проблем и применения минимальных точных решений этих проблем.
  2. Чтобы запросить изменения, пользователь ДОЛЖЕН зарегистрировать проблему на Платформе.
  3. Пользователь или Контрибьютор ДОЛЖНЫ описать проблему, с которой они столкнулись.
  4. Пользователь или Контрибьютор ДОЛЖНЫ стремиться к консенсусу относительно точности их наблюдения и ценности решения проблемы.
  5. Пользователи НЕ ДОЛЖНЫ регистрировать запросы на новые возможности, идеи, предложения или любые решения проблем, которые явно не задокументированы и не доказуемы.
  6. Таким образом, история версий проекта ДОЛЖНА быть списком значимых проблем, документируемых и решаемых.
  7. Чтобы работать над проблемой, Контрибьютор ДОЛЖЕН сделать копию (fork) репозитория проекта, а затем работать с этой копией.
  8. Чтобы отправить патч, Контрибьютор ДОЛЖЕН создать Pull Request в проект.
  9. Контрибьютор НЕ ДОЛЖЕН производить коммиты непосредственно в проект.
  10. Если Платформа реализует создание Pull Request'а к созданной проблеме, Контрибьютор МОЖЕТ создать Pull Request без регистрации отдельной проблемы.
  11. Чтобы обсудить патч, люди МОГУТ комментировать коммиты и Pull Request'ы на Платформе или в другом месте.
  12. Чтобы принять или отклонить патч, Мейнтейнер ДОЛЖЕН использовать интерфейс платформы.
  13. Мейнтейнеры НЕ ДОЛЖНЫ принимать свои собственные исправления, за исключением исключительных случаев, таких как недоступность других Мейнтейнеров в течение длительного периода (более 1-2 дней).
  14. Мейнтейнеры НЕ ДОЛЖНЫ делать оценочные суждения относительно корректных исправлений.
  15. Мейнтейнерам СЛЕДУЕТ быстро принимать исправления от Контрибьюторов.
  16. Мейнтейнеры МОГУТ принимать некорректные исправления от других Контрибьюторов с целью (а) прекращения бесплодных дискуссий, (б) улавливания неправильных патчей в истории, (в) привлечения Контрибьюторов к улучшению качества их исправлений.
  17. Пользователь, создавший проблему, ДОЛЖЕН закрыть проблему после проверки исправления.
  18. Любой участник, который имеет оценочные суждения на патче, ДОЛЖЕН выразить их через свои собственные патчи.
  19. Мейнтейнеры ДОЛЖНЫ закрывать проблемы пользователей, которые остаются без действий в течение неприемлемо долгого периода времени.

2.5. Ветки и релизы (Branches and Releases)

  1. Проект ДОЛЖЕН иметь одну ветку («мастер»), которая всегда содержит последнюю версию, и ДОЛЖЕН всегда компилироваться.
  2. В проекте НЕ ДОЛЖНЫ использоваться «topic branch» по какой-либо причине. В персональных ветках МОГУТ быть использованы «topic branch».
  3. Для создания стабильного релиза, Мейнтейнер должен использовать тэг в репозитории. Стабильные релизы всегда ДОЛЖНЫ быть отделены от мастера ветки.

2.6. Разработка публичных Интерфейсов

  1. Все публичные Интерфейсы (API или протоколы) ДОЛЖНЫ документироваться.
  2. Все публичные Интерфейсы ДОЛЖНЫ иметь пространство для расширения и экспериментов.
  3. Патч, который изменяет стабильный публичный Интерфейс, НЕ ДОЛЖЕН нарушать работоспособность существующих приложений, если не будет преобладающего консенсуса относительно ценности этого решения.
  4. Патч, вводящий новые функции, ДОЛЖЕН делать это с использованием новых имен (новый Интерфейс).
  5. Новые Интерфейсы ДОЛЖНЫ маркироваться как «черновик» («draft»), пока они не станут стабильными и не будут использоваться реальными пользователями.
  6. Старые Интерфейсы ДОЛЖНЫ систематически отмечаться как «устаревшие» («deprecated») и заменены их новыми аналогами по мере необходимости.
  7. По прошествию достаточного количества времени, устаревшие Интерфейсы ДОЛЖНЫ быть удалены.
  8. Имена устаревших Интерфейсов НЕ ДОЛЖНЫ повторно использоваться новыми Интерфейсами.

2.7. Администрирование проекта

  1. Учредители проекта ДОЛЖНЫ выступать в качестве Администраторов по набору Мейнтейнеров.
  2. Администраторы ДОЛЖНЫ обеспечить свою собственную преемственность, продвигая наиболее эффективных Мейнтейнеров.
  3. Новый Контрибьютор, который делает правильные исправления, который четко понимает цели проекта, и процесс разработки ДОЛЖЕН быть приглашен стать Мейнтейнером.
  4. Администраторы ДОЛЖНЫ удалять Мейнтейнеров, неактивных в течение длительного периода времени, или неоднократно нарушивших изложенный процесс разработки.
  5. Администраторы ДОЛЖНЫ блокировать «плохих участников», которые вызывают стресс и причиняют боль другим людям, участвующим проекте. Это должно быть сделано после публичного обсуждения, с возможностью для всех сторон говорить. «Плохой участник» — это тот, кто неоднократно игнорирует правила и культуру проекта, выставляет беспочвенные аргументы, производит враждебные или оскорбительные действия, и который не может самостоятельно корректировать свое поведение, когда другие просят его сделать это.

Читать еще

  • Модели 1 и 2 Аргириса — цели C4 согласуются с моделью Аргириса 2.
  • Toyota Kata — книга о совершенствовании процессов производства и управления.

Реализации