git: 0529d2fd98 - main - update translation of articles/problem-reports to Russian

The branch main has been updated by vladlen:

URL: https://cgit.FreeBSD.org/doc/commit/?id=0529d2fd9833e09cb7dffe79966b545e360946e7

commit 0529d2fd9833e09cb7dffe79966b545e360946e7
Author:     Vladlen Popolitov <vladlen@FreeBSD.org>
AuthorDate: 2025-09-20 10:08:39 +0000
Commit:     Vladlen Popolitov <vladlen@FreeBSD.org>
CommitDate: 2025-09-20 10:08:39 +0000

    update translation of articles/problem-reports to Russian
    
    Reviewed by: maxim (mentor)
    Approved by: maxim (mentor)
    Differential Revision: https://reviews.freebsd.org/D52023
---
 .../ru/articles/problem-reports/_index.adoc        |  248 +---
 .../content/ru/articles/problem-reports/_index.po  | 1433 ++++++++++++++++++++
 2 files changed, 1495 insertions(+), 186 deletions(-)

diff --git a/documentation/content/ru/articles/problem-reports/_index.adoc b/documentation/content/ru/articles/problem-reports/_index.adoc
index 307dc95049..47827186a6 100644
--- a/documentation/content/ru/articles/problem-reports/_index.adoc
+++ b/documentation/content/ru/articles/problem-reports/_index.adoc
@@ -1,9 +1,13 @@
 ---
-title: Составление сообщений о проблеме во FreeBSD
 authors:
-  - author: Dag-Erling Smørgrav
-  - author: Mark Linimon
-trademarks: ["freebsd", "ibm", "intel", "sparc", "sun", "general"]
+  - 
+    author: 'Dag-Erling Smørgrav'
+  - 
+    author: 'Mark Linimon'
+description: 'Как лучше сформулировать и отправить отчет о проблеме в проект FreeBSD'
+tags: ["formulate", "submit", "FreeBSD", "PR"]
+title: 'Составление сообщений о проблеме во FreeBSD'
+trademarks: ["freebsd", "ibm", "intel", "sun", "general"]
 ---
 
 = Составление сообщений о проблеме во FreeBSD
@@ -67,12 +71,8 @@ toc::[]
 Вот некоторые случаи, в которых может оказаться полезным отправить сообщение о чем-то, что не является ошибкой:
 
 * Уведомление об обновлении программного обеспечения, которое поддерживается сторонними разработчиками (в основном порты, но также и компоненты базовой системы, разрабатываемые сторонними организациями, такие, как BIND или различные утилиты GNU).
-+ 
-Для не поддерживаемых никем портов (переменная `MAINTAINER` содержит `ports@FreeBSD.org`), такие уведомления о обновлении будут замечены заинтересовавшимся коммиттером и вас могут попросить предоставить патч для обновления порта; предоставление патча до того, как вас попросят об этом сильно увеличит шансы того, что порт будет обновлён вовремя.
-+ 
-Если порт поддерживается, PR-ы, указывающие о появлении новых улучшенных (upstream) релизов обычно не очень полезны, так как они прибавляют много вспомогательной работы для коммиттеров, а мэйнтейнер наверняка уже знает о новой версии. Они уже наверняка работали с разработчиками над ней или они возможно тестируют её, чтобы убедиться в отсутствии регрессии и т.п.
-+ 
-В любом случае, следование процессу, описанному в extref:{porters-handbook}[Руководстве по созданию портов, port-upgrading] даст наилучшие результаты. (Также можно ознакомиться с статьей link:{contributing-ports}[Контрибуция в коллекцию портов FreeBSD].)
+* Для не поддерживаемых никем портов (переменная `MAINTAINER` содержит `ports@FreeBSD.org`), такие уведомления о обновлении будут замечены заинтересовавшимся коммиттером и вас могут попросить предоставить патч для обновления порта; предоставление патча до того, как вас попросят об этом сильно увеличит шансы того, что порт будет обновлён вовремя.
+* В любом случае, следование процессу, описанному в extref:{porters-handbook}upgrading[Руководстве по созданию портов] даст наилучшие результаты. (Также можно ознакомиться с статьей extref:{contributing}[Вклад в коллекцию портов FreeBSD, ports-contributing].)
 
 Ошибка, которую нельзя воспроизвести, вряд ли будет исправлена. Если ошибка возникла только единожды, и вы не можете ее воспроизвести, к тому же никто с ней больше не сталкивался, нет никаких шансов, что разработчики смогут ее воспроизвести или понять, что делается неправильно. Это не значит, что такого не случается, но это значит, что шансов у вашего сообщения дойти когда-либо до стадии исправления ошибки очень малы. Часто эти виды ошибок возникают из-за неудовлетворительной работы жёстких дисков, перегревшихся процессоров. Всегда, когда э�
 �о возможно вы должны отслеживать такие случаи перед посылкой сообщения об ошибке.
 
@@ -84,40 +84,41 @@ toc::[]
 
 Затем вы должны убедиться, действительно ли проблема существует. Существует всего несколько вещей, которые раздражают разработчика больше, чем получение сообщения об ошибке, которую он уже исправил.
 
-Если проблема в базовой системе, то вам нужно сначала прочесть раздел extref:{faq}[версии FreeBSD, LATEST-VERSION] из FAQ, если вы ещё не знакомы с данной темой. Для FreeBSD возможно исправлять проблемы только для некоторых недавних веток базовой системы, поэтому отправка сообщения об ошибке для более старой версии приведёт к тому, что разработчик посоветует вам обновиться до поддерживаемой версии, чтобы посмотреть присутствует ли в ней проблема. Команда офицеров безопасности поддерживает link:https://www.FreeBSD.org/security/[список поддерживаемых версий.].
+Если проблема в базовой системе, то вам нужно сначала прочесть раздел extref:{faq}[версии FreeBSD, latest-version] из FAQ, если вы ещё не знакомы с данной темой. Для FreeBSD возможно исправлять проблемы только для некоторых недавних веток базовой системы, поэтому отправка сообщения об ошибке для более старой версии приведёт к тому, что разработчик посоветует вам обновиться до поддерживаемой версии, чтобы посмотреть присутствует ли в ней проблема. Команда офицеров безопасности поддерживает link:https://www.FreeBSD.org/security/[список поддерживаемых версий.].
 
-Если проблема связана с портами, помните, что вы сначала должны обновиться до самой последней версии Коллекции Портов и проверить, существует ли в ней проблема. Из-за быстрых внесений изменений в эти приложения, неосуществимым для FreeBSD является поддержка чего-либо, кроме самых последних версий, и проблемы со устаревшими версиями приложений просто не могут быть исправлены.
+Если проблема в порте, рассмотрите возможность сообщить об ошибке разработчикам исходного проекта. Проект FreeBSD не может исправлять все ошибки во всём программном обеспечении.
 
 [[pr-prep]]
 == Подготовка
 
 Нужно следовать хорошему правилу всегда сначала выполнять дополнительные исследования перед тем, как послать сообщение о проблеме. Может быть, о вашей проблеме уже сообщено; может быть, она недавно обсуждалась или обсуждается в списках рассылки; она может быть уже исправлена в более новой версии, чем та, что вы используете. Поэтому вы должны проверить все обычные места до того, как послать ваше сообщение о проблеме. Для FreeBSD это значит:
 
-* FreeBSD extref:{faq}[FAQ] (Ответы на часто задаваемые вопросы). FAQ содержит ответы на вопросы из самых разных категорий, в частности, extref:{faq}[аппаратной совместимости, hardware], extref:{faq}[пользовательских программ, applications] и extref:{faq}[конфигурации ядра, kernelconfig].
-* extref:{handbook}[Списки рассылки]-если Вы не подписаны на них, воспользуйтесь http://www.FreeBSD.org/search/#mailinglists[поиском в архивах] на сайте FreeBSD. Если ваша проблема не обсуждалась в списках рассылки, вы можете попытаться опубликовать сообщение о ней и подождать несколько дней, пока кто-нибудь не сможет увидеть то, что вы не заметили.
+* Список extref:{faq}[Часто задаваемых вопросов] (FAQ) по FreeBSD. FAQ содержит ответы на широкий круг вопросов, таких как вопросы, касающиеся extref:{faq}[совместимости оборудования, hardware], extref:{faq}[пользовательских приложений, applications] и extref:{faq}[конфигурации ядра, kernelconfig].
+* extref:{handbook}eresources/[Списки рассылки, eresources-mail] — если Вы не подписаны на них, воспользуйтесь https://www.FreeBSD.org/search/#mailinglists[поиском в архивах] на сайте FreeBSD. Если ваша проблема не обсуждалась в списках рассылки, вы можете попытаться опубликовать сообщение о ней и подождать несколько дней, пока кто-нибудь не сможет увидеть то, что вы не заметили.
 * Как вариант, весь веб-используйте вашу любимую поисковую систему для поиска каких-либо ссылок по вашей проблеме. Вы можете даже увидеть ссылки на архивы списков рассылки или телеконференций, о которых вы не знали или не думали там искать.
-* Следующим пунктом должна быть http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query[ база данных PR FreeBSD] (GNATS). Если только ваша проблема не нова или редка, есть некоторый шанс, что о ней уже сообщено.
+* Следующим пунктом должна быть https://bugs.freebsd.org/bugzilla/query.cgi[ база данных PR FreeBSD] (Bugzilla). Если только ваша проблема не нова или редка, есть некоторый шанс, что о ней уже сообщено.
 * И самое важное, вы должны посмотреть не затрагивает ли документация в базовой системе вашу проблему.
