1 files changed, 21 insertions, 11 deletions
diff --git a/documentation/content/ru/books/dev-model/_index.adoc b/documentation/content/ru/books/dev-model/_index.adoc
index a23147d91c..8fcc432bb5 100644
--- a/documentation/content/ru/books/dev-model/_index.adoc
+++ b/documentation/content/ru/books/dev-model/_index.adoc
@@ -77,7 +77,7 @@ toc::[]
 [.abstract-title]
 Предисловие
 
-До настоящего момента проект FreeBSD выпустил ряд описанных методик для выполнения различных частей работы. Однако, из-за растущего числа участников проекта, необходима модель проекта, обобщающая его структуру. footnote:[Это согласуется с законом Брукса, согласно которому добавление нового человека в задерживающийся проект сделает его ещё более задержанным, поскольку увеличит потребность в коммуникации. Модель проекта — это инструмент для снижения потребности в коммуникации.] Данная статья предоставляет такую модель проекта и передаётся в проект документации FreeBSD, где она может развиваться вместе с проектом, чтобы в любой момент времени отражать способ его работы. Она основана на [crossref:dev-model[диссертации, Saers,2003]].
+До настоящего момента проект FreeBSD выпустил ряд описанных методик для выполнения различных частей работы. Однако, из-за растущего числа участников проекта, необходима модель проекта, обобщающая его структуру. footnote:[Это согласуется с законом Брукса, согласно которому добавление нового человека в задерживающийся проект сделает его ещё более задержанным, поскольку увеличит потребность в коммуникации. Модель проекта — это инструмент для снижения потребности в коммуникации.] Данная статья предоставляет такую модель проекта и передаётся в проект документации FreeBSD, где она может развиваться вместе с проектом, чтобы в любой момент времени отражать способ его работы. Она основана на диссертации [crossref:dev-model[thesis, Saers,2003]].
 
 Я хотел бы поблагодарить следующих людей за то, что они нашли время объяснить мне непонятные моменты и проверить документ.
 
@@ -103,7 +103,7 @@ toc::[]
 
 Во время выборов в Core в 2002 году Марк Мюррей заявил: «Я против длинного свода правил, так как это удовлетворяет склонности к юриспруденции и противоречит техноцентричности, в которой проект так нуждается.» [crossref:dev-model[bsd-election2002, FreeBSD, 2002B]]. Эта модель проекта не предназначена для того, чтобы оправдывать создание ограничений для разработчиков, а служит инструментом для облегчения координации. Она призвана описывать проект, давая обзор того, как выполняются различные процессы. Это введение в то, как работает проект FreeBSD.
 
-Модель проекта FreeBSD будет описана по состоянию на 1 июля 2004 года. Она основана на работе Нильса Йоргенсена [crossref:dev-model[jorgensen2001, Jørгенсен, 2001]], официальных документах FreeBSD, обсуждениях в списках рассылки FreeBSD и интервью с разработчиками.
+Модель проекта FreeBSD будет описана по состоянию на 1 июля 2004 года. Она основана на работе Нильса Йоргенсена [crossref:dev-model[jorgensen2001, Jørgensen, 2001]], официальных документах FreeBSD, обсуждениях в списках рассылки FreeBSD и интервью с разработчиками.
 
 После определения используемых терминов в этом документе будет описана организационная структура (включая описания ролей и линии коммуникации), рассмотрена модель методологии, а после представления инструментов, используемых для контроля процессов, будут описаны определенные процессы. В заключение будут представлены основные подпроекты проекта FreeBSD.
 
@@ -276,7 +276,7 @@ toc::[]
 
 В дополнение к множеству людей, работающих над проектом, существует множество связанных проектов в рамках FreeBSD. Это могут быть проекты, разрабатывающие совершенно новые функции, подпроекты или проекты, результаты которых интегрируются в FreeBSD footnote:[Например, разработка стека Bluetooth начиналась как подпроект, пока не была признана достаточно стабильной для включения в ветку -CURRENT. Теперь это часть основной системы FreeBSD.]. Эти проекты вписываются в FreeBSD так же, как и обычные разработки: они создают код, который интегрируется с проектом FreeBSD. Однако некоторые из них (например, Ports и Documentation) имеют привилегию применяться к обеим веткам или коммитить напрямую как в -CURRENT, так и в -STABLE.
 
