Implement review suggestions

1 files changed, 49 insertions, 43 deletions

diff --git a/contributors/guide/contributor-cheatsheet/README-uk.md b/contributors/guide/contributor-cheatsheet/README-uk.md
index 6c6b4b2b..09c22ae3 100644
--- a/contributors/guide/contributor-cheatsheet/README-uk.md
+++ b/contributors/guide/contributor-cheatsheet/README-uk.md
@@ -2,36 +2,37 @@
 
 [Deutsch](README-de.md) | [Français](README-fr.md) | [Bahasa Indonesia](README-id.md) | [日本語](README-ja.md) | [한국어](README-ko.md) | [Português](README-pt.md) | [中文](README-zh.md)
 
-Список загальних джерел для контриб'юторів Kubernetes, корисні поради, прийоми та найкращі практики, що застосовуються в Kubernetes. Це "TL;DR", або стислий довідник корисної інформації, що має на меті покращити ваш досвід контриб'ютора на GitHub.
+Список загальних джерел для контриб'юторів Kubernetes, корисні поради, прийоми та найкращі практики, що застосовуються у Kubernetes. Це "TL;DR", або стислий довідник корисної інформації, що має на меті покращити ваш досвід контриб'ютора на GitHub.
 
 **Зміст**
-- [Шпаргалка для контриб'юторів Kubernetes](#kubernetes-contributor-cheat-sheet)
-  - [Корисні джерела](#helpful-resources)
-    - [Початок роботи](#getting-started)
-    - [SIGs та інші групи](#sigs-and-other-groups)
-    - [Спільнота](#community)
-    - [Робочий процес](#workflow)
-    - [Тести](#tests)
-    - [Важливі поштові адреси](#important-email-aliases)
-    - [Інші корисні посилання](#other-useful-links)
-  - [Ефективне спілкування в GitHub](#communicating-effectively-on-github)
-    - [Як бути найкращими одне для одного](#how-to-be-excellent-to-each-other)
-      - [Приклади хорошого/поганого спілкування](#examples-of-goodbad-communication)
-  - [Внесок до проекту](#submitting-a-contribution)
-    - [Підписання CLA](#signing-the-cla)
-    - [Відкрити та відреагувати на Issue](#opening-and-responding-to-issues)
-      - [Створення Issue](#creating-an-issue)
-      - [Реакція на Issue](#responding-to-an-issue)
-    - [Відкрити Pull Request](#opening-a-pull-request)
-      - [Створення Pull Request](#creating-a-pull-request)
-      - [Приклад опису PR](#example-pr-description)
-      - [Усунення помилок у Pull Request](#troubleshooting-a-pull-request)
-    - [Мітки](#labels)
-  - [Робота локально](#working-locally)
-    - [Стратегія галуження](#branch-strategy)
-      - [Додання Upstream](#adding-upstream)
-      - [Синхронізація вашого відгалуження (fork)](#keeping-your-fork-in-sync)
-      - [Об’єднання комітів (squashing commits)](#squashing-commits)
+
+- [Шпаргалка для контриб'юторів Kubernetes](#шпаргалка-для-контрибюторів-kubernetes)
+  - [Корисні джерела](#корисні-джерела)
+    - [Початок роботи](#початок-роботи)
+    - [SIGs та інші групи](#sigs-та-інші-групи)
+    - [Спільнота](#спільнота)
+    - [Робочий процес](#робочий-процес)
+    - [Тести](#тести)
+    - [Важливі поштові адреси](#важливі-поштові-адреси)
+    - [Інші корисні посилання](#інші-корисні-посилання)
+  - [Ефективне спілкування в GitHub](#ефективне-спілкування-в-github)
+    - [Як бути найкращими одне для одного](#як-бути-найкращими-одне-для-одного)
+      - [Приклади хорошого/поганого спілкування](#приклади-хорошогопоганого-спілкування)
+  - [Внесок до проекту](#внесок-до-проекту)
+    - [Підписання CLA](#підписання-cla)
+    - [Відкрити та відреагувати на Issue](#відкрити-та-відреагувати-на-issue)
+      - [Створення Issue](#створення-issue)
+      - [Реакція на Issue](#реакція-на-issue)
+    - [Відкрити Pull Request](#відкрити-pull-request)
+      - [Створення Pull Request](#створення-pull-request)
+      - [Приклад опису PR](#приклад-опису-pr)
+      - [Усунення помилок у Pull Request](#усунення-помилок-у-pull-request)
+    - [Мітки](#мітки)
+  - [Робота локально](#робота-локально)
+    - [Стратегія галуження](#стратегія-галуження)
+      - [Додання Upstream](#додання-upstream)
+      - [Синхронізація вашого відгалуження (fork)](#синхронізація-вашого-відгалуження-fork)
+      - [Об’єднання комітів (squashing commits)](#обєднання-комітів-squashing-commits)
 
 ---
 
@@ -78,9 +79,9 @@
 - community@kubernetes.io - Написати листа комусь із команди спільноти (SIG Contributor
   Experience) щодо непорозумінь у спільноті.
 - conduct@kubernetes.io - Написати листа до Комітету з контролю поведінки в Kubernetes, приватна розсилка.
-- github@kubernetes.io - Надіслати приватного листа до [Адміністративної команди GitHub] з приводу дражливих питань.
+- github@kubernetes.io - Надіслати приватного листа до [Адміністративної команди GitHub] з приводу чутливих питань.
 - steering@kubernetes.io - Надіслати листа до комітету управління. Загальнодоступна адреса із публічним архівом.
-- steering-private@kubernetes.io - Надіслати листа до комітету управління у приватному порядку, з приводу дражливих питань.
+- steering-private@kubernetes.io - Надіслати листа до комітету управління у приватному порядку, з приводу чутливих питань.
 - social@cncf.io - Зв’язатися із командою соціальних мереж CNCF; блог, Twitter акаунт, решта соціальних сервісів.
 
 ### Інші корисні посилання
@@ -106,9 +107,9 @@
 
 Якщо ви відхиляєте PR, будь ласка, надайте інформативне та доброзичливе пояснення, чому запропоновані зміни не можуть бути об'єднані з основною гілкою (merged).
 
-🙂 “Я відхиляю цей PR тому, що ця функціональність не може підтримувати сценарій використання X. У запропонованій формі її краще реалізувати із інструментом Y. Дякую за вашу роботу.”
+🙂 “Я відхиляю цей PR тому, що ця функціональність не може підтримувати сценарій використання X. У запропонованій формі її краще реалізувати з інструментом Y. Дякую за вашу роботу.”
 
-😞 “Чому це не узгоджується із домовленостями щодо API? Це має бути зроблене в іншому місці!”
+😞 “Чому це не узгоджується з домовленостями щодо API? Це має бути зроблене в іншому місці!”
 
 ---
 
@@ -126,10 +127,10 @@ GitHub Issue є основним джерелом для відстеження
 [інструкцією із усунення несправностей], повідомте про проблему до [Stack Overflow] чи [Kubernetes форум].
 
 **Посилання:**
+
 - [Мітки]
 - [Команди Prow][commands]
 
-
 #### Створення Issue
 
 - Скористайтеся шаблоном issue, якщо такий є. Використання відповідного шаблона допоможе іншим учасникам, які відповідатимуть на ваш запит.
@@ -138,19 +139,20 @@ GitHub Issue є основним джерелом для відстеження
 - Проставте відповідні [мітки]. Якщо ви не впевнені, бот [k8s-ci-robot][prow]
   ([Kubernetes CI bot][prow]) відповість на ваш issue і запропонує мітки, необхідні для пріоритизації вашого питання.
 - Дотримуйтесь вибірковості, коли за допомогою [`/assign @<username>`][assign] або
-  [`/cc @<username>`][cc] залучаєте до роботи над вашим питанням інших осіб. Використання правильних міток є набагато ефективнішим для пріоритизації вашого     запиту, аніж залучення більшої кількості учасників.
+  [`/cc @<username>`][cc] залучаєте до роботи над вашим питанням інших осіб. Використання правильних міток є набагато ефективнішим для пріоритизації вашого запиту, аніж залучення більшої кількості учасників.
 
 #### Реакція на Issue
 
 - Якщо ви починаєте роботу над якимось запитом (issue), залиште про це коментар. Так інші учасники знатимуть, над чим ви працюєте, і не робитимуть подвійної роботи.
 - Якщо ви самостійно розв’язали якесь питання, залиште коментар по цьому запиту, а вже потім закривайте його.
-- Долучайте посилання на PR, інші запити (issues) чи будь-які інші наявні матеріали,     наприклад: _"ref: #1234"_. Доцільно зазначити, що роботи з даного питання вже велися деінде.
+- Долучайте посилання на PR, інші запити (issues) чи будь-які інші наявні матеріали, наприклад: _"ref: #1234"_. Доцільно зазначити, що роботи з даного питання вже велися деінде.
 
 ### Відкрити Pull Request
 
 Pull request (PR) є основним засобом, за допомогою якого відбувається додання коду, документації чи іншого доробку до Git-репозиторія.
 
 **Посилання:**
+
 - [Мітки]
 - [Команди Prow][commands]
 - [Процес pull request]
@@ -159,15 +161,15 @@ Pull request (PR) є основним засобом, за допомогою я
 #### Створення Pull Request
 
 - Дотримуйтесь рекомендацій, наведених у шаблоні pull request, якщо такий є. Це допоможе іншим учасникам, які відповідатимуть на ваш PR.
-- У випадку [незначних виправлень], як-от неробоче посилання, друкарська або     граматична помилка, перегляньте весь документ на предмет інших потенційних     помилок. Не відкривайте численних PR для невеликих виправлень у тому самому документі.
+- У випадку [незначних виправлень], як-от неробоче посилання, друкарська або граматична помилка, перегляньте весь документ на предмет інших потенційних помилок. Не відкривайте численних PR для невеликих виправлень у тому самому документі.
 - Посилайтеся на будь-які запити (issue), що стосуються вашого PR, або такі, які цей PR може вирішити.
 - Уникайте завеликої кількості змін в одному коміті. Натомість розбийте ваш PR на декілька невеликих, логічно зв’язаних комітів. Цим ви полегшите перевірку вашого PR.
 - Лишайте коментарі до свого PR щоразу, як вважаєте за потрібне пояснити щось детальніше.
 - Дотримуйтесь вибірковості, коли за допомогою [`/assign @<username>`][assign] залучаєте до роботи над вашим PR інших осіб. Надмірна кількість рецензентів не пришвидшить перевірки вашого PR.
 - Якщо ваш PR _"у роботі"_ (_"Work in progress"_), додайте до його назви префікс `[WIP]`
   або використайте команду [`/hold`][hold]. Наявність`[WIP]` або hold дозволить уникнути автоматичного злиття змін (merge).
-- Якщо ваш PR не перевірили, не потрібно закривати його і відкривати новий із тими  самими змінами. Зверніться до своїх рецензентів у коментарі, скориставшись `@<github username>`.
-- Якщо вашому PR не приділяється достатньої уваги, опублікуйте посилання на PR у     Slack-каналі `#pr-reviews` для того, щоб знайти додаткових рецензентів.
+- Якщо ваш PR не перевірили, не потрібно закривати його і відкривати новий із тими самими змінами. Зверніться до своїх рецензентів у коментарі, скориставшись `@<github username>`.
+- Якщо вашому PR не приділяється достатньої уваги, опублікуйте посилання на PR у Slack-каналі `#pr-reviews` для того, щоб знайти додаткових рецензентів.
 
 #### Приклад опису PR
 
@@ -183,12 +185,13 @@ Ref. #3064 #3097
 ```
 
 Що в цьому PR:
+
 - **Рядок 1** - Посилання на інші issue або PR (#3064 #3097).
 - **Рядок 2** - Стислий опис того, що було зроблено в PR.
 - **Рядок 4** - [Команда][commands]
   `/sig contributor-experience` визначає дотичну до PR [SIG][sigs].
 - **Рядок 5** - Команда [`/cc`][cc] визначає рецензентів, яких може зацікавити цей issue або PR.
-- **Рядок 6** - Команда [`/kind cleanup`][kind] додає [мітку][мітки], що     характеризує issue або PR як такий, що стосується чистки коду, процесу або технічного боргу.
+- **Рядок 6** - Команда [`/kind cleanup`][kind] додає [мітку][мітки], що характеризує issue або PR як такий, що стосується чистки коду, процесу або технічного боргу.
 - **Рядок 7** - Команда [`/area developer-guide`][kind] характеризує issue або PR як такий, що має відношення до керівництва для розробників.
 - **Рядок 8** - Команда [`/assign`][assign] визначає погоджувача (approver) PR.
   Погоджувач обирається ботом [k8s-ci-robot][prow] зі списку відповідальних осіб, що міститься у файлі [OWNERS]. Після перевірки PR вони додадуть до нього мітку
@@ -209,10 +212,12 @@ Ref. #3064 #3097
 Kubernetes використовує [мітки] для розподілу Issues та Pull Requests за категоріями та для визначення пріоритетності їх виконання. Використання відповідних міток сприятиме ефективній пріоритизації вашого issue чи PR.
 
 **Посилання:**
+
 - [Мітки]
 - [Команди Prow][commands]
 
 Часто використовувані мітки:
+
 - [`/sig <sig name>`][kind] Призначити [SIG][SIGs] відповідальною за issue чи PR.
 - [`/area <area name>`][kind] Віднести issue чи PR до певної
   [зони][мітки].
@@ -225,6 +230,7 @@ Kubernetes використовує [мітки] для розподілу Issue
 Перш ніж зробити PR, вам необхідно виконати певний рівень роботи локально. Якщо ви раніше не працювали із git, [git-посібник Atlassian] стане хорошою точкою для старту. Гарною альтернативою йому буде стенфордський багатомовний посібник [Git magic].
 
 **Посилання:**
+
 - [Git-посібник Atlassian]
 - [Git magic]
 - [Робочий процес у GitHub]
@@ -233,13 +239,13 @@ Kubernetes використовує [мітки] для розподілу Issue
 
 ### Стратегія галуження
 
-Проект Kubernetes використовує стандартний для GitHub робочий процес _"Fork and Pull"_ (створення відгалуження від проекту і отримання останніх змін із віддаленого репозиторія проекту).  У термінології git ваше особисте відгалуження називатиметься _"`origin`"_, а фактичний git-репозиторій проекту - _"`upstream`"_. Для того, щоб підтримувати синхронізацію вашої особистої гілки (`origin`) із гілкою проекту (`upstream`), налаштуйте конфігурацію у вашій локальній копії.
+Проект Kubernetes використовує стандартний для GitHub робочий процес _"Fork and Pull"_ (створення відгалуження від проекту і отримання останніх змін із віддаленого репозиторія проекту). У термінології git ваше особисте відгалуження називатиметься _"`origin`"_, а фактичний git-репозиторій проекту - _"`upstream`"_. Для того, щоб підтримувати синхронізацію вашої особистої гілки (`origin`) із гілкою проекту (`upstream`), налаштуйте конфігурацію у вашій локальній копії.
 
 #### Додання Upstream
 
 Додайте `upstream` як віддалений репозиторій і налаштуйте таким чином, щоб ви не могли відправити до нього зміни.
 
-```
+```bash
 # замініть <upstream git repo> на url upstream-репозиторія
 # наприклад:
 #  https://github.com/kubernetes/kubernetes.git
@@ -255,7 +261,7 @@ git remote set-url --push upstream no_push
 
 Отримайте останні зміни з основного репозиторія `upstream` і _"перебазуйте"_ їх у вашу локальну гілку `master`. Це синхронізує ваш локальний репозиторій із основним репозиторієм проекту (`upstream`). Відправте локальні зміни до своєї віддаленої мастер-гілки (`remote master`).
 
-```
+```bash
 git fetch upstream
 git checkout master
 git rebase upstream/master
@@ -264,7 +270,7 @@ git push
 
 Це - необхідний мінімум для створення нової гілки, у якій ви працюватимете над розробкою функціональності чи виправленням помилок.
 
-```
+```bash
 git checkout -b myfeature
 ```