-+ 
-Для основного кода FreeBSD вы должны тщательно изучить содержимое файла [.filename]#/usr/src/UPDATING# или его текущую версию по адресу http://svnweb.freebsd.org/base/head/UPDATING?view=log[http://svnweb.freebsd.org/base/head/UPDATING?view=log]. (Если вы переходите с одной версии на другую, особенно если вы обновляетесь до FreeBSD-CURRENT, то в этом файле вы можете найти много важной информации).
-+ 
-Если же ваша проблема связана с коллекцией портов FreeBSD, вы должны обратиться к файлу [.filename]#/usr/ports/UPDATING# (изменения, касающиеся индивидуальных портов) или к [.filename]#/usr/ports/CHANGES# (изменения, касающиеся всей коллекции портов). Они также доступны через интерфейс svnweb: http://svnweb.freebsd.org/ports/head/UPDATING?view=log[http://svnweb.freebsd.org/ports/head/UPDATING?view=log] и http://svnweb.freebsd.org/ports/head/CHANGES?view=log[http://svnweb.freebsd.org/ports/head/CHANGES?view=log].
++
+Для основного кода FreeBSD вы должны тщательно изучить содержимое файла [.filename]#/usr/src/UPDATING# или его текущую версию по адресу https://cgit.freebsd.org/src/tree/UPDATING[https://cgit.freebsd.org/src/tree/UPDATING]. (Если вы переходите с одной версии на другую, особенно если вы обновляетесь до FreeBSD-CURRENT, то в этом файле вы можете найти много важной информации).
++
+Если же ваша проблема связана с коллекцией портов FreeBSD, вы должны обратиться к файлу [.filename]#/usr/ports/UPDATING# (изменения, касающиеся индивидуальных портов) или к [.filename]#/usr/ports/CHANGES# (изменения, касающиеся всей коллекции портов). Они также доступны через интерфейс cgit: https://cgit.freebsd.org/ports/tree/UPDATING[https://cgit.freebsd.org/ports/tree/UPDATING] и https://cgit.freebsd.org/ports/tree/CHANGES[https://cgit.freebsd.org/ports/tree/CHANGES] .
 
 [[pr-writing]]
 == Написание сообщения о проблеме
 
 Теперь, после того, как вы решили, что ваш вопрос подпадает под категорию сообщения о проблеме, и это проблема FreeBSD, самое время написать собственно сообщение о проблеме (PR). Прежде чем мы углубимся в частности использования программы для создания и отправки PR, вот несколько советов, которые помогут вам сделать PR более эффективным.
 
+[[pr-writing-tips]]
 == Как писать хорошие сообщения о проблемах
 
-* Основным языком общения разработчиков FreeBSD является английский. База данных по проблемам также ведется на английском. Если вы испытываете проблемы с формулировкой описания проблемы по-английски, свяжитесь со своими соотечественниками, которые помогут вам составить PR.
-+
-* _Не оставляйте поле "Synopsis" (краткое описание) пустым._ Сообщения о проблемах попадают как в списки рассылки, которые затем расходятся по всему миру (в них поле "Synopsis" определяет тему письма), так и в базу данных. Просматривающий эту базу, как правило, пройдет мимо PR с пустым кратким описанием. Не забудьте, что PR остается в базе до тех пор, пока кто-либо не закроет его; сообщение-аноним, скорее всего, просто потеряется на общем фоне.
-* __Избегайте туманных описаний в поле "Synopsis"__. Не стоит предполагать, что читающий ваше сообщение владеет контекстом; поэтому, чем подробнее вы опишете ситуацию, тем лучше. В частности, к какой части системы относится ваша проблема? Проявляется ли она на этапе установки или во время нормальной работы? Например, вместо строки `Synopsis: portupgrade is broken` следовало бы написать что-то вроде `Synopsis: port ports-mgmt/portupgrade coredumps on -current`. В случае портированных приложений в поле "Synopsis" полезно указывать не только имя порта, но и категорию.
-* _Если у вас есть готовый патч, скажите об этом._ PR, содержащий патч, имеет куда больше шансов быть рассмотренным. В этом случае добавьте строку `[patch]` (включая квадратные скобки) в начало поля "Synopsis" (хотя использование именно этой формы необязательно, она является стандартом де-факто).
-* _Если вы отвечаете за исходные тексты, сообщите об этом._ Если вы отвечаете за часть исходных текстов (например, порт), вы можете добавить в начало поля "Synopsis" строку `[maintainer update]` (включая квадратные скобки), а также установить класс вашего PR (поле "Class") в `maintainer-update`. В этом случае коммиттеру, обрабатывающему ваш PR, не придётся лишний раз проверять.
+* _Не оставляйте поле "Summary" (краткое описание) пустым._ Сообщения о проблемах попадают как в списки рассылки, которые затем расходятся по всему миру (в них поле "Summary" определяет тему письма), так и в базу данных. Просматривающий эту базу, как правило, пройдет мимо PR с пустым кратким описанием. Не забудьте, что PR остается в базе до тех пор, пока кто-либо не закроет его; сообщение-аноним, скорее всего, просто потеряется на общем фоне.
+* __Избегайте туманных описаний в поле "Summary"__. Не стоит предполагать, что читающий ваше сообщение владеет контекстом; поэтому, чем подробнее вы опишете ситуацию, тем лучше. В частности, к какой части системы относится ваша проблема? Проявляется ли она на этапе установки или во время нормальной работы? Например, вместо строки `Summary: portupgrade is broken` следовало бы написать что-то вроде `Summary: port ports-mgmt/portupgrade coredumps on -current`. В случае портированных приложений в поле "Summary" полезно указывать не только имя порта, но и категорию.
+* _Если у вас есть патч, сообщите об этом._ Наличие патча значительно упрощает обработку отчёта.
+** Не используйте ключевые слова `patch` или `patch-ready` — они устарели.
+* _Если вы сопровождаете код, укажите это._ Если вы сопровождаете часть исходного кода (например, существующий порт), обязательно установите «Class» вашего PR в значение `maintainer-update`. Таким образом, любой коммиттер, обрабатывающий ваш PR, не будет вынужден проверять это.
 * _Будьте точны в формулировках._ Чем больше информации вы можете предоставить о проблеме, тем больше у вас шансов получить ответ.
-** Включите информацию о версии FreeBSD, которую вы используйте (существует специальное поле для его включения, смотрите ниже) и на какой архитектуре. Сообщите, используете ли вы release версию (установили с компакт-диска либо загрузили) или скачали её с помощью Subversion (и если так, то сообщите номер ревизии). Если вы используете FreeBSD-CURRENT, то первый вопрос, который вам могут задать, будет про номер ревизии, так как исправления для этой ветки (особенно в случае серьёзных проблем) имеют тенденцию появляться слишком быстро.
+
+** Включите версию FreeBSD, которую вы используете (для этого есть специальное поле, см. ниже), и архитектуру. Укажите, используете ли вы релиз (например, с CD-ROM или загруженный) или систему, поддерживаемую через Git (и, если да, укажите хэш и ветку). Если вы используете ветку FreeBSD-CURRENT, укажите это в первую очередь, так как исправления (особенно для известных проблем) часто добавляются очень быстро, и пользователи FreeBSD-CURRENT должны следить за обновлениями.
 ** Включите информацию о том, какие глобальные опции вы указали в [.filename]#make.conf#. На заметку: Объявление опций наподобие `-02` и других, описанных в man:gcc[1] во многих случаях может быть причиной ошибок. Хотя и разработчики FreeBSD будут принимать патчи, у них не будет желания исследовать такие случаи из-за отсутствия времени и добровольцев, и вместо этого они могут ответить, что это не поддерживается.
 ** Если проблему можно легко повторить, включите необходимую информацию, чтобы разработчик смог воспроизвести ее самостоятельно. Если проблема проявляется при некоторых вводимых данных, то, по возможности, приведите их вместе с получаемым и ожидаемым выводом. Если же вводимых данных много или же их нельзя разглашать, то попробуйте выделить из них лишь небольшой фрагмент, приводящий к возникновению проблемы, и включите его в PR.
 ** Если ваша проблема связана с ядром, будьте готовы предоставить следующую информацию (вам не обязательно включать её всю, она пойдёт лишь на заполнение базы данных, но вы должны включить информацию, которая по вашему мнению актуальна):
@@ -136,37 +137,24 @@ toc::[]
 *** Прочли ли вы [.filename]#ports/UPDATING#, и описана ли там ваша проблема (кто-нибудь спросит обязательно)
 
 * _Избегайте нечетких запросов о новых возможностях._ Сообщение типа "кто-то обязательно должен сделать так, чтобы такая-то утилита вела себя так-то" имеет куда меньше шансов встретить позитивный отклик, чем более четко сформулированный запрос. Помните, что исходные тексты доступны всем, так что если вам нужна реализация какого-то нового свойства, лучший способ- взяться за работу самому! Не забудьте также, что такие моменты лучше обсуждать в списках рассылки, таких как `freebsd-questions`, чем делать это посредством базы данных PR.
-* _Убедитесь, что ваша проблема еще никем не описана._ Мы уже говорили об этом, но стоит повториться. Потратьте пару минут на составление запросов к базе PR: http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query[http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query]. (Несмотря на повторы, об этом постоянно забывают)
+* _Убедитесь, что ваша проблема еще никем не описана._ Мы уже говорили об этом, но стоит повториться. Потратьте пару минут на составление запросов к базе PR: https://bugs.freebsd.org/bugzilla/query.cgi[https://bugs.freebsd.org/bugzilla/query.cgi]. (Несмотря на повторы, об этом постоянно забывают)
 * _Сообщайте об одной проблеме в одном PR._ Избегайте описания двух и более проблем в одном сообщении (исключением являются взаимосвязанные проблемы). Оформляя патчи, не пытайтесь в них добавлять множество функциональных возможностей или исправлять ими несколько ошибок в одном и том же сообщении о проблеме (опять же, за исключением взаимосвязанных проблем) - для таких PR-ов потребуется значительно больше времени на обработку.
