База знаний Mozilla остаётся открытой для всех, кто хочет внести свой вклад. Любой может отправить незначительную правку, чтобы исправить или обновить наши статьи поддержки, не требуя специальных разрешений.

Этот документ описывает рабочий процесс для новых запросов на контент и крупных обновлений, которые координируются через Bugzilla. Эти запросы следуют другому процессу, поскольку они часто требуют сотрудничества с командами продуктов и другими заинтересованными сторонами.

Если вы не уверены, какой рабочий процесс применим к вашему изменению, пожалуйста, обратитесь к разделу Основное правило ниже или ознакомьтесь с Незначительные и значительные изменения, чтобы понять, к какой категории относится предлагаемое вами изменение.

Почему Bugzilla?

Мы используем Bugzilla для координации обсуждений новых запросов на контент и крупных обновлений, поскольку в этом процессе часто участвуют несколько заинтересованных сторон.

Использование единого пространства для совместной работы помогает обеспечить прозрачность и доступность обсуждений для всех участников. Мы намеренно используем Bugzilla вместо обсуждений в статьях Базы знаний, потому что многие из наших заинтересованных сторон, связанных с продуктами, уже работают в Bugzilla в рамках своего обычного рабочего процесса, в то время как сравнительно немногие знакомы с системой обсуждений Базы знаний.

Bugzilla также обеспечивает чёткое владение задачами и отслеживание прогресса. Поскольку создание контента — это совместная работа сотрудников Mozilla и участников сообщества, важно, чтобы каждый мог легко видеть, кто отвечает за запрос, какие решения были приняты и какая работа осталась. Это помогает избежать дублирования усилий, уменьшает путаницу и облегчает соблюдение графика выпуска документации, связанной с релизами.

Основное правило

Как общее правило, вы можете задать себе следующий вопрос:

Требует ли это изменение вклада или подтверждения от команды продукта?

• Если да, создайте или работайте через тикет в Bugzilla, чтобы соответствующие заинтересованные стороны могли принять участие в обсуждении.
• Если нет, вы, как правило, можете отправить изменение напрямую как незначительное обновление Базы знаний.

Другими словами, если предлагаемое вами изменение не требует участия заинтересованных сторон продукта и подпадает под категорию незначительной правки, нет необходимости использовать Bugzilla.

Почему существует этот процесс

Этот процесс предназначен для поддержки вклада сообщества. Он помогает нам:

• Защищать сроки релизов
• Прояснять ответственность и подотчётность
• Сохранять здоровое сотрудничество
• Избегать разногласий, вызванных нечёткими ожиданиями

Мы глубоко ценим опыт участников сообщества. Многолетние знания о продукте в сообществе невероятно ценны. В то же время работа с контентом, связанная с выпуском продуктов и межфункциональным сотрудничеством, требует чёткого распределения ответственности, предсказуемых сроков и структурированной координации, чтобы мы могли обеспечить своевременную доставку точного и полезного контента для поддержки глобальной базы пользователей Mozilla.

Рабочий процесс для запросов на контент через Bugzilla

Следующий процесс применяется к новым запросам на контент и крупным обновлениям, отправленным через Bugzilla.

Запросы на контент обычно делятся на две категории:

• Запросы, связанные с релизом (on-train): Контент, привязанный к запланированному релизу Firefox. Эти запросы чувствительны ко времени и должны соответствовать графику релиза.
• Запросы, не связанные с релизом (off-train): Контент, не привязанный к запланированному релизу Firefox. У этих запросов всё ещё может быть целевой срок, но они обычно допускают большую гибкость.

Для полного просмотра, пожалуйста, откройте изображение в новой вкладке.

1. Отправка

Все крупные обновления контента должны быть отправлены через тикет в Bugzilla.

2. Анализ и назначение

Анализ: Все новые запросы на контент проходят процесс анализа для определения приоритета и назначения. Анализ проводится еженедельно по четвергам.

