Update suggest-change.md

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

@@ -261,31 +261,30 @@ git push
 
 #### Как выбрать Changelog Category
 
-{% note info %}
-
-Важно выбрать только одну категорию, поэтому не рекомендуется включать в один PR изменения из разных категорий, например, новую функциональность и исправление ошибки. Однако, если так случилось, следует выбрать категорию более важного для пользователя изменения, а в блок Changelog Entry добавить описание всех изменений.
-
-{% endnote %}
-
 #|
 || Категория | Раздел в списке изменений | Описание | Требования к сообщению ||
+|| Если изменение конечно и видно пользователю, используйте категории, для которых есть соответствующий блок в истории изменений:
+| <
+| <
+| <
+||
 || Feature
 | Функциональность
 | Новая функциональность или изменения существующей функциональности. Иногда выпускается под флагом для сохранения совместимости.
 
 Если вы делаете больше одного PR'а в рамках задачи, то эту категорию нужно выбрать только для финального коммита, для промежуточных коммитов нужно выбирать Not for changelog.
 | Должна включать:
-    - ссылку на документацию (если описание больше пары предложений),
-    - описание, как включить функциональность, если она релизится под флагом (если описание больше одного предложения, тоже стоит вынести его в документацию).
+    * ссылку на документацию (если описание больше пары предложений),
+    * описание, как включить функциональность, если она релизится под флагом (если описание больше одного предложения, тоже стоит вынести его в документацию).
 ||
 || Experimental feature
 | Функциональность с пометкой экспериментально
 | Новая функциональность или изменения существующей функциональности. Всегда выпускается под флагом для сохранения совместимости.
 
 Отличие от предыдущей категории в том, что даже после тестирования мы не сможем дать конечному пользователю гарантий, что система будет работать корректно с этим изменением.
 | Должна включать:
-    - ссылку на документацию (если описание больше пары предложений),
-    - описание, как включить функциональность, если она релизится под флагом (если описание больше одного предложения, тоже стоит вынести его в документацию).
+    * ссылку на документацию (если описание больше пары предложений),
+    * описание, как включить функциональность, если она релизится под флагом (если описание больше одного предложения, тоже стоит вынести его в документацию).
 ||
 || Performance
 | Производительность
@@ -295,30 +294,45 @@ git push
 || Bugfix
 | Исправления ошибок
 | Исправления ошибок, с которыми пользователь сталкивался или мог столкнуться в предыдущих релизных версиях.
-| Должно содержать ссылку на ISSUE в GitHub, где описано: при каких условиях пользователь мог столкнуться с проблемой, как проблема проявлялась, как была исправлена (необязательно, если логика работы системы принципиально не изменилась).
+| Должно содержать:
+    * ссылку на задачу в GitHub,
+    * при каких условиях пользователь мог столкнуться с проблемой,
+    * как проблема проявлялась,
+    * как была исправлена (необязательно, если логика работы системы принципиально не изменилась).
 ||
 || User Interface
 | YDB UI
 | Любые изменения в YDB UI
 |
 ||
-|| Backward incompatible change
+|| Backward incompatible changes
 | Изменения с потерей обратной совместимости
 | Изменения с потерей обратной совместимости с предыдущими релизными версиями.
 |
 ||
+|| Если ваше изменение не видно для конечного пользователя, используйте категории:
+| <
+| <
+| <
+||
 || Documentation
 | -
-| Изменения в документации. Не будет опубликовано в истории изменений.
-|
+| Изменения в документации. 
+| Не будет опубликовано в истории изменений. Сообщение заполнять не нужно.
 ||
 || Not for Changelog
 | -
-| Изменения, которые не видны конечному пользователю - рефакторинг кода, тесты, CI/CD, изменения CHANGELOG.md, исправления ошибок в коде новой функциональности (которая не попала в предыдущие релизные версии). Не будет опубликовано в истории изменений.
-|
+| Изменения, которые не видны конечному пользователю - рефакторинг кода, тесты, CI/CD, изменения CHANGELOG.md, исправления ошибок в коде новой функциональности (которая не попала в предыдущие релизные версии).
+| Не будет опубликовано в истории изменений. Сообщение заполнять не нужно.
 ||
 |#
 
+{% note info %}
+
+Важно выбрать только одну категорию, поэтому не рекомендуется включать в один PR изменения из разных категорий, например, новую функциональность и исправление ошибки. Однако, если так случилось, следует выбрать категорию более важного для пользователя изменения, а в блок Changelog Entry добавить описание всех изменений.
+
+{% endnote %}
+
 ### Предварительные проверки {#precommit_checks}
 
 Перед мержем изменений выполняются прекоммитные проверки Pull Request'а.