-Не существует стандартов по выполнению проектирования, также как и централизованного репозитория для хранения проектов. Основной дизайн взят из 4.4BSD. footnote:[По словам Кирка Маккузика, после 20 лет разработки операционных систем UNIX, интерфейсы в основном уже определены. Поэтому нет необходимости в большом количестве проектирования. Однако новые применения системы и новое оборудование приводят к тому, что некоторые реализации становятся более выгодными по сравнению с ранее предпочитаемыми. Одним из примеров является появление веб-браузинга, который превратил обычное TCP/IP-соединение в короткие всплески данных, а не в устойчивый поток за более длительный период времени.] Поскольку проектирование является частью этапа "Программирование" в модели Йоргенсена, каждый разработчик или подпроект сам решает, как это должно выполняться. Даже если проектирование должно храниться в централизованном репозитории, результаты этапов проектирования будут иметь ограниченную полезность, так как различия в методологиях сделают их плохо совместимыми, если вообще совместимыми. Для общего проектирования проекта, проект полагается на подпроекты, которые договариваются о совместимых интерфейсах между собой, а не на диктат интерфейсов.
+Не существует стандартов по выполнению проектирования, также как и централизованного репозитория для хранения проектов. Основной дизайн взят из 4.4BSD. footnote:[По словам Кирка МакКузика, после 20 лет разработки операционных систем UNIX, интерфейсы в основном уже определены. Поэтому нет необходимости в большом количестве проектирования. Однако новые применения системы и новое оборудование приводят к тому, что некоторые реализации становятся более выгодными по сравнению с ранее предпочитаемыми. Одним из примеров является появление веб-браузинга, который превратил обычное TCP/IP-соединение в короткие всплески данных, а не в устойчивый поток за более длительный период времени.] Поскольку проектирование является частью этапа "Программирование" в модели Йоргенсена, каждый разработчик или подпроект сам решает, как это должно выполняться. Даже если проектирование должно храниться в централизованном репозитории, результаты этапов проектирования будут иметь ограниченную полезность, так как различия в методологиях сделают их плохо совместимыми, если вообще совместимыми. Для общего проектирования проекта, проект полагается на подпроекты, которые договариваются о совместимых интерфейсах между собой, а не на диктат интерфейсов.
 
 [[release-branches]]
 === Ветви релизов
@@ -292,7 +292,7 @@ image::branches.png["Обратитесь к таблице ниже для уд
 [cols="1,1,1", options="header"]
 |===
 | Основные выпуски
-| Форкнут из
+| Форк сделан из
 | Следующие минорные выпуски
 
 |...
@@ -454,7 +454,7 @@ Postmaster отвечает за корректную доставку почт�
 [[role-webmaster]]
 ==== Управление веб-сайтом
 
-Роль управления веб-сайтом отвечает за координацию развертывания обновленных веб-страниц на зеркалах по всему миру, за общую структуру основного веб-сайта и систему, на которой он работает. Управление должно согласовывать содержимое с crossref:dev-model[документацией подпроекта, Документационный проект FreeBSD] и выступает в роли сопровождающего для дерева "www".
+Роль управления веб-сайтом отвечает за координацию развертывания обновленных веб-страниц на зеркалах по всему миру, за общую структуру основного веб-сайта и систему, на которой он работает. Управление должно согласовывать содержимое с crossref:dev-model[sub-project-documentation, Проектом документации FreeBSD] и выступает в роли сопровождающего для дерева "www".
 
 Роль поддерживается: веб-мастеры FreeBSD mailto:www@FreeBSD.org[www@FreeBSD.org].
 
@@ -553,7 +553,9 @@ image::proc-add-committer.png["Обратитесь к абзацу ниже д�
 
 Когда участник отправляет фрагмент кода, принимающий коммиттер может предложить предоставить этому участнику права на коммит. Если он рекомендует это основной команде (Core Team), команда проводит голосование по этой рекомендации. Если голосование завершается в пользу предложения, новому коммиттеру назначается наставник, и новый коммиттер должен отправить свои данные администраторам для создания учётной записи. После этого новый коммиттер готов сделать свой первый коммит. По традиции, это делается путём добавления своего имени в список коммиттеров.
 
-Recall that a committer is considered to be someone who has committed code during the past 12 months. However, it is not until after 18 months of inactivity have passed that commit privileges are eligible to be revoked. [crossref:dev-model[freebsd-expiration-policy, FreeBSD, 2002H]] There are, however, no automatic procedures for doing this. For reactions concerning commit privileges not triggered by time, see crossref:dev-model[process-reactions,section 1.5.8].
+Напомним, что коммиттером считается тот, кто за последние 12 месяцев внёс изменения в код. Однако право на коммиты может быть отозвано только после 18 месяцев неактивности.
+[crossref:dev-model[freebsd-expiration-policy, FreeBSD, 2002H]]
+Однако не существует автоматических процедур для этого. Для действий, связанных с привилегиями коммитов, не вызванных временем, см. crossref:dev-model[process-reactions,раздел 1.5.8].
 
 .Процесс: удаление коммиттера
 image::proc-rm-committer.png["Обратитесь к абзацу ниже для версии, совместимой с программами чтения с экрана."]
@@ -570,7 +572,9 @@ image::proc-rm-committer.png["Обратитесь к абзацу ниже дл
 . crossref:dev-model[role-maintainer, Сопровождение]
 . crossref:dev-model[role-mentor, Наставник (Mentor)]
 
-[crossref:dev-model[freebsd-bylaws, FreeBSD, 2000A]] [crossref:dev-model[freebsd-expiration-policy, FreeBSD, 2002H]] [crossref:dev-model[freebsd-new-account, FreeBSD, 2002I]]
+[crossref:dev-model[freebsd-bylaws, FreeBSD, 2000A]]
+[crossref:dev-model[freebsd-expiration-policy, FreeBSD, 2002H]]
+[crossref:dev-model[freebsd-new-account, FreeBSD, 2002I]]
 
 [[committing]]
 === Коммит кода
@@ -602,7 +606,8 @@ image::proc-contrib.png["Обратитесь к абзацам выше и ни
 . crossref:dev-model[role-vendor, Поставщик]
 . crossref:dev-model[role-reviewer, Рецензенты]
 
-[crossref:dev-model[freebsd-committer, FreeBSD, 2001]] [crossref:dev-model[jorgensen2001, Jørgensen, 2001]]
+[crossref:dev-model[freebsd-committer, FreeBSD, 2001]]
+[crossref:dev-model[jorgensen2001, Jørgensen, 2001]]
 
 [[process-core-election]]
 === Выборы основной команды (Core Team)
@@ -634,7 +639,9 @@ Core Team объявляет выборы и назначает руководи
 * crossref:dev-model[role-committer, Коммиттер]
 * crossref:dev-model[role-election-manager, Менеджер выборов]
 
-[crossref:dev-model[freebsd-bylaws, FreeBSD, 2000A]] [crossref:dev-model[bsd-election2002, FreeBSD, 2002B]] [crossref:dev-model[freebsd-election, FreeBSD, 2002G]]
+[crossref:dev-model[freebsd-bylaws, FreeBSD, 2000A]]
+[crossref:dev-model[bsd-election2002, FreeBSD, 2002B]]
+[crossref:dev-model[freebsd-election, FreeBSD, 2002G]]
 
 [[new-features]]
 === Разработка новых функций
@@ -714,7 +721,8 @@ image::proc-pr.png["Обратитесь к абзацу ниже для вер�
 . crossref:dev-model[role-maintainer, Сопровождение]
 . crossref:dev-model[role-bugbuster, Исправитель ошибок (Bugbuster)]
 
-[crossref:dev-model[freebsd-handle-pr, FreeBSD, 2002C]]. [crossref:dev-model[freebsd-send-pr, FreeBSD, 2002D]]
+[crossref:dev-model[freebsd-handle-pr, FreeBSD, 2002C]].
+[crossref:dev-model[freebsd-send-pr, FreeBSD, 2002D]]
 
 [[process-reactions]]
 === Реагирование на неправильное поведение
@@ -754,7 +762,9 @@ image::proc-pr.png["Обратитесь к абзацу ниже для вер�
 
 Версии ветки -CURRENT (то есть все версии, оканчивающиеся на ".0"), очень похожи, но с вдвое большим временным промежутком. Процесс начинается за 8 недель до выпуска с объявления графика релиза. Через две недели после начала процесса выпуска вводится заморозка функциональности, и оптимизация производительности должна быть сведена к минимуму. За четыре недели до выпуска становится доступна официальная бета-версия. За две недели до выпуска код официально ветвится в новую версию. Этой версии присваивается статус релиз-кандидата, и, как и в случае с разработкой -STABLE, заморозка кода релиз-кандидата ужесточается. Однако разработка на основной ветке разработки может продолжаться. За исключением этих различий, процессы разработки релизов схожи.
 
-*.0 releases go into their own branch and are aimed mainly at early adopters. The branch then goes through a period of stabilisation, and it is not until the crossref:dev-model[role-releng, Release Engineering Team] decides the demands to stability have been satisfied that the branch becomes -STABLE and -CURRENT targets the next major version. While this for the majority has been with *.1 versions, this is not a demand.
+*.0 выпуски выделяются в отдельную ветку и ориентированы в основном на ранних последователей.
+Затем ветка проходит период стабилизации, и только после того, как
+crossref:dev-model[role-releng, Команда разработки релизов] решит, что требования к стабильности выполнены, ветка становится -STABLE, а -CURRENT переключается на следующую мажорную версию. Хотя в большинстве случаев это происходило с версиями *.1, это не является обязательным требованием.
 
 Большинство выпусков происходит по достижении даты, которая считается достаточно отдалённой от предыдущего выпуска. Установлена цель выпускать основные версии каждые 18 месяцев, а промежуточные — каждые 4 месяца. Сообщество пользователей чётко дало понять, что безопасность и стабильность не могут быть принесены в жертву из-за самостоятельно установленных сроков и целевых дат выпуска. Чтобы задержки не становились слишком длинными в вопросах безопасности и стабильности, требуется дополнительная дисциплина при внесении изменений в -STABLE.