Сначала спасибо за то, что выделили время, чтобы внести свой вклад!
Этот проект регулируется кодом поведения Spring. Участвуя, вы обязаны придерживаться этого кода. Пожалуйста, сообщите о недопустимом поведении на spring-code-of-conduct@spring.io.
Если у вас есть вопрос, проверьте Stack Overflow используя этот список тегов. Найдите существующий диалог, или начните новый, если это необходимо.
Если вы считаете, что существует проблема, просмотрите существующие проблемы, пробуя несколько разных способов найти обсуждения, прошлых или текущих, связанные с этой проблемой. Чтение этих обсуждений поможет вам лучше понять проблему, а также поможет нам принять решение.#### Создайте проблему
Отчет о проблеме или запрос на новую функцию — отличный способ внести вклад. Ваш отзыв и беседы, возникающие из него, обеспечивают непрерывный поток идей. Однако, перед созданием билета, пожалуйста, потратите время на запрос и исследование.
Если вы создали проблему после обсуждения на Stack Overflow, пожалуйста, предоставьте описание в проблеме вместо простого указания на Stack Overflow. Проблемный трекер является важным местом хранения для обсуждений дизайна и должен быть самодостаточным.
Как только вы будете готовы, создайте проблему на GitHub. Многие проблемы вызваны незначительным поведением, опечатками и непреднамеренной конфигурацией. Создание минимального воспроизводимого примера (начиная с https://start.spring.io, например) проблемы помогает команде быстро отсеять ваш запрос и выявить суть проблемы.
Когда проблема создается впервые, она помечается как waiting-for-triage
, то есть ждет рассмотрения командой. После того как проблема будет проверена, команда может запросить дополнительную информацию при необходимости, а затем, основываясь на найденных данных, проблема либо получает целевой майлстоун, либо закрывается с конкретным статусом.При завершении исправления проблема закрывается, но может быть снова открыта до выпуска исправления. После этого проблема обычно больше не будет открываться. В редких случаях, если проблема вообще не была исправлена, её могут снова открыть. Однако в большинстве случаев любые последующие отчеты потребуют создания новых проблем с новым описанием.
Нужно ли создать проблему перед отправкой pull request? Нет, просто создайте pull request и используйте описание для предоставления контекста и мотивации, как это делалось бы для проблемы. Если вы хотите начать обсуждение заранее или уже создали проблему, после создания pull request мы закроем проблему как устаревшую и продолжим обсуждение под pull request.
Всегда проверяйте ветку main
и отправляйте pull request против неё (для целевой версии см. settings.gradle). Обратные совместимости для предыдущих версий будут рассматриваться в каждом случае и отражены как версия исправления в трекере проблем.
Выберите гранулярность ваших коммитов осознанно и объедините коммиты, представляющие несколько правок или исправлений одного логического изменения. Для общего представления о том, как можно улучшить историю коммитов, см. раздел Rewriting History книги "Pro Git".1. Все коммиты должны содержать штамп Signed-off-by в конце каждого сообщения коммита для указания согласия автора с Декларацией Оригинального Разработчика. Для дополнительной информации обратитесь к блоговой записи Привет DCO, Прощай CLA: Упрощение вкладов в Spring.1. Форматируйте сообщения коммитов с использованием 55 символов для строки темы, 72 символов на каждую строку описания, за которым следует номер проблемы, которую исправили, например, Закрывает gh-22276
. Для лучших практик относительно сообщений коммитов см. раздел Руководство по коммитам книги "Pro Git". Используйте git log
, чтобы просмотреть примеры.
Если существует предыдущий запрос, укажите номер проблемы в GitHub в описании запроса на слияние (pull request).
Если ваш вклад будет принят, он может быть существенно модифицирован до слияния. Вы, вероятнее всего, сохраните атрибуцию авторства ваших коммитов в Git при условии, что основная часть ваших изменений остается нетронутой. Вас также могут попросить доработать отправленное вами.
Если вас попросят сделать исправления, просто выполните изменения против того же самого ветвления, и ваш запрос на слияние будет обновлён. Другими словами, вам не требуется создавать новый запрос на слияние при необходимости внесения изменений.
Помощь в проверке запросов на слияние является ещё одним отличным способом внести свой вклад. Ваши отзывы могут помочь сформировать реализацию новых функций. Однако, когда вы проверяете запросы на слияние, пожалуйста, воздержитесь от одобрения или отказа от запроса, если вы не являетесь ключевым участником проекта Spring Framework.### Сборка из исходников
См. страницу вики Сборка из исходников для получения инструкций по получению, сборке и импорту исходного кода Spring Framework в вашу среду разработки.
Страницы вики Стили кода и Настройки редактора IntelliJ IDEA определяют стандарты оформления исходных файлов, которые мы используем, а также некоторые настраиваемые параметры редактора IDEA.
Справочные документы создаются в формате Asciidoctor с использованием Antora. Исходные файлы для документов находятся в директории framework-docs/modules/ROOT. Для незначительных изменений вы можете просматривать, редактировать исходные файлы и отправлять изменения прямо через GitHub.
При локальных изменениях выполните команду ./gradlew antora
, затем просмотрите результаты в файле framework-docs/build/site/index.html
.
Asciidoctor также поддерживает живое редактирование. Подробнее см. раздел Инструменты Asciidoc.
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )