docops-hq · ka1bi4 · Sep 27, 2020 · Sep 27, 2020
diff --git a/Publishing-doc/Manage-wiki-content.md b/Publishing-doc/Manage-wiki-content.md
@@ -44,7 +44,7 @@ Github имеет некоторые ограничения:
 - **открытый доступ в Интернете:** если документация должна быть приватной, GitHub вряд ли будет подходящим местом для хранения (однако, есть опция делать репозитории приватными);
 - **нет структуры:** Вики-страницы GitHub выдают пустую страницу и позволяют добавлять разделы. Но нет возможности делать какие-либо продвинутые стили или интерактивные функции.
 
-> Здесь речь именно о встроенной функции Wiki на GitHub, а не [GitHub Pages](https://pages.github.com/). Для стилизования
+> Здесь речь именно о встроенной функции Wiki на GitHub, а не [GitHub Pages](https://pages.github.com/). Для стилизации
  и автоматического создания контента можно использовать такие инструменты, как Jekyll.  Более подробно GitHub Pages рассмотрим в [руководстве по Jekyll](Jekyll-and-cloudCannon.md).
 
 <a name="install"></a>

diff --git a/Publishing-doc/Use-GitHub-Desktop.md b/Publishing-doc/Use-GitHub-Desktop.md
@@ -146,7 +146,7 @@
 <a name="manage"></a>
 ## Управление конфликтами слияния
 
-Предположим, мы внесли изменения в свою локальную копию файла в хранилище, а кто-то другой изменяет этот же файл, используя интерфейс браузера [GitHub.com](https://github.com/). Изменения противоречат друг другу. Что просходит?
+Предположим, мы внесли изменения в свою локальную копию файла в хранилище, а кто-то другой изменяет этот же файл, используя интерфейс браузера [GitHub.com](https://github.com/). Изменения противоречат друг другу. Что происходит?
 
 Когда нажимаем **Push origin** от клиента GitHub Desktop, увидим сообщение о том, что хранилище было обновлено с момента последнего извлечения:
 

diff --git a/conceptual-topics/assess-conceptual-content.md b/conceptual-topics/assess-conceptual-content.md
@@ -4,7 +4,7 @@
 
 ## 👨‍💻 Оценка концептуального контента 3 сайтов API документации
 
-1. Переходим к [Списку 100 сайтов API документации](../Publishing-doc/API-doc-sites-list.md) и выбираем 3 сайта для анализа. Можно взять сайты любимых инструментов или любимых компаний, или просто 3 рандомных сайта.
+1. Переходим к [Списку 100 сайтов API документации](../Publishing-doc/API-doc-sites-list.md) и выбираем 3 сайта для анализа. Можно взять сайты любимых инструментов или любимых компаний, или просто любые 3 сайта.
 
 2. Смотрим документацию и анализируем ее состав:
 

diff --git a/conceptual-topics/code-samples.md b/conceptual-topics/code-samples.md
@@ -224,7 +224,7 @@ REST API позволяет разработчикам использовать
 
 Документирование кода может быть одним из самых сложных аспектов документации. Часть проблемы заключается в том, что код не организован таким образом, что построчное (или блочное) описание не имеет смысл. Переменные часто определяются в первую очередь, вызываются функции, которые определены в другом месте, да и многие другие аспекты также являются нелинейными. Объясняя логику, можно обнаружить, что приходится прыгать по разным местам кода, не обязательно перемещаясь сверху вниз.
 
-> Для более глубокого понимания того, как документировать примеры кода, см. презентацию автра курса[ «Создание примеров кода для документации API / SDK»](https://idratherbewriting.com/2014/05/30/creating-code-samples-webinar-recording-slides-and-audio/).
+> Для более глубокого понимания того, как документировать примеры кода, см. презентацию автора курса[ «Создание примеров кода для документации API / SDK»](https://idratherbewriting.com/2014/05/30/creating-code-samples-webinar-recording-slides-and-audio/).
 
 <a name="activity"></a>
 ## 👨‍💻 Практическое занятие: примеры кода

diff --git a/introduction-rest-apis/workshop-activities.md b/introduction-rest-apis/workshop-activities.md
@@ -672,7 +672,8 @@ Stoplight автоматически генерирует схему JSON, со
 
 👨‍💻 **Оценка концептуального контента на 3 сайта API документации**
 
-1. Переходим к [Списку 100 сайтов API документации](../Publishing-doc/API-doc-sites-list.md) и выбираем 3 сайта для анализа. Можно взять сайты любимых инструментов или любимых компаний, или просто 3 рандомных сайта.
+
+1. Переходим к [Списку 100 сайтов API документации](..Publishing-doc/API-doc-sites-list.md) и выбираем 3 сайта для анализа. Можно взять сайты любимых инструментов или любимых компаний, или просто любых 3 сайта.
 
 2. Смотрим документацию и анализируем ее состав:
 

diff --git a/testing-api-doc/overview-testing.md b/testing-api-doc/overview-testing.md
@@ -15,7 +15,7 @@
 
 Когда начинаем настраивать тесты для своей документации, обычно мы взаимодействуем с группой обеспечения качества (QA, отдел тестирования). Разработчики  могут быть также полезны, но команда обеспечения качества уже имеет, предположительно, систему тестирования, обычно тестовый сервер, и тестовые случаи. «Тестовые случаи» - это различные сценарии, по которым продукт должен быть проверен.
 
-С командой тестирования стоит дружить и узнавать лучшие практики для тестирования сценариев, соответствующих документации. Как правило, эти люди могут помочь эффективно приступить к работе, и они будут рады видеть нового члена команды. Если тех.писатель обнаружит ошибки, он может переслать их в QA или зарегистрировать их самостоятельно в баг треккере группы.
+С командой тестирования стоит дружить и узнавать лучшие практики для тестирования сценариев, соответствующих документации. Как правило, эти люди могут помочь эффективно приступить к работе, и они будут рады видеть нового члена команды. Если тех.писатель обнаружит ошибки, он может переслать их в QA или зарегистрировать их самостоятельно в баг трекере группы.
 
 Если мы можем подключиться к набору тестов, которые команды QA используют для выполнения тестов, можно начать с задокументированных заданий. В хороших тестовых примерах обычно перечисляются шаги, необходимые для получения результата, и сценарии могут наводить на нужную документацию.
 

diff --git a/testing-api-doc/test-assumptions.md b/testing-api-doc/test-assumptions.md
@@ -106,7 +106,7 @@
 <a name="conclusion"></a>
 ## Заключение
 
-Независимо от того, насколько интенсивно это делаеть, нужно искать возможности проверять свои инструкции на реальной аудитории. Не нужно делать много тестов (даже профессионалы в области юзабилити говорят, что 4-5 испытуемых обычно достаточно для выявления 80% проблем), но попробовать выполнить некоторое пользовательское тестирование стоит. Если рассматривать [документы как код](../Publishing-doc/Doc-as-code-tools.md), то следует, что тестировать документы нужно точно так же, как тестируется код.
+Независимо от того, насколько интенсивно это делается, нужно искать возможности проверять свои инструкции на реальной аудитории. Не нужно делать много тестов (даже профессионалы в области юзабилити говорят, что 4-5 испытуемых обычно достаточно для выявления 80% проблем), но попробовать выполнить некоторое пользовательское тестирование стоит. Если рассматривать [документы как код](../Publishing-doc/Doc-as-code-tools.md), то следует, что тестировать документы нужно точно так же, как тестируется код.
 
 [🔙](test-instructions-yourself.md)