Для внесения вклада в проект Spoon рекомендуется создать запрос на слияние (pull request, PR) на GitHub. После принятия запроса объединённый код будет защищён авторским правом согласно лицензии Cecill-C.

Кодекс поведения интеграторов

Интеграторами являются разработчики, имеющие права записи в репозиторий. Интеграторы должны соблюдать следующие правила:* Интеграторы Spoon объединяют атомарные запросы на слияние (одна исправленная ошибка или одна новая функциональность).

• Интеграторы Spoon объединяют только хорошо протестированные и подробно документированные запросы на слияние после тщательной проверки кода.
• Интеграторы Spoon проверяют качество сообщений о сжатых слияниях, и меняют их при необходимости. Конвенция состоит в том, что сообщение начинается со слова fix:, feat:, test:, doc:, perf:, chore:, refactor:, checkstyle: (источник). В качестве опционального параметра можно указывать затронутый компонент, например fix(prettyprinter): ....
• Интеграторы Spoon никогда не отправляют изменения напрямую в ветку master.
• Интеграторы Spoon никогда не объединяют свои собственные запросы на слияние.
• Интеграторы Spoon оставляют запросы на слияние открытыми как минимум один день перед объединением, чтобы сообщество было осведомлено и могло высказаться по этому вопросу.
• Острый конфликт, который невозможно разрешить временным решением или обсуждением, разрешается голосованием среди интеграторов.Как стать интегратором? Интеграторами являются разработчики, сделавшие значительный вклад за последние 12 месяцев (период времени). Значимость оценивается текущими интеграторами, которые выбирают новых участников.

Текущие интеграторы:

• Николас Харранд @nharrand
  • Электронная почта: nicolas.harrand@gmail.com
• Мартин Монперрус @monperrus
  • Электронная почта: martin.monperrus@gnieh.org
  • Отпечаток ключа GPG: AF7B251DA8126C30896FAFF77D398AD45AEEEC93
• Мартин Витлингер @MartinWitt
  • Электронная почта: wittlinger.martin@gmail.com
• Ганнес Грейле @SirYwell
  • Электронная почта: hannesgreule@outlook.de
• I-Al-Istannen @I-Al-Istannen
  • Электронная почта: me@ialistannen.de

Руководства для pull-requests

Существуют различные типы pull-requests, в частности исправление ошибок, добавление новых возможностей, рефакторинг и pull-requests, направленные на повышение производительности.

Руководства для всех pull-requests:* Pull-request должен выполнять одно действие (например, исправление одной ошибки или реализация одной возможности).

• Pull-request должен пройти все проверки непрерывной интеграции (включая правила форматирования).

• Pull-request должен иметь явное и понятное объяснение.

• Если pull-request решает проблему, просто добавьте "fix #номер_проблемы" или "close #номер_проблемы" в описание, см. документацию для подробностей.

• Название pull-request:

  • Название pull-request начинается с префикса, указывающего его тип: "fix:", "feature:", "refactor:", "perf:", "checkstyle:".
  • Pull-requests, находящиеся в процессе выполнения, имеют префикс "WIP".
  • Pull-requests, готовые для проверки, имеют префикс "review" или помечаются как "review".* Избегайте force-pushing после того, как вы отметили свой pull-request как готовый для проверки или получили любую форму обратной связи по вашему pull-request.
  • Хотя чистая и понятная история коммитов может помочь при проверке pull-request, это может запутать проверяющих, если ранее просмотренные коммиты исчезнут.
  • Обратите внимание, что pull-requests сворачиваются. Не беспокойтесь, если история коммитов станет немного запутанной после получения обратной связи.
  • Force-push к pull-requestам типа "WIP" допустимо, пока вы не сотрудничаете с другими людьми.

• Ваш вклад очень ценим! Если у вас есть что-то интересное, мы будем рады принять ваш pull-request даже если он ещё не идеален. Сообщество Spoon поможет вам исправить оставшиеся проблемы, если они есть;)

• Версия JUnit:

  • Pull-request для миграции существующих тестов с JUnit4 на JUnit5 приветствуются.
  • Новые классы тестов должны использовать JUnit5.
  • Добавление тестовых случаев к существующим классам тестов JUnit4 допустимо, но попытайтесь придерживаться базового уровня (если возможно, используйте только аннотацию @Test).

Руководства для pull-requests исправления ошибок:

• Pull-request должен содержать тестовый случай, демонстрирующий ошибку.Руководства для pull-requests новых возможностей:

• В запросе на слияние должны содержаться набор тестовых случаев, указывающие ожидаемое поведение новой функции.

• В запросе на слияние должна содержаться обновленная документация в папке doc, объясняющая новую функцию.

• В запросе на слияние должны пройти все архитектурные правила, проверяемые в SpoonArchitectureEnforcerTest (например, новые пакеты должны быть зарегистрированы там).

Другие виды запросов на вытягивание (pull-request):1. Приветствуются запросы на вытягивание с прошедшими тестовыми случаями, они описывают ранее неописанное поведение и имеют префикс "test:". 2. Приветствуются запросы на вытягивание с провалившимися тестовыми случаями, они воспроизводят ошибки и очень полезны для поддержки, чтобы исправить их. Вы можете предотвратить провал CI, добавив аннотацию @GitHubIssue(issueNumber = <ваш номер задачи>, fixed = false). Если вы исправили тестовый случай с такой аннотацией, отметьте этот тестовый случай как исправленный с помощью @GitHubIssue(issueNumber = <ваш номер задачи>, fixed = true).

Общие изменения ("chore") в запросах на вытягивание модифицируют настройки CI.

Если нет активности по задаче или по запросу на вытягивание в течение трёх месяцев, он закрывается.

Открытый API

Открытый API состоит из всех публичных классов и методов, за исключением тех, для которых хотя бы одно из следующих условий выполняется:

• аннотировано @Internal
• расположено в пакете с названием internal, включая все подпакеты, то есть **.internal.**

Классы, аннотированные @Experimental, планируются к включению в открытый API в будущем, но пока считаются нестабильными и могут меняться в некомплементарном для обратной совместимости порядке.

Политика подмодулей --------------------По умолчанию мы предпочитаем добавление новых функциональностей в spoon-core, чтобы иметь наиболее простую возможную интеграцию для клиентов. Мы обязуемся поддерживать код в spoon-core.Мы создаем подмодули при выполнении одного из следующих условий:

1. функциональность сделает бинарник spoon-core слишком большим;

ИЛИ

2. функциональность слишком экспериментальна / нестабильна, чтобы соответствовать высокому качественному стандарту spoon-core;

ИЛИ

3. команда интеграторов приветствует вклад, но не может обязаться его поддерживать.

Подмодули не публикуются в Maven Central и поэтому требуют сборки из исходников.