Запросы на контент, открытые для участников сообщества, будут помечены ключевым словом sumo-contributors в Bugzilla. Если вы заинтересованы в помощи с одним из этих запросов, не стесняйтесь выразить свой интерес, оставив комментарий непосредственно в тикете Bugzilla.

Назначение: Сотрудник CX назначит баг либо участнику сообщества, либо техническому писателю. После назначения менеджер сообщества или другой член команды CX будет направлять вас в этом процессе. Пожалуйста, не начинайте создавать черновик, пока сотрудник CX не подтвердит ваше назначение.

Ожидаемые сроки: Анализ проводится еженедельно, и участники сообщества могут ожидать ответа на свой запрос о назначении в течение пяти рабочих дней.

• Запросы, связанные с релизом (on-train): Назначение для запросов, связанных с релизом, чувствительно ко времени. Если связанный с релизом запрос открыт для участников сообщества, но остаётся неназначенным после следующего цикла анализа (5 рабочих дней), команда CX может назначить его техническому писателю, чтобы не задерживать график релиза.

• Запросы, не связанные с релизом (off-train): Запросы, не связанные с релизом, обычно допускают большую гибкость и могут оставаться доступными для назначения участникам сообщества дольше, в зависимости от запрашиваемого срока.

3. Создание контента

Черновик контента: Внимательно изучите тикет, чтобы понять запрос, его объём, целевой релиз или срок, а также ожидаемый результат, прежде чем начинать работу.

Как только баг будет вам назначен, вы можете начать создавать контент. Если команда продукта предоставит черновик, используйте его в качестве отправной точки. В противном случае вы можете начать создавать черновик контента в Google Docs. Если Google Docs не является возможным вариантом, вы можете прикрепить свой черновик непосредственно к тикету Bugzilla для проверки.

Обязательно опубликуйте ссылку на свой черновик в тикете Bugzilla и установите разрешения для документа, чтобы позволить заинтересованным сторонам оставлять комментарии.

Утверждение контента: Тесно сотрудничайте с автором запроса или заинтересованными сторонами продукта, чтобы убедиться, что статья является полной и точной. Если для выполнения работы не хватает какой-либо информации, используйте опцию «Запросить информацию у…» в Bugzilla, чтобы получить дополнительные сведения.

Вы можете проверить последнюю строку описания формы Bugzilla, чтобы увидеть, был ли определён официальный утверждающий для черновика.

Ожидаемые сроки:

• Запросы, связанные с релизом (on-train): Должны рассматриваться как высокоприоритетные. Если прогресс не заблокирован зависимостями от других заинтересованных сторон, команда CX может переназначить запросы, связанные с релизом, если значимый черновик не будет готов к проверке в течение недели после назначения или за неделю до целевого дня релиза. Это помогает обеспечить готовность контента к моменту релиза.

• Запросы, не связанные с релизом (off-train): Черновик, как правило, должен быть готов к проверке заинтересованными сторонами не менее чем за одну неделю до запрашиваемого срока.

Эскалация:

• Если вы думаете, что не сможете уложиться в ожидаемые сроки, пожалуйста, как можно скорее уведомите команду CX, обновив тикет в Bugzilla или связавшись с сотрудником CX напрямую. Раннее информирование даёт нам время скорректировать план или найти дополнительную поддержку, не задерживая публикацию.
• Если вы не можете получить необходимую информацию от автора запроса, обратитесь к сотруднику CX, который назначил баг, за помощью в получении необходимой информации.

4. Публикация контента

Публикация контента: После того как черновик будет окончательно готов и утверждён заинтересованными сторонами, вы можете отправить контент как новую ревизию в фактической статье Базы знаний.

Пожалуйста, помните, что наша База знаний использует собственный синтаксис wiki, поэтому убедитесь, что ваш контент отформатирован правильно при переносе его из Google Docs или другого инструмента, который вы используете для создания черновика.

