KIKIMR-22202 Changes in PR template and docs for contributors with requirements to PR description

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,18 +1,18 @@
-### Changelog entry <!-- a user-readable short description of changes introduced in this PR -->
+### Changelog entry <!-- a user-readable short description of the changes that goes to CHANGELOG.md and Release Notes -->
 
 ...
 
 ### Changelog category <!-- remove all except one -->
 
 * New feature
 * Experimental feature
-* Improvement
 * Performance improvement
+* User Interface
 * Bugfix 
 * Backward incompatible change
 * Documentation (changelog entry is not required)
 * Not for changelog (changelog entry is not required)
 
-### Additional information
+### Description <!-- (optional) description for those who read this PR -->
 
 ...

ydb/docs/ru/core/contributor/suggest-change.md

@@ -239,6 +239,93 @@ git push
 
 {% endlist %}
 
+### Заполните описание к Pull Request'у {#create_pr_desc}
+
+При создании Pull Request'а описание будет заполнено текстом из шаблона, который нужно отредактировать:
+
+1. **Changelog Entry.** В этот блок следует добавить описание изменения для конечных пользователей системы (см. [требования](#changelog_entry_req)). Содержимое этого блока будет опубликовано в [списке изменений](../changelog-server.md), если PR будет замержен.
+2. **Changelog Category.** В этом блоке нужно оставить одну категорию из списка, которой соответствует изменение (см. [как выбрать категорию](#choose_category)). Есть категории, для которых сообщения из Changelog Entry не будут опубликованы в списке изменений. Остальные категории определяют раздел списка изменений, в который попадет сообщение.
+3. **Description.** В этот блок можно добавить ссылку на задачу и любую дополнительную информацию, которую вы считаете полезной для ревью. Содержимое этого блока не попадет в список изменений.
+
+
+#### Требования к Changelog Entry {#changelog_entry_req}
+
+Сообщение в Changelog Entry должно отвечать следующим требованиям:
+
+- должно быть написано на английском языке,
+- содержать не менее 20 символов, если [выбранная категория](#choose_category) имеет раздел в списке изменений,
+- содержать термины, которые используются в [глоссарии](../concepts/glossary.md),
+- описывать, что в работе системы изменилось для конечного пользователя,
+- отвечать дополнительным требованиям, которые определяются выбранной категорией.
+
+
+#### Как выбрать Changelog Category {#choose_category}
+
+#|
+|| Категория | Раздел в списке изменений | Описание | Требования к сообщению ||
+|| Feature
+| Функциональность
+| Новая функциональность или изменения существующей функциональности. Иногда выпускается под флагом для сохранения совместимости.
+
+Если вы делаете больше одного PR'а в рамках задачи, то эту категорию нужно выбрать только для финального коммита, для промежуточных коммитов нужно выбирать Not for changelog.
+| Должно включать:
+
+  * ссылку на документацию (если описание больше пары предложений),
+  * описание, как включить функциональность, если она релизится под флагом (если описание больше одного предложения, тоже стоит вынести его в документацию).
+||
+|| Experimental feature
+| Функциональность с пометкой экспериментально
+| Новая функциональность или изменения существующей функциональности. Всегда выпускается под флагом для сохранения совместимости.
+
+Отличие от предыдущей категории в том, что даже после тестирования мы не сможем дать конечному пользователю гарантий, что система будет работать корректно с этим изменением.
+| Должно включать:
+
+  * ссылку на документацию (если описание больше пары предложений),
+  * описание, как включить функциональность, если она релизится под флагом (если описание больше одного предложения, тоже стоит вынести его в документацию).
+||
+|| Performance
+| Производительность
+| Изменения в производительности системы - ускорения, оптимизации, улучшения, которые привели к измеряемым изменения в производительности.
+| Должно отвечать на вопросы производительность какой части системы изменилась и насколько.
+||
+|| Bugfix
+| Исправления ошибок
+| Исправления ошибок, с которыми пользователь сталкивался или мог столкнуться в предыдущих релизных версиях.
+| Должно содержать:
+
+  * ссылку на задачу в GitHub,
+  * при каких условиях пользователь мог столкнуться с проблемой,
+  * как проблема проявлялась,
+  * как была исправлена (необязательно, если логика работы системы принципиально не изменилась).
+||
+|| User Interface
+| YDB UI
+| Любые изменения в YDB UI
+|
+||
+|| Backward incompatible changes
+| Изменения с потерей обратной совместимости
+| Изменения с потерей обратной совместимости с предыдущими релизными версиями.
+|
+||
+|| Documentation
+| -
+| Изменения в документации.
+| Не будет опубликовано в истории изменений. Сообщение заполнять не нужно.
+||
+|| Not for Changelog
+| -
+| Изменения, которые не видны конечному пользователю - рефакторинг кода, тесты, CI/CD, изменения CHANGELOG.md, исправления ошибок в коде новой функциональности (которая не попала в предыдущие релизные версии).
+| Не будет опубликовано в истории изменений. Сообщение заполнять не нужно.
+||
+|#
+
+{% note info %}
+
+Важно выбрать только одну категорию, поэтому не рекомендуется включать в один PR изменения из разных категорий, например, новую функциональность и исправление ошибки. Однако, если так случилось, следует выбрать категорию более важного для пользователя изменения, а в блок Changelog Entry добавить описание всех изменений.
+
+{% endnote %}
+
 ### Предварительные проверки {#precommit_checks}
 
 Перед мержем изменений выполняются прекоммитные проверки Pull Request'а.