-* _Избегайте полемики._ Если ваше сообщение касается области или способов реализации, которые ранее вызвали разногласия, вам стоит быть готовым предоставить не только патчи, но и внятные аргументы, почему следует поступать именно так (то есть, это "Правильный Путь"). Как отмечалось выше, аккуратный поиск по архиву списков рассылки http://www.FreeBSD.org/search/#mailinglists[http://www.FreeBSD.org/search#mailinglists] никогда не помешает.
+* _Избегайте полемики._ Если ваше сообщение касается области или способов реализации, которые ранее вызвали разногласия, вам стоит быть готовым предоставить не только патчи, но и внятные аргументы, почему следует поступать именно так (то есть, это "Правильный Путь"). Как отмечалось выше, аккуратный поиск по архиву списков рассылки https://www.FreeBSD.org/search/#mailinglists[https://www.FreeBSD.org/search/#mailinglists] никогда не помешает.
 * _Будьте вежливы._ Почти каждый из тех, кто может заниматься вашим сообщением, является добровольцем. Никому не понравятся указания, как и что делать, когда он и так занимается этим, да еще и по каким-либо причинам, отличным от финансовых. Вообще говоря, этого подхода следует придерживаться, имея дело с любым проектом с Открытыми Исходными текстами (Open Source).
 
+[[pr-writing-before-beginning]]
 == Прежде всего
 
-Если вы используйте утилиту man:send-pr[1] проверьте, что переменная вашего окружения `VISUAL` (или `EDITOR`, если `VISUAL` не задана) задана подходящим образом.
-
-Следует также проверить работоспособность системы электронной почты. Утилита man:send-pr[1] использует почтовую систему для отправки и отслеживания сообщения о проблеме. Если с машины, на которой вы запускаете man:send-pr[1], нельзя отправить почту, сообщение не попадёт в базу данных GNATS. О настройке электронной почты во FreeBSD можно прочитать в главе "Электронная почта" Руководства по FreeBSD по адресу extref:{handbook}mail[Electronic Mail, mail].
-
-Убедитесь, что ваш почтовый клиент не исказит сообщение по пути в GNATS. В частности, если ваш почтовый клиент автоматически переносит строки, изменяет символы табуляции на пробелы или предотвращает интерпретацию символов новой строки, любой патч, который вы пришлёте окажется непригодным. Для текста мы хотели бы, чтобы вы делали строчки размером примерно в 70 символов для читабельности PR на веб странице.
-
-Примерные соображения должны учитываться при отправке сообщения об ошибке через link:https://www.FreeBSD.org/send-pr/[веб-форму] вместо man:send-pr[1]. Помните, что операции копирования-вставки могут иметь сторонние эффекты в форматировании текста. В определённых случаях может быть необходимо использовать man:uuencode[1] для гарантии того, что патчи придут не изменёнными.
+Аналогичные соображения применимы к использованию https://bugs.freebsd.org/bugzilla/enter_bug.cgi[веб-формы для отправки PR]. Будьте осторожны с операциями копирования и вставки, которые могут изменить пробелы или другое форматирование текста.
 
-И наконец, если ваше сообщение будет объёмным, вы должны приготовить его в offline, чтобы ничего не потерялось в случае, если будет проблема при его отправке. Это особенно касается link:https://www.FreeBSD.org/send-pr/[веб-формы].
+И наконец, если ваше сообщение будет объёмным, вы должны приготовить его в offline, чтобы ничего не потерялось в случае, если будет проблема при его отправке.
 
+[[pr-writing-attaching-patches]]
 == Вложение патчей или файлов
 
-Нижеследующее применимо к передаче сообщения о проблеме посредством электронной почты:
+В общем, мы рекомендуем использовать `git format-patch` для создания одного или серии унифицированных diff-файлов относительно базовой ветки (например, `origin/main`). Патчи, созданные таким образом, будут содержать хеши Git, а также ваше имя и адрес электронной почты, что упростит применение вашего патча коммиттерами и правильное указание вас как автора (с помощью `git am`). Для небольших изменений, где вы предпочитаете не использовать git, убедитесь, что используете man:diff[1] с опцией `-u` для создания унифицированного diff-файла, так как это даст разработчикам больше 
 контекста и сделает его более читаемым по сравнению с другими форматами diff.
 
-Программа man:send-pr[1] предусматривает присоединение файлов к сообщению о проблеме. Вы можете вложить сколько угодно файлов, но каждый с уникальным именем (имеется в виду имя файла без маршрута). Просто используйте параметр командной строки `-a` для задания имен файлов, которые вы хотите присоединить:
-
-[source,shell]
-....
-% send-pr -a /var/run/dmesg -a /tmp/errors
-....
-
-Не беспокойтесь о бинарных файлах, они будут автоматически перекодированы для того, чтобы не повредить работе вашей почтовой программы.
-
-Если вы вкладываете патч, обязательно используйте параметр `-c` или `-u` вместе с командой man:diff[1] для создания контекстного или унифицированного diff-файла (унифицированный формат предпочтителен), и обязательно укажите точные номера SVN ревизий файлов, которые вы изменяли, чтобы разработчики, которые будут читать ваше сообщение, смогли легко его применить. Для проблем, связанных с ядром или с базовыми утилитами, предпочтительнее будет патч относительно ветки FreeBSD-CURRENT (или Subversion-ветки HEAD), так как весь новый код должен быть сначала протестирован 
 в ней. После завершения тестирования код будет интегрирован в ветвь FreeBSD-STABLE.
+Для проблем с ядром или базовыми утилитами предпочтителен патч для FreeBSD-CURRENT (основной ветки Git), поскольку весь новый код должен сначала применяться и тестироваться там. После проведения соответствующих или достаточных тестов код будет объединён/перенесён в ветку FreeBSD-STABLE.
 
 Если вы вставляете патч в тело сообщения, учтите, что некоторые почтовые программы имеют тенденцию заменять табуляции серией пробелов, что полностью разрушит, например, часть файла сборки (Makefile).
 
@@ -176,201 +164,89 @@ toc::[]
 
 Вы должны также помнить, что пока вы явно не укажете обратного в вашем сообщении о проблеме или в самих патчах, будет предполагаться, что они подпадают под те же условия лицензирования, что и оригинальный файл, измененный вами.
 
+[[pr-writing-filling-template]]
 == Заполнение шаблона
 
-Следующие несколько абзацев применимы только к способу подачи PR через электронную почту:
-
-После запуска утилиты man:send-pr[1] вам будет представлен шаблон сообщения о проблеме. Шаблон состоит из списка полей, некоторые из которых уже заполнены, а некоторые содержат комментарии, объясняющие назначение поля или перечисляющие подходящие значения. Не беспокойтесь о комментариях; они будут автоматически удалены, если вы их не изменяли (или удалите их сами).
-
-Вверху шаблона, ниже строк `SEND-PR:` находятся заголовки почтового сообщения. Вам обычно не нужно их изменять, если только вы не посылаете сообщение о проблеме с машины или от учетной записи, которая может посылать, но не может получать электронную почту, в случае чего вы можете задать в полях `From:` и `Reply-To:` ваши реальные адреса электронной почты. Вы можете также послать самому себе (или кому-то еще) копию сообщения о проблеме, добавив один или большее количество адресов к заголовку `Cc:`.
-
-В шаблоне вы найдете два однострочных поля:
-
-* _Submitter-Id:_ Не меняйте его. Значение по умолчанию `current-users` правильно, даже если вы используете FreeBSD-STABLE.
-* _Confidential:_ Предварительно заполнено как `no`, его изменение не имеет значения, так как нет такого понятия, как конфиденциальное сообщение о проблеме - база данных PR распространяется по всему миру.
-
-Далее описаны общие поля для почтового и link:https://www.FreeBSD.org/send-pr/[веб интерфейса]:
-
-* _Originator:_ Пожалуйста, укажите ваше реальное имя, за которым опционально следует адрес вашей электронной почты в угловых скобках. Обычно, man:send-pr[1] заполняет поле Originator содержимым поля `gecos` из учетной записи текущего пользователя.
-+
 [NOTE]
 ====
-Предоставленный вами адрес электронной почты станет публичной информацией и может стать доступным спамерам. Поэтому совсем не лишними будут меры по борьбе со спамом на вашей стороне, или же можно воспользоваться временным адресом электронной почты. Однако, если вы укажете несуществующий почтовый адрес, то у нас не будет возможности уточнять детали по вашему PR.
+Используемый вами адрес электронной почты станет общедоступной информацией и может попасть к спамерам. У вас должны быть процедуры обработки спама или следует использовать временный почтовый аккаунт. Однако учтите, что если вы вообще не используете действительный почтовый аккаунт, мы не сможем задать вам вопросы о вашем PR.
 ====
-* _Organization:_ Все, что вы захотите здесь указать. Это поле не содержит значительной информации.
-* _Synopsis:_ Заполняется кратким и точным описанием проблемы. Краткое описание используется в качестве темы сообщения электронной почты о проблеме, и используется при выдаче списков и выборках сообщений о проблемах; сообщения о проблемах с непонятными краткими описаниями чаще всего игнорируются.
-+ 
-Повторим: если к вашему сообщению о проблеме приложен патч, то, пожалуйста, начните краткое описание с `[patch]` (включая квадратные скобки); если PR принадлежит к категории ports и вы являетесь его мейнтейнером, то начните описание с `[maintainer update]` (включая квадратные скобки) и установите класс проблемы (поле "Class") в `maintainer-update`.
-* _Severity:_ Одно из `non-critical`, `serious` или `critical`. Не переусердствуйте; избегайте пометки вашей проблемы как `critical`, если только это не действительно критичная проблема (повреждение данных, существенная потеря функциональности в -CURRENT), или `serious`, если только это не касается многих пользователей (паники ядра, блокировки (freezes), проблемы с конкретными драйверами устройств или с системными утилитами). Разработчики FreeBSD не обязательно будут работать над вашей проблемой быстрее, если вы установите слишком высокий уровень важности, т.к. существует много др�
 �гих людей, которые сделали тоже самое - некоторые разработчики всё же уделят этому полю немного внимания и перейдут к следующему сообщению именно из-за этого поля.
+
+При подаче сообщения об ошибке вы увидите следующие поля:
+
+* _Краткое описание:_ Заполните это кратким и точным описанием проблемы. Краткое описание используется как тема письма с отчётом о проблеме, а также в списках и сводках отчётов; отчёты с неясными описаниями часто остаются без внимания.
+* _Серьезность:_ Одно из значений: `Затрагивает только меня (Affects only me)`, `Затрагивает некоторых людей (Affects some people)` или `Затрагивает многих людей (Affects many people)`. Не переоценивайте проблему; избегайте отмечать её как `Затрагивает многих людей`, если это не так. Разработчики FreeBSD не обязательно будут работать над вашей проблемой быстрее, если вы преувеличите её важность, поскольку многие другие уже поступали точно так же.
+* _Категория:_ Выберите подходящую категорию.
 +
-[NOTE]
-====
-Большинство проблем с безопасностью _не_ следует отправлять в GNATS, потому что вся эта информация становится публичной. Пожалуйста, направляйте подобные отчеты на электронный адрес `{security-officer}`.
-====
-* _Priority:_ Одно из `low`, `medium` или `high`. `high` должен использоваться для проблем, которые затронут конкретно каждого пользователя FreeBSD, а `medium` для чего-то, что затронет многих пользователей.
+Первое, что вам нужно сделать, — это определить, в какой части системы находится ваша проблема. Помните, что FreeBSD — это полноценная операционная система, которая включает в себя ядро, стандартные библиотеки, множество драйверов периферийных устройств и большое количество утилит («базовая система»). Однако в Коллекции портов доступны тысячи дополнительных приложений. Сначала вам нужно выяснить, связана ли проблема с базовой системой или с чем-то, установленным через Коллекцию портов.
 +
-[NOTE]
-====
-Ввиду массовых злоупотреблений это поле потеряло свое значение.
-====
-* _Category:_ Выберите соответствующую категорию.
-+ 
-Первым делом необходимо решить, к какой части системы относится ваша проблема. Помните: FreeBSD - завершенная операционная система, которая устанавливает ядро, стандартные библиотеки, множество драйверов периферийного оборудования, а также - большой набор системных утилит ("базовая система"). В дополнение к этому, в коллекции портов имеются тысячи приложений. Следовательно, определитесь: обнаруженная вами проблема находится в базовой системе или в чем-то, установленным через коллекцию портов.
-+ 
 Вот описание основных категорий:
 
 ** Если проблема в ядре, в библиотеках (таких как стандартная библиотека С `libc`) или в драйвере из базовой системы, то используйте категорию `kern`. (Есть несколько исключений, описанных ниже). В общем, это всё, что описано в разделах 2, 3 или 4 справочника.
 ** Если проблема с бинарной программой, например с man:sh[1] или man:mount[8], то вам прежде всего необходимо определить принадлежность программы к базовой системе или к установке из коллекции портов. Если вы не уверены, выполните команду `whereis _имя программы_`. В FreeBSD для коллекции портов существует договоренность: установка ведется в [.filename]#/usr/local#, однако это может быть переопределено системным администратором. Для таких программ следует использовать категорию `ports` (даже если категория порта `www`; см. ниже). Если программа располагается в [.filename]#/bin#, [.file
 name]#/usr/bin#, [.filename]#/sbin# или в [.filename]#/usr/sbin#, то это часть базовой системы, и вам следует использовать категорию `bin`. (Несколько программ, например man:gcc[1], на самом деле используют категорию `gnu`, но не беспокойтесь об этом сейчас.) Программы этой категории описаны в разделах 1 и 8 справочной системы.
 ** Если вы уверены, что в стартовых скриптах `(rc)` или в каком-то ином неисполняемом конфигурационном файле присутствует ошибка, тогда верной категорией будет `conf` (configuration). Эти сущности описываются в разделе 5 справочной системы.
 ** Если вы нашли проблему в наборе документации (статьи, книги, страницы справочной системы), правильным выбором будет `docs`.
-** Если вы наблюдаете проблему на страницах http://www.FreeBSD.org[сайта FreeBSD], то правильным выбором будет `www`.
 +
 [NOTE]
 ====
-Если проблема с чем-то из порта, называемого `www/_someportname_`, то она все же принадлежит к категории `ports`.
+Если проблема с чем-то из порта, называемого `www/_имяпорта_`, то она все же принадлежит к категории `ports`.
 ====
-+ 
++
 Далее представлены более специализированные категории.
 
 ** Если проблема принадлежит к `kern`, но в то же время имеет дело с подсистемой USB, то правильным выбором будет `usb`.
 ** Если проблема принадлежит к `kern` и найдена в потоковых библиотеках, правильным выбором будет `threads`.
 ** Если проблема принадлежит к базовой системе и касается соблюдения стандартов, таких как POSIX(R), правильным выбором будет `standards`.
-** Если проблема связана с ошибками внутри Java Virtual Machine(TM) (JVM(TM)), даже если Java(TM) была установлена из коллекции портов, вам следует выбрать категорию `java`. Более общие проблемы с портами Java(TM) попадают под категорию `ports`.
-+ 
-Далее перечислены остальные категории.
-
-** Если вы уверены, что проблема проявляется только на используемой вами процессорной архитектуре, выберите одну из архитектурно-специфичных категорий: это `i386` для Intel-совместимых машин в 32-битном режиме; `amd64` для AMD машин в 64-битном режиме (сюда также входят Intel-совместимые машины работающие в режиме EMT64); и менее распространенные `arm`, `ia64`, `powerpc` и `sparc64`.
+** Если вы уверены, что проблема возникнет только на используемой вами архитектуре процессора, выберите одну из архитектурно-зависимых категорий: обычно `i386` для Intel-совместимых машин в 32-битном режиме; `amd64` для машин AMD, работающих в 64-битном режиме (это также включает Intel-совместимые машины, работающие в режиме EMT64); и реже `arm` или `powerpc`.
 +
 [NOTE]
 ====
 Люди часто ошибаются в выборе категории. Если вы не уверены в правильности выбора, то лучше не гадать, а выбрать `misc`.
 ====
 +
-.Правильное использование категории
+.Правильное использование архитектурно-зависимых категорий
 [example]
 ====
-
 У вас простой ПК, и вы подозреваете, что столкнулись с проблемой, специфичной для конкретного чипсета или материнской платы: верная категория - `i386`.
 ====
 +
-.Неправильное использование категории
+.Некорректное использование категории, зависящей от архитектуры
 [example]
 ====
-
 Если вы наблюдаете проблему с периферийной картой расширения на распространенной шине или неполадки с конкретного типа жестким диском: в этом случае возможно, что неисправность наблюдается на более чем одной архитектуре, и верным выбором будет `kern`.
 ====
 ** Если вы не знаете в чем проблема (или вам кажется, что описание не попадает ни под какую из вышеобозначенных), используйте категорию `misc`. Перед тем, как написать PR, можно для начала спросить помощи в {freebsd-questions}. Возможно, там вам подскажут, какую из существующих категорий следует выбрать.
-+ 
-Вот текущий перечень категорий (взят из http://svnweb.freebsd.org/base/head/gnu/usr.bin/send-pr/categories[http://svnweb.freebsd.org/base/head/gnu/usr.bin/send-pr/categories]):
-
-** `advocacy:` проблемы, связанные с общественным мнением о FreeBSD. Вышло из употребления.
-** `amd64:` проблемы, специфичные для платформы AMD64.
-** `arm:` проблемы, специфичные для платформы ARM.
-** `bin:` проблемы с пользовательскими программами из базовой системы.
-** `conf:` проблемы с файлами настройки, используемыми по умолчанию значениями и прочее.
-** `docs:` проблемы со страницами справочной системы или онлайновой документацией.
-** `gnu:` проблемы с портированным программным обеспечением GNU, таким как man:gcc[1] или man:grep[1].
-** `i386:` проблемы, специфичные для платформы i386(TM).
-** `ia64:` проблемы, специфичные для платформы ia64.
-** `java:` проблемы, связанные с виртуальной машиной Java(TM).
-** `kern:` проблемы с ядром или с библиотеками в базовой системе, или с драйверами устройств, не связанными с какой-либо конкретной платформой.
-** `misc:` все, что не подпадает ни под какую другую категорию. (Надо отметить, что нет почти ничего, чтобы действительно соответствовало этой категории, за исключением проблем с релизами и с инфраструктурой сборки. Временные отказы при построении ветки `HEAD` не принадлежат к данной категории. Также надо отметить, что проблемы этой категории имеют тенденцию теряться легче всего).
-** `ports:` проблемы, связанные с коллекцией портов.
-** `powerpc:` проблемы, специфичные для платформы PowerPC(R).
-** `sparc64:` проблемы, специфичные для платформы Sparc64(R).
-** `standards:` проблемы, связанные с соответствием стандартам.
-** `threads:` проблемы, касающиеся реализации тредов во FreeBSD (особенно во FreeBSD-CURRENT).
-** `usb:` проблемы, относящиеся к реализации USB во FreeBSD.
-** `www:` изменения или улучшения сайта FreeBSD
-
-* _Class:_ Выберите одно из следующего:
-
-** `sw-bug:` ошибки в программном обеспечении.
-** `doc-bug:` ошибки в документации.
-** `change-request:` запросы на расширение функций или изменение в существующих.
-** `update:` обновления портов или другого программного обеспечения сторонних разработчиков.
-** `maintainer-update:` обновления в портах, для которых вы являетесь ответственной персоной.
-
-* _Release:_ Используемая вами версия FreeBSD. Оно заполняется автоматически программой man:send-pr[1] и требует изменения, если только вы отсылаете сообщение о проблеме с системы, отличающейся от той, где вы столкнулись с проблемой.
-
-И наконец, последовательность многострочных полей:
-
 * _Environment:_ Оно должно максимально точно описывать окружение, в котором встречается проблема. Сюда включается версия операционной системы, версия конкретной программы или файла, содержащего проблему, и любая другая информация, такая, как конфигурация системы, другое программное обеспечение, которое влияет на проблему, и так далее-просто все, что разработчик должен знать для создания условий появления проблемы.
-* _Description:_ Полное и точное описание проблемы, с которой вы столкнулись. Попытайтесь избежать своих предположений о причинах проблемы, если только вы не уверены, что правы, так как вы можете привести разработчика к неправильным предположениям о проблеме.
-* _How-To-Repeat:_ Последовательность действий, которые должны быть выполнены для повторения проблемы.
-* _Fix:_ Предпочтителен патч, или по крайней мере обходной путь (который не только поможет другим людям обойти ту же самую проблему, но также поможет разработчику понять ее причины), однако если у вас нет никаких здравых идей, то лучше оставить это поле пустым, чем строит догадки.
-
-== Отправка сообщения о проблеме
-
-Если вы используете man:send-pr[1]:
-
-Как только вы заполните шаблон, сохраните его и выйдете из редактора, man:send-pr[1] запросит вас `s)end, e)dit or a)bort?`. Вы можете нажать `s` для продолжения и отправки сообщения о проблеме, `e` для повторного запуска редактора и выполнения дальнейших изменений, или `a` для отказа от вашего сообщения. Если вы выберете последнее, то ваше сообщение о проблеме останется на диске (man:send-pr[1] укажет вам имя файла перед завершением работы), так что вы сможете отредактировать его на свой вкус или передать в систему с лучшим подключением к сети, перед тем, как послать ег�
 � при помощи параметра `-F` программы man:send-pr[1]:
-
-[source,shell]
-....
-% send-pr -f ~/my-problem-report
-....
-
-При этом будет прочитан указанный файл, будет проверено содержимое, убраны комментарии и сообщение будет отослано.
-
-Если вы используете link:https://www.FreeBSD.org/send-pr/[веб форму]:
-
-Перед нажатием `submit` вам потребуется заполнить проверочное поле текстом, представленным на картинке рядом. Эта непопулярная мера была принята в связи со злоупотреблениями со стороны роботов и некоторых неверно сориентированных индивидуумов. Это необходимая мера, которая никому не нравится, и, пожалуйста, не просите нас убрать её.
-
-Отметим, что вам `настоятельно рекомендуется` сохранить вашу работу (PR) куда-нибудь перед нажатием кнопки `submit`. Распространенная пользовательская ошибка: отображение браузером устаревшей проверочной картинки из его кэша. Если это произойдет в вашем случае, ваше сообщение будет отвергнуто и ваши труды пропадут.
-
-Если по какой-либо причине вы не имеете возможности видеть проверочную картинку, а также не можете воспользоваться man:send-pr[1], пожалуйста примите наши извинения за неудобства и пришлите ваш PR электронной почтой команде mailto:freebsd-bugbusters@FreeBSD.org[freebsd-bugbusters@FreeBSD.org].
+* _Описание:_ Полное и точное описание проблемы, с которой вы столкнулись. Старайтесь избегать предположений о причинах проблемы, если не уверены в своей правоте, так как это может ввести разработчика в заблуждение и привести к неверным выводам. В описании должны быть указаны действия, необходимые для воспроизведения проблемы. Если вам известен обходной путь, укажите его. Это не только поможет другим людям с той же проблемой временно её решить, но и может помочь разработчику понять причину возникновения проблемы.
 
 [[pr-followup]]
 == Отслеживание
 
 После того, как ваше сообщение будет принято, вы получите по электронной почте уведомление, в котором будет указан номер для отслеживания, который был назначен вашему сообщению о проблеме и URL, который вы можете использовать для проверки его состояния. В случае удачи кто-нибудь проявит интерес к вашей проблеме и попытается ее решить, или, как это бывает, описать, почему это не является проблемой. Вы будете автоматически оповещаться о любом изменении состояния и получать копии всех комментариев или патчей, которые будут присоединяться в про
 цессе отработки вашего сообщения о проблеме.
 
-Если кто-то запросит дополнительную информацию от вас, или вы вспомните или обнаружите нечто, что не указали в начальном сообщении, пожалуйста пошлите ваше дополнение (отклик) с помощью одного из этих способов:
+Если кто-то запросит у вас дополнительную информацию, или вы вспомните или обнаружите что-то, что не упомянули в первоначальном отчёте, пожалуйста, отправьте уточнение. Основная причина, по которой ошибка не исправляется, — это отсутствие связи с автором отчёта. Проще всего воспользоваться опцией комментария на веб-странице конкретного PR, которую можно открыть с https://bugs.freebsd.org/bugzilla/query.cgi[страницы поиска PR].
 
-* Самый простой путь это использовать соответствующую ссылку (followup) на индивидуальной веб страничке сообщения об ошибки, к которой можно перейти, используя http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query[страничку поиска PR]. Кликнув на этой ссылке откроется окно для отправки email с уже корректно заполненными полями To: и Subject: (если ваш браузер сконфигурирован для этого).
-* Или просто пошлите письмо на адрес {bugfollowup}, включив отслеживаемый номер в теме письма, чтобы система отслеживания сообщений могла знать, к какому сообщению о проблеме его присоединить.
-+
-[NOTE]
-====
-Если вы _не_ включите отслеживаемый номер, GNATS растеряется и создаст совершенно новое PR, которое будет закреплено за администратором GNATS. В результате ваш отклик затеряется до тех пор пока кто-нибудь не начнёт разгребать скопившийся мусор, что может произойти спустя дни или даже недели.
+Если проблема исчезла, но отчёт о ней остаётся открытым, просто добавьте комментарий с указанием, что отчёт можно закрыть, и, по возможности, объясните, как или когда проблема была устранена.
 
-Неправильно:
+Иногда возникает задержка в одну-две недели, когда отчёт о проблеме остаётся без внимания — никто не назначается на него и не оставляет комментариев. Такое может произойти при увеличении очереди отчётов о проблемах или во время праздничного сезона. Если отчёт о проблеме не получил внимания в течение нескольких недель, стоит найти коммиттера, особенно заинтересованного в работе над ним.
 
-[.programlisting]
-....
-Subject: that PR I sent
-....
+Существует несколько способов сделать это, желательно в следующем порядке, с перерывом в несколько дней между попытками использования каждого канала связи:
 
-Правильно:
-
-[.programlisting]
-....
-Subject: Re: ports/12345: compilation problem with foo/bar
-....
-
-====
+* Отправить письмо по электронной почте в extref:{handbook}eresources/[соответствующий список, eresources-summary] для получения комментариев к отчету.
+* Присоединитесь к соответствующим IRC-каналам. Частичный список доступен здесь: https://wiki.freebsd.org/IRC/Channels[]. Сообщите участникам канала о проблеме и запросите помощь. Будьте терпеливы и оставайтесь в канале после отправки сообщения, чтобы у людей из разных часовых поясов была возможность отреагировать.
+* Найдите коммиттеров, заинтересованных в сообщенной проблеме. Если проблема касается конкретного инструмента, бинарного файла, порта, документа или исходного файла, проверьте https://cgit.FreeBSD.org[Git Repository]. Определите последних коммиттеров, внесших существенные изменения в файл, и попытайтесь связаться с ними через IRC или электронную почту. Список коммиттеров и их адреса электронной почты можно найти в статье extref:{contributors}[Участники проекта FreeBSD].
 
-Если сообщение о проблеме остается открытым после того, как проблема была решена, просто отправьте сообщение (так, как это описано выше), с указанием, что сообщение о проблеме может быть закрыто, и если это возможно, объясните, как и когда проблема была устранена.
+Помните, что эти люди — добровольцы, как и сопровождающие и пользователи, поэтому они могут быть не сразу доступны для помощи с отчётом о проблеме. Терпение и последовательность в дальнейших действиях крайне рекомендуются и ценятся. При достаточном внимании и усилиях, посвящённых этому процессу, найти коммиттера, который займётся отчётом о проблеме — лишь вопрос времени.
 
 [[pr-problems]]
-== Проблемы взаимодействия с GNATS
-
-Большинство PR проходят сквозь систему и принимаются быстро; однако, во время загруженности GNATS, подтверждение на ваше сообщение о проблеме может задержаться на 10 и более минут. Пожалуйста, сохраняйте спокойствие.
-
-Помимо всего прочего, так как GNATS получает все данные через электронную почту, становится понятным, почему FreeBSD пропускает все сообщения через спамфильтры. Если подтверждение не приходит на протяжении часа-двух, то, возможно, что ваше сообщение попало под них; если так, то, пожалуйста, свяжитесь с администраторами GNATS по адресу mailto:bugmeister@FreeBSD.org[bugmeister@FreeBSD.org] и попросите помощи.
-
-[NOTE]
-====
-Среди антиспам мер есть одна, которая сопоставляет сообщения с множеством злоупотреблений, наблюдаемых в электронной почте с HTML-форматированием текста (однако, сюда не относится простое включение HTML в PR). Мы настоятельно рекомендуем не использовать HTML-форматированный текст при посылке PR: не только из-за вероятности попадания в спамфильтры, но и из-за загромождения базы данных. Отдайте предпочтение простому старому текстовому формату.
-====
+== Если возникли проблемы
 
-В редких случаях вы можете столкнуться с ошибкой GNATS, когда PR принят и ему присвоен номер, но он не отображается в списках PR ни на одной из страниц веб поиска PR. Вероятно, что рассинхронизировался индекс базы с самой базой. Этот случай можно проверить, обратившись к страничке http://www.FreeBSD.org/cgi/query-pr.cgi[Query PR Database] и проконтролировав наличие вашего PR. Если он есть, пожалуйста, известите администраторов GNATS (mailto:bugmeister@FreeBSD.org[bugmeister@FreeBSD.org]). Следует отметить, что перестройка базы выполняется периодически по `cron`, и если вам не к спеху, то не предпринимайте
  никаких шагов.
+Если вы обнаружили проблему в системе отслеживания ошибок, сообщите об ошибке! Для этого существует специальная категория. Если у вас не получается это сделать, свяжитесь с ответственными за обработку ошибок по адресу mailto:bugmeister@FreeBSD.org[bugmeister@FreeBSD.org].
 
 [[pr-further]]
-== Дополнительная литература
+== Для дальнейшего ознакомления
 
 Это список информационных ресурсов, относящихся к правильному написанию и обработке сообщений о проблемах. Он, без сомнения, не полон.
 
-* http://www.chiark.greenend.org.uk/~sgtatham/bugs.html[How to Report Bugs Effectively]-прекрасное эссе, которое написал Simon G. Tatham о составлении полезных (не специфичных для FreeBSD) сообщений о проблемах.
+* https://github.com/smileytechguy/reporting-bugs-effectively/blob/master/ENGLISH.md[How to Report Bugs Effectively]-прекрасное эссе, которое написал Simon G. Tatham о составлении полезных (не специфичных для FreeBSD) сообщений о проблемах.
 * extref:{pr-guidelines}[Problem Report Handling Guidelines]-интересный взгляд на обработку сообщений о проблемах самими разработчиками FreeBSD.
diff --git a/documentation/content/ru/articles/problem-reports/_index.po b/documentation/content/ru/articles/problem-reports/_index.po
new file mode 100644
index 0000000000..4b7ed7aceb
--- /dev/null
+++ b/documentation/content/ru/articles/problem-reports/_index.po
@@ -0,0 +1,1433 @@
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) YEAR The FreeBSD Project
+# This file is distributed under the same license as the FreeBSD Documentation package.
+# Vladlen Popolitov <vladlenpopolitov@list.ru>, 2025.
+msgid ""
+msgstr ""
+"Project-Id-Version: FreeBSD Documentation VERSION\n"
+"POT-Creation-Date: 2025-09-20 12:50+0300\n"
+"PO-Revision-Date: 2025-09-05 04:45+0000\n"
+"Last-Translator: Vladlen Popolitov <vladlenpopolitov@list.ru>\n"
+"Language-Team: Russian <https://translate-dev.freebsd.org/projects/"
+"documentation/articlesproblem-reports_index/ru/>\n"
+"Language: ru\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n%10>=2 && "
+"n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;\n"
+"X-Generator: Weblate 4.17\n"
+
+#. type: Yaml Front Matter Hash Value: description
+#: documentation/content/en/articles/problem-reports/_index.adoc:1
+#, no-wrap
+msgid "How to best formulate and submit a problem report to the FreeBSD Project"
+msgstr "Как лучше сформулировать и отправить отчет о проблеме в проект FreeBSD"
+
+#. type: Title =
+#: documentation/content/en/articles/problem-reports/_index.adoc:1
+#: documentation/content/en/articles/problem-reports/_index.adoc:11
+#, no-wrap
+msgid "Writing FreeBSD Problem Reports"
+msgstr "Составление сообщений о проблеме во FreeBSD"
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:44
+msgid "Abstract"
+msgstr "Аннотация"
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:46
+msgid ""
+"This article describes how to best formulate and submit a problem report to "
+"the FreeBSD Project."
+msgstr ""
+"Эта статья описывает, как наилучшим образом сформулировать и отправить "
+"сообщение о проблеме в Проект FreeBSD."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:48
+msgid "'''"
+msgstr "'''"
+
+#. type: Title ==
+#: documentation/content/en/articles/problem-reports/_index.adoc:52
+#, no-wrap
+msgid "Introduction"
+msgstr "Введение"
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:56
+msgid ""
+"One of the most frustrating experiences one can have as a software user is "
+"to submit a problem report only to have it summarily closed with a terse and "
+"unhelpful explanation like \"not a bug\" or \"bogus PR\".  Similarly, one of "
+"the most frustrating experiences as a software developer is to be flooded "
+"with problem reports that are not really problem reports but requests for "
+"support, or that contain little or no information about what the problem is "
+"and how to reproduce it."
+msgstr ""
+"Одной из самых разочаровывающих практик, которую можно получить в качестве "
+"пользователя программного обеспечения, является отправка сообщения о "
+"проблеме, которое вскоре закрывается с кратким и ничему не помогающим "
+"объяснением типа \"это не проблема\" или \"неправильное PR\". Подобным же "
+"образом одной из самых разочаровывающих практик, которую можно получить в "
+"качестве разработчика программного обеспечения, является получение массы "
+"сообщений о проблемах, которые на самом деле не являются сообщениями о "
+"проблемах, а запросами на получение поддержки, или которые содержат мало или "
+"вообще не содержат никакой информации о сути проблемы или способе ее "
+"воспроизведения."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:59
+msgid ""
+"This document attempts to describe how to write good problem reports.  What, "
+"one asks, is a good problem report? Well, to go straight to the bottom line, "
+"a good problem report is one that can be analyzed and dealt with swiftly, to "
+"the mutual satisfaction of both user and developer."
+msgstr ""
+"В этом документе делается попытка описать то, как составлять хорошие "
+"сообщения о проблемах. Что же, спросите вы, является хорошим сообщением о "
+"проблеме? Ну, если перейти прямо к сути, то хорошим сообщением об проблеме "
+"является то, которое может быть быстро проанализировано и отработано, к "
+"обоюдному удовлетворению как пользователя, так и разработчика."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:61
+msgid ""
+"Although the primary focus of this article is on FreeBSD problem reports, "
+"most of it should apply quite well to other software projects."
+msgstr ""
+"Хотя в основном статья фокусируется на сообщениях о проблемах во FreeBSD, "
+"большей частью она должна хорошо подходить и другим программным проектам."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:64
+msgid ""
+"Note that this article is organized thematically, not chronologically.  Read "
+"the entire document before submitting a problem report, rather than treating "
+"it as a step-by-step tutorial."
+msgstr ""
+"Заметьте, что эта статья организована по тематическому принципу, а не "
+"хронологически, так что вы должны прочесть документ целиком прежде, чем "
+"посылать сообщение о проблеме, и не воспринимать статью как пошаговое "
+"руководство."
+
+#. type: Title ==
+#: documentation/content/en/articles/problem-reports/_index.adoc:66
+#, no-wrap
+msgid "When to Submit a Problem Report"
+msgstr "Когда нужно отправлять сообщение о проблеме"
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:72
+msgid ""
+"There are many types of problems, and not all of them should engender a "
+"problem report.  Of course, nobody is perfect, and there will be times when "
+"what seems to be a bug in a program is, in fact, a misunderstanding of the "
+"syntax for a command or a typographical error in a configuration file "
+"(though that in itself may sometimes be indicative of poor documentation or "
+"poor error handling in the application).  There are still many cases where "
+"submitting a problem report is clearly _not_ the right course of action, and "
+"will only serve to frustrate both the submitter and the developers.  "
+"Conversely, there are cases where it might be appropriate to submit a "
+"problem report about something else than a bug—an enhancement or a new "
+"feature, for instance."
+msgstr ""
+"Имеется много классов ошибок, и не все они должны приводить к появлению "
+"сообщения о проблеме. Конечно же, нет идеальных людей, и будут моменты, "
+"когда вы решите, что нашли ошибку в программе, а на самом деле вы "
+"неправильно поняли синтаксис команды или сделали опечатку в конфигурационном "
+"файле (хотя само по себе это иногда говорит о плохой документации или "
+"неправильной обработке ошибок в прикладной программе). Есть еще много "
+"случаев, когда посылка сообщения о проблеме явно _не_ является правильным "
+"действием, а только приводит к разочарованию вас и разработчиков. И "
+"наоборот, есть случаи, когда может быть нужно послать сообщение о чем-то, не "
+"являющемся ошибкой - к примеру, запрос на доработку или расширение "
+"функциональности."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:76
+msgid ""
+"So how does one determine what is a bug and what is not? As a simple rule of "
+"thumb, the problem is _not_ a bug if it can be expressed as a question "
+"(usually of the form \"How do I do X?\" or \"Where can I find Y?\").  It is "
+"not always quite so black and white, but the question rule covers a large "
+"majority of cases.  When looking for an answer, consider posing the question "
+"to the {freebsd-questions}."
+msgstr ""
+"Но как же определить, что является ошибкой, а что нет? Простым правилом, "
+"которому нужно следовать, является следующее - ваша проблема _не_ является "
+"ошибкой, если она формулируется как вопрос (обычно в форме \"Как сделать X?"
+"\" или \"Где можно найти Y?\"). Не всегда это так однозначно, но правило "
+"вопроса покрывает большинство случаев. Если Вам нужен ответ, лучше всего "
+"задать свой вопрос в {freebsd-questions}."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:78
+msgid ""
+"Consider these factors when submitting PRs about ports or other software "
+"that is not part of FreeBSD itself:"
+msgstr ""
+"Вот некоторые случаи, в которых может оказаться полезным отправить сообщение "
+"о чем-то, что не является ошибкой:"
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:80
+msgid ""
+"Please do not submit problem reports that simply state that a newer version "
+"of an application is available. Ports maintainers are automatically notified "
+"by portscout when a new version of an application becomes available. Actual "
+"patches to update a port to the latest version are welcome."
+msgstr ""
+"Уведомление об обновлении программного обеспечения, которое поддерживается "
+"сторонними разработчиками (в основном порты, но также и компоненты базовой "
+"системы, разрабатываемые сторонними организациями, такие, как BIND или "
+"различные утилиты GNU)."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:81
+msgid ""
+"For unmaintained ports (`MAINTAINER` is `ports@FreeBSD.org`), a PR without "
+"an included patch is unlikely to get picked up by a committer. To become the "
+"maintainer of an unmaintained port, submit a PR with the request (patch "
+"preferred but not required)."
+msgstr ""
+"Для не поддерживаемых никем портов (переменная `MAINTAINER` содержит "
+"`ports@FreeBSD.org`), такие уведомления о обновлении будут замечены "
+"заинтересовавшимся коммиттером и вас могут попросить предоставить патч для "
+"обновления порта; предоставление патча до того, как вас попросят об этом "
+"сильно увеличит шансы того, что порт будет обновлён вовремя."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:82
+msgid ""
+"In either case, following the process described in extref:{porters-handbook}"
+"upgrading/[Porter's Handbook] will yield the best results. (You might also "
+"wish to read extref:{contributing}[Contributing to the FreeBSD Ports "
+"Collection, ports-contributing].)"
+msgstr ""
+"В любом случае, следование процессу, описанному в extref:{porters-handbook}"
+"upgrading[Руководстве по созданию портов] даст наилучшие результаты. "
+"(Также можно ознакомиться с статьей extref:{contributing}[Вклад в "
+"коллекцию портов FreeBSD, ports-contributing].)"
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:87
+msgid ""
+"A bug that cannot be reproduced can rarely be fixed.  If the bug only "
+"occurred once and you cannot reproduce it, and it does not seem to happen to "
+"anybody else, chances are none of the developers will be able to reproduce "
+"it or figure out what is wrong.  That does not mean it did not happen, but "
+"it does mean that the chances of your problem report ever leading to a bug "
+"fix are very slim.  To make matters worse, often these kinds of bugs are "
+"actually caused by failing hard drives or overheating processors—you should "
+"always try to rule out these causes, whenever possible, before submitting a "
+"PR."
+msgstr ""
+"Ошибка, которую нельзя воспроизвести, вряд ли будет исправлена. Если ошибка "
+"возникла только единожды, и вы не можете ее воспроизвести, к тому же никто с "
+"ней больше не сталкивался, нет никаких шансов, что разработчики смогут ее "
+"воспроизвести или понять, что делается неправильно. Это не значит, что "
+"такого не случается, но это значит, что шансов у вашего сообщения дойти "
+"когда-либо до стадии исправления ошибки очень малы. Часто эти виды ошибок "
+"возникают из-за неудовлетворительной работы жёстких дисков, перегревшихся "
+"процессоров. Всегда, когда это возможно вы должны отслеживать такие случаи "
+"перед посылкой сообщения об ошибке."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:89
+msgid ""
+"Next, to decide to whom you should file your problem report, you need to "
+"understand that the software that makes up FreeBSD is composed of several "
+"different elements:"
+msgstr ""
+"Теперь, чтобы определить кому вы должны отправить ваше сообщение об ошибке, "
+"вы должны понимать, что программное обеспечение, которое входит во FreeBSD, "
+"составляется из нескольких различных частей:"
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:91
+msgid ""
+"Code in the base system that is written and maintained by FreeBSD "
+"contributors, such as the kernel, the C library, and the device drivers "
+"(categorized as `kern`); the binary utilities (`bin`); the manual pages and "
+"documentation (`docs`); and the web pages (`www`). All bugs in these areas "
+"should be reported to the FreeBSD developers."
+msgstr ""
+"Код в базовой системе, который пишется и поддерживается контрибьюторами "
+"FreeBSD. Такой, как ядро, библиотека C, драйвера устройств (входят в "
+"категорию `kern`); утилиты (`bin`); страницы справочника и документация "
+"(`docs`); веб-страницы (`www`). Все ошибки в этих областях должны быть "
+"сообщены разработчикам FreeBSD."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:92
+msgid ""
+"Code in the base system that is written and maintained by others, and "
+"imported into FreeBSD and adapted. Examples include man:clang[1], and "
+"man:sendmail[8]. Most bugs in these areas should be reported to the FreeBSD "
+"developers; but in some cases they may need to be reported to the original "
+"authors instead if the problems are not FreeBSD-specific."
+msgstr ""
+"Код в базовой системе, который пишется и поддерживается другим, "
+"импортируется во FreeBSD и адаптируется. Примеры включают в себя: bind, "
+"man:gcc[1] и man:sendmail[8]. Большинство ошибок, попадающие в данные "
+"области должны быть сообщены разработчикам FreeBSD, но в некоторых случаях "
+"они должны быть отправлены изначальным разработчикам, если проблемы не "
+"являются специфичными для FreeBSD. Обычно ошибки такого рода попадают под "
+"категории `bin` или `gnu`."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:93
+msgid ""
+"Individual applications that are not in the base system but are instead part "
+"of the FreeBSD Ports Collection (category `ports`). Most of these "
+"applications are not written by FreeBSD developers; what FreeBSD provides is "
+"merely a framework for installing the application. Therefore, only report a "
+"problem to the FreeBSD developers when the problem is believed to be FreeBSD-"
+"specific; otherwise, report it to the authors of the software."
+msgstr ""
+"Отдельные приложения, не входящие в базовую систему, но являющиеся частью "
+"Коллекции Портов FreeBSD (категория `ports`). Большинство этих приложений не "
+"пишется разработчиками FreeBSD; что предоставляет FreeBSD, так это только "
+"лишь инфраструктуру для установки приложения. Следовательно, вы должны "
+"отправлять сообщение об ошибке разработчикам FreeBSD только тогда, когда вы "
+"уверены в том, что проблема специфична для FreeBSD - иначе отправляйте её "
+"авторам программного обеспечения."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:96
+msgid ""
+"Then, ascertain whether the problem is timely.  There are few things that "
+"will annoy a developer more than receiving a problem report about a bug she "
+"has already fixed."
+msgstr ""
+"Затем вы должны убедиться, действительно ли проблема существует. Существует "
+"всего несколько вещей, которые раздражают разработчика больше, чем получение "
+"сообщения об ошибке, которую он уже исправил."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:100
+msgid ""
+"If the problem is in the base system, first read the FAQ section on extref:"
+"{faq}[FreeBSD versions, latest-version], if you are not already familiar "
+"with the topic.  It is not possible for FreeBSD to fix problems in anything "
+"other than certain recent branches of the base system, so filing a bug "
+"report about an older version will probably only result in a developer "
+"advising you to upgrade to a supported version to see if the problem still "
+"recurs.  The Security Officer team maintains the link:https://"
+"www.FreeBSD.org/security/[list of supported versions]."
+msgstr ""
+"Если проблема в базовой системе, то вам нужно сначала прочесть раздел extref:"
+"{faq}[версии FreeBSD, latest-version] из FAQ, если вы ещё не знакомы с "
+"данной темой. Для FreeBSD возможно исправлять проблемы только для некоторых "
+"недавних веток базовой системы, поэтому отправка сообщения об ошибке для "
+"более старой версии приведёт к тому, что разработчик посоветует вам "
+"обновиться до поддерживаемой версии, чтобы посмотреть присутствует ли в ней "
+"проблема. Команда офицеров безопасности поддерживает link:https://"
+"www.FreeBSD.org/security/[список поддерживаемых версий.]."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:103
+msgid ""
+"If the problem is in a port, consider filing a bug with the upstream.  The "
+"FreeBSD Project can not fix all bugs in all software."
+msgstr ""
+"Если проблема в порте, рассмотрите возможность сообщить об ошибке "
+"разработчикам исходного проекта. Проект FreeBSD не может исправлять все "
+"ошибки во всём программном обеспечении."
+
+#. type: Title ==
+#: documentation/content/en/articles/problem-reports/_index.adoc:105
+#, no-wrap
+msgid "Preparations"
+msgstr "Подготовка"
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:111
+msgid ""
+"A good rule to follow is to always do a background search before submitting "
+"a problem report.  Maybe the problem has already been reported; maybe it is "
+"being discussed on the mailing lists, or recently was; it may even already "
+"be fixed in a newer version than what you are running.  You should therefore "
+"check all the obvious places before submitting your problem report.  For "
+"FreeBSD, this means:"
+msgstr ""
+"Нужно следовать хорошему правилу всегда сначала выполнять дополнительные "
+"исследования перед тем, как послать сообщение о проблеме. Может быть, о "
+"вашей проблеме уже сообщено; может быть, она недавно обсуждалась или "
+"обсуждается в списках рассылки; она может быть уже исправлена в более новой "
+"версии, чем та, что вы используете. Поэтому вы должны проверить все обычные "
+"места до того, как послать ваше сообщение о проблеме. Для FreeBSD это значит:"
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:113
+msgid ""
+"The FreeBSD extref:{faq}[Frequently Asked Questions] (FAQ) list. The FAQ "
+"attempts to provide answers for a wide range of questions, such as those "
+"concerning extref:{faq}[hardware compatibility, hardware], extref:{faq}[user "
+"applications, applications], and extref:{faq}[kernel configuration, "
+"kernelconfig]."
+msgstr ""
+"Список extref:{faq}[Часто задаваемых вопросов] (FAQ) по FreeBSD. FAQ "
+"содержит ответы на широкий круг вопросов, таких как вопросы, касающиеся "
+"extref:{faq}[совместимости оборудования, hardware], extref:{faq}"
+"[пользовательских приложений, applications] и extref:{faq}[конфигурации "
+"ядра, kernelconfig]."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:114
+msgid ""
+"The extref:{handbook}eresources/[mailing lists, eresources-mail]. If you are "
+"not subscribed, use https://www.FreeBSD.org/search/#mailinglists[the "
+"searchable archives] on the FreeBSD web site. If the problem has not been "
+"discussed on the lists, you might try posting a message about it and waiting "
+"a few days to see if someone can spot something that has been overlooked."
+msgstr ""
+"extref:{handbook}eresources/[Списки рассылки, eresources-mail] — если Вы не "
+"подписаны на них, воспользуйтесь https://www.FreeBSD.org/search/"
+"#mailinglists[поиском в архивах] на сайте FreeBSD. Если ваша проблема не "
+"обсуждалась в списках рассылки, вы можете попытаться опубликовать сообщение "
+"о ней и подождать несколько дней, пока кто-нибудь не сможет увидеть то, что "
+"вы не заметили."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:115
+msgid ""
+"Optionally, the entire web-use your favorite search engine to locate any "
+"references to the problem. You may even get hits from archived mailing lists "
+"or newsgroups you did not know of or had not thought to search through."
+msgstr ""
+"Как вариант, весь веб-используйте вашу любимую поисковую систему для поиска "
+"каких-либо ссылок по вашей проблеме. Вы можете даже увидеть ссылки на архивы "
+"списков рассылки или телеконференций, о которых вы не знали или не думали "
+"там искать."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:116
+msgid ""
+"Next, the searchable https://bugs.freebsd.org/bugzilla/query.cgi[FreeBSD PR "
+"database] (Bugzilla). Unless the problem is recent or obscure, there is a "
+"fair chance it has already been reported."
+msgstr ""
+"Следующим пунктом должна быть https://bugs.freebsd.org/bugzilla/"
+"query.cgi[ база данных PR FreeBSD] (Bugzilla). Если только ваша проблема не "
+"нова или редка, есть некоторый шанс, что о ней уже сообщено."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:117
+msgid ""
+"Most importantly, attempt to see if existing documentation in the source "
+"base addresses your problem."
+msgstr ""
+"И самое важное, вы должны посмотреть не затрагивает ли документация в "
+"базовой системе вашу проблему."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:120
+msgid ""
+"For the base FreeBSD code, you should carefully study the contents of "
+"[.filename]#/usr/src/UPDATING# on your system or the latest version at "
+"https://cgit.freebsd.org/src/tree/UPDATING[https://cgit.freebsd.org/src/tree/"
+"UPDATING].  (This is vital information if you are upgrading from one version "
+"to another, especially if you are upgrading to the FreeBSD-CURRENT branch)."
+msgstr ""
+"Для основного кода FreeBSD вы должны тщательно изучить содержимое файла "
+"[.filename]#/usr/src/UPDATING# или его текущую версию по адресу  https://"
+"cgit.freebsd.org/src/tree/UPDATING[https://cgit.freebsd.org/src/tree/"
+"UPDATING]. (Если вы переходите с одной версии на другую, особенно если вы "
+"обновляетесь до FreeBSD-CURRENT, то в этом файле вы можете найти много "
+"важной информации)."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:123
+msgid ""
+"However, if the problem is in something that was installed as a part of the "
+"FreeBSD Ports Collection, you should refer to [.filename]#/usr/ports/"
+"UPDATING# (for individual ports) or [.filename]#/usr/ports/CHANGES# (for "
+"changes that affect the entire Ports Collection).  https://cgit.freebsd.org/"
+"ports/tree/UPDATING[https://cgit.freebsd.org/ports/tree/UPDATING] and "
+"https://cgit.freebsd.org/ports/tree/CHANGES[https://cgit.freebsd.org/ports/"
+"tree/CHANGES] are also available via cgit."
+msgstr ""
+"Если же ваша проблема связана с коллекцией портов FreeBSD, вы должны "
+"обратиться к файлу [.filename]#/usr/ports/UPDATING# (изменения, касающиеся "
+"индивидуальных портов) или к [.filename]#/usr/ports/CHANGES# (изменения, "
+"касающиеся всей коллекции портов). Они также доступны через интерфейс cgit: "
+"https://cgit.freebsd.org/ports/tree/UPDATING[https://cgit.freebsd.org/ports/"
+"tree/UPDATING] и https://cgit.freebsd.org/ports/tree/CHANGES[https://"
+"cgit.freebsd.org/ports/tree/CHANGES] ."
+
+#. type: Title ==
+#: documentation/content/en/articles/problem-reports/_index.adoc:125
+#, no-wrap
+msgid "Writing the Problem Report"
+msgstr "Написание сообщения о проблеме"
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:129
+msgid ""
+"Now that you have decided that your issue merits a problem report, and that "
+"it is a FreeBSD problem, it is time to write the actual problem report.  "
+"Before we get into the mechanics of the program used to generate and submit "
+"PRs, here are some tips and tricks to help make sure that your PR will be "
+"most effective."
+msgstr ""
+"Теперь, после того, как вы решили, что ваш вопрос подпадает под категорию "
+"сообщения о проблеме, и это проблема FreeBSD, самое время написать "
+"собственно сообщение о проблеме (PR). Прежде чем мы углубимся в частности "
+"использования программы для создания и отправки PR, вот несколько советов, "
+"которые помогут вам сделать PR более эффективным."
+
+#. type: Title ==
+#: documentation/content/en/articles/problem-reports/_index.adoc:131
+#, no-wrap
+msgid "Tips and Tricks for Writing a Good Problem Report"
+msgstr "Как писать хорошие сообщения о проблемах"
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:134
+msgid ""
+"_Do not leave the \"Summary\" line empty._ The PRs go both onto a mailing "
+"list that goes all over the world (where the \"Summary\" is used for the "
+"`Subject:` line), but also into a database. Anyone who comes along later and "
+"browses the database by synopsis, and finds a PR with a blank subject line, "
+"tends just to skip over it. Remember that PRs stay in this database until "
+"they are closed by someone; an anonymous one will usually just disappear in "
+"the noise."
+msgstr ""
+"_Не оставляйте поле \"Summary\" (краткое описание) пустым._ Сообщения о "
+"проблемах попадают как в списки рассылки, которые затем расходятся по всему "
+"миру (в них поле \"Summary\" определяет тему письма), так и в базу данных. "
+"Просматривающий эту базу, как правило, пройдет мимо PR с пустым кратким "
+"описанием. Не забудьте, что PR остается в базе до тех пор, пока кто-либо не "
+"закроет его; сообщение-аноним, скорее всего, просто потеряется на общем фоне."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:135
+msgid ""
+"_Avoid using a weak \"Summary\" line._ You should not assume that anyone "
+"reading your PR has any context for your submission, so the more you "
+"provide, the better. For instance, what part of the system does the problem "
+"apply to? Do you only see the problem while installing, or while running? To "
+"illustrate, instead of `Summary: portupgrade is broken`, see how much more "
+"informative this seems: `Summary: port ports-mgmt/portupgrade coredumps on "
+"-current`. (In the case of ports, it is especially helpful to have both the "
+"category and portname in the \"Summary\" line.)"
+msgstr ""
+"__Избегайте туманных описаний в поле \"Summary\"__. Не стоит предполагать, "
+"что читающий ваше сообщение владеет контекстом; поэтому, чем подробнее вы "
+"опишете ситуацию, тем лучше. В частности, к какой части системы относится "
+"ваша проблема? Проявляется ли она на этапе установки или во время нормальной "
+"работы? Например, вместо строки `Summary: portupgrade is broken` следовало "
+"бы написать что-то вроде `Summary: port ports-mgmt/portupgrade coredumps on "
+"-current`. В случае портированных приложений в поле \"Summary\" полезно "
+"указывать не только имя порта, но и категорию."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:137
+msgid ""
+"_If you have a patch, say so._ The presence of a patch makes it much easier "
+"to progress a report."
+msgstr ""
+"_Если у вас есть патч, сообщите об этом._ Наличие патча значительно упрощает "
+"обработку отчёта."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:138
+msgid "Do not use the `patch` or `patch-ready` keywords – they are deprecated."
+msgstr ""
+"Не используйте ключевые слова `patch` или `patch-ready` — они устарели."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:139
+msgid ""
+"_If you are a maintainer, say so._ If you are maintaining a part of the "
+"source code (for instance, an existing port), you definitely should set the "
+"\"Class\" of your PR to `maintainer-update`. This way any committer that "
+"handles your PR will not have to check."
+msgstr ""
+"_Если вы сопровождаете код, укажите это._ Если вы сопровождаете часть "
+"исходного кода (например, существующий порт), обязательно установите «Class» "
+"вашего PR в значение `maintainer-update`. Таким образом, любой коммиттер, "
+"обрабатывающий ваш PR, не будет вынужден проверять это."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:140
+msgid ""
+"_Be specific._ The more information you supply about what problem you are "
+"having, the better your chance of getting a response."
+msgstr ""
+"_Будьте точны в формулировках._ Чем больше информации вы можете предоставить "
+"о проблеме, тем больше у вас шансов получить ответ."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:142
+msgid ""
+"Include the version of FreeBSD you are running (there is a place to put "
+"that, see below) and on which architecture. You should include whether you "
+"are running from a release (e.g., from a CD-ROM or download), or from a "
+"system maintained by Git (and, if so, what hash and branch you are at). If "
+"you are tracking the FreeBSD-CURRENT branch, that is the very first thing "
+"someone will ask, because fixes (especially for high-profile problems) tend "
+"to get committed very quickly, and FreeBSD-CURRENT users are expected to "
+"keep up."
+msgstr ""
+"Включите версию FreeBSD, которую вы используете (для этого есть специальное "
+"поле, см. ниже), и архитектуру. Укажите, используете ли вы релиз (например, "
+"с CD-ROM или загруженный) или систему, поддерживаемую через Git (и, если да, "
+"укажите хэш и ветку). Если вы используете ветку FreeBSD-CURRENT, укажите это "
+"в первую очередь, так как исправления (особенно для известных проблем) часто "
+"добавляются очень быстро, и пользователи FreeBSD-CURRENT должны следить за "
+"обновлениями."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:143
+msgid ""
+"Include which global options you have specified in your "
+"[.filename]#make.conf#, [.filename]#src.conf#, and [.filename]#src-"
+"env.conf#. Given the infinite number of options, not every combination may "
*** 843 LINES SKIPPED ***