Проверка контента: Участники сообщества должны дождаться, пока их ревизия в Базе знаний будет проверена сотрудником или рецензентом Базы знаний, отличным от автора. На этом этапе проверка в основном сосредоточена на обеспечении качества и правильной разметке, а не на проверке точности основной информации о продукте.

Ожидаемые сроки:

• Запросы, связанные с релизом (on-train): В тикете Bugzilla может быть указана запланированная дата публикации, согласованная с графиком релиза Firefox. Пожалуйста, отправьте ревизию Базы знаний на проверку не менее чем за два дня до целевой даты публикации, если только прогресс не заблокирован зависимостями от других заинтересованных сторон. Это даёт рецензентам достаточно времени для завершения окончательной проверки качества и разметки, не подвергая риску срок релиза.

• Запросы, не связанные с релизом (off-train): Публикация должна соответствовать сроку, согласованному в тикете Bugzilla.

Эскалация: Если вам нужна помощь с проверкой ревизии Базы знаний, вы можете связаться с рецензентами Базы знаний, отправив электронное письмо по адресу kb-reviewers@mozilla.com.

Закрытие тикета: После публикации статьи в Базе знаний тикет в Bugzilla можно закрыть, отметив его как Resolved — Fixed.

Понимание утверждения контента и проверки контента

Исторически участники Базы знаний знакомы только с процессом проверки в Базе знаний, где любой, у кого есть права рецензента Базы знаний, может проверять и утверждать или отклонять ревизии статей.

Однако при работе через Bugzilla существуют две отдельные контрольные точки:

1. Утверждение контента: Выполняется соответствующими заинтересованными сторонами продукта в процессе создания контента в Bugzilla.
2. Проверка контента: Выполняется рецензентами Базы знаний перед публикацией статьи.

Хотя оба процесса важны, они служат разным целям.

Утверждение контента заинтересованными сторонами

Основная цель утверждения контента — проверка сути и замысла контента с участием заинтересованных сторон продукта. Это включает в себя проверку того, что черновик контента:

• Технически точен и отражает предполагаемое поведение продукта
• Соответствует утверждённой терминологии продукта и соглашениям об именах
• Согласуется с голосом бренда и сообщениями Mozilla

Проверка контента рецензентом Базы знаний

Проверка контента дополняет утверждение, фокусируясь на качестве и представлении статьи. На этом этапе рецензенты Базы знаний проверяют, что статья:

• Использует правильный синтаксис и форматирование, включая разметку wiki
• Ясная, хорошо структурирована и проста для понимания
• Соответствует редакционным и руководствам по контенту Mozilla

Вместе эти два шага помогают гарантировать, что каждая статья является как технически точной, так и простой для понимания пользователями перед её публикацией.

Дополнительные рекомендации для участников сообщества

• Справедливость назначения

Участники сообщества, имеющие прямые отношения с командами продуктов, могут быть в курсе предстоящих запросов до их официальной подачи. Однако, пожалуйста, не начинайте работу и не запрашивайте назначение до тех пор, пока запрос на контент не будет создан и проанализирован. Это гарантирует, что возможности для внесения вклада остаются открытыми и справедливыми для всех участников.

• Уважайте процесс анализа

Пожалуйста, предоставьте команде CX полное окно в 5 рабочих дней для анализа и назначения тикетов в Bugzilla. Избегайте запросов или давления для принятия решений о назначении до истечения этого периода.

• Сообщайте об изменениях в своей доступности

Мы понимаем, что могут возникнуть непредвиденные ситуации. Если вы не можете уложиться в срок, который вы обязались соблюдать, пожалуйста, как можно скорее уведомите команду CX, чтобы мы могли внести соответствующие коррективы.

• Политика повторного открытия тикетов в Bugzilla

Пожалуйста, не открывайте повторно решённый тикет с запросом на контент в Bugzilla для запроса проверки ревизий, которые не имеют прямого отношения к первоначальному запросу. Для связанных обновлений добавляйте новый комментарий в существующий тикет, а не открывайте его повторно. Если у вас нет прав на комментирование, пожалуйста, эскалируйте ваш запрос в список рассылки kb-reviewers (читайте ниже).

Повторное открытие тикетов без соблюдения этого стандарта может привести к отклонению запроса. Пожалуйста, следуйте Этикету Bugzilla для поддержания продуктивного и уважительного сотрудничества.

• Запросы на ускоренную проверку

Если новая статья или ревизия требует более быстрого выполнения, например, в случае срочного изменения продукта, текущего инцидента или критической неточности, вы можете отправить электронное письмо по адресу kb-reviewers@mozilla.com, чтобы запросить ускоренную проверку.

Поиск запросов на контент для работы

Участникам сообщества рекомендуется принимать участие в запросах на контент через Bugzilla, если они соответствуют критериям, описанным в следующем разделе. Вот как вы можете искать входящие запросы на контент:

• Ручной мониторинг

Вы можете следить за новыми запросами на контент, проверяя список неназначенных запросов на контент. Если вы найдёте запрос, над которым хотели бы поработать, просто оставьте комментарий в баге, чтобы сообщить команде CX о своей заинтересованности.

После анализа запросы на контент, открытые для вклада сообщества, будут помечены ключевым словом sumo-contributors в Bugzilla. Вы можете использовать это ключевое слово, чтобы отслеживать текущие запросы, доступные для участников сообщества.

• Будьте в курсе

Если вы хотите получать уведомления о новых запросах на контент, рассмотрите возможность отслеживания компонента Knowledge Base Content в Bugzilla. Для этого перейдите в свой профиль Bugzilla → Edit Profile & Preferences → Component Watching. Выберите support.mozilla.org в выборе продукта, выберите Knowledge Base Content в поле Component и нажмите кнопку Add, чтобы сохранить изменения.

Критерии назначения

Запрос на контент может быть назначен участнику сообщества, если он соответствует следующим условиям:

• Не содержит конфиденциальной информации

Запросы на контент, содержащие информацию под эмбарго или конфиденциальные данные, останутся в ведении сотрудников.

• Не предполагает тесных внутренних зависимостей

Запросы, которые затрагивают чувствительность сообщений, проверку на соответствие требованиям, или изменяющиеся спецификации и требуют активной координации с юридическим отделом, отделом маркетинга и коммуникаций, отделом безопасности или внешними партнёрами, также останутся в ведении сотрудников.

• Не связаны с платными продуктами

Запросы на контент, связанные с продуктами по подписке и платными функциями, должны оставаться в ведении сотрудников из-за требований юридического характера, соответствия, тестирования и межфункциональной координации. Эти запросы часто включают договорную, биллинговую или чувствительную к релизам информацию, которая требует централизованной ответственности.

• Не являются срочными

Запросы на контент со сроком выполнения менее 5 дней останутся у сотрудников для обеспечения своевременной доставки и соответствия графикам релизов.

• Загруженность участника сообщества

Участники сообщества могут иметь не более 3 активных заданий одновременно. Это помогает обеспечить сфокусированное выполнение и предотвращает дисбаланс рабочей нагрузки. Мы понимаем, что некоторые запросы могут быть задержаны из-за технических зависимостей. Если запрос остаётся заблокированным из-за зависимостей на стороне продукта более двух недель, тикет может считаться неактивным (устаревшим) и исключаться из ожидаемой рабочей нагрузки участника.

Дополнительные разъяснения:

• Это относится только к запросам через Bugzilla и не распространяется на незначительные ревизии в Базе знаний.
• Это не относится к созданию Часто задаваемые вопросы на форуме.
• Сотрудники сохраняют за собой окончательную ответственность за опубликованный контент.