Skip to content

Latest commit

 

History

History
91 lines (63 loc) · 11.8 KB

issues-policy.md

File metadata and controls

91 lines (63 loc) · 11.8 KB
ms.openlocfilehash ms.sourcegitcommit ms.translationtype ms.contentlocale ms.lasthandoff ms.locfileid
33178637c4fcfb21e8190c3d2593f09326ea5995
7588136e355e10cbc2582f389c90c127363c02a5
HT
ru-RU
03/14/2020
73166638

Процесс и политика в отношении проблем на GitHub

Цели этого процесса:

  1. обеспечить, чтобы ошибки или пропуски в документации не мешали клиентам;
  2. своевременно реагировать на отзывы и проблемы клиентов;
  3. постоянно развивать взаимодействие с клиентами;
  4. получать сведения о впечатлениях клиентов через открытое обсуждение проблем и решений.

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

Процесс включает следующие задачи с фиксированным распределением времени.

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

Этап диагностики

Каждый участник команды каждый рабочий день тратит до 30 минут на классификацию новых проблем. Мы ищем ответы на следующие вопросы.

  • Связана ли проблема с документацией или самим продуктом?
  • Возможно, это не проблема, а вопрос для форума или сайта поддержки?
  • Какой приоритет имеет эта проблема?
  • К какому подразделению относится эта проблема?

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

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

  • Благодарности. Мы благодарим за отзыв и закрываем проблему.
  • Проблемы с продуктом. Проблемы, связанные с самим продуктом, а не с нашей документацией, сразу закрываются. Мы можем выполнить по ним дополнительные действия, как описано ниже.
  • Нарушения кодекса поведения. Если в описании проблемы есть нарушения кодекса поведения, за которые полагается жалоба и блокировка, такие проблемы сразу закрываются с жалобой.
  • Повторы. Повторные сообщения закрываются с комментарием, указывающим на уже существующее сообщение об ошибке.
  • Документация в порядке. Клиент ошибается, а в документации все в порядке.
  • Форум. Проблемы, которые нужно направлять в службу поддержки или на форум, передаются на Stack Overflow или другие сайты поддержки и сразу закрываются.

Действия при наличии проблем с продуктом

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

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

Правильный выбор действий зависит от субъективной оценки. Члены команды руководствуются здравым смыслом при выборе действий

Действия при наличии проблем с содержимым

Для проблем другого рода команда выполняет следующее:

  • назначение приоритета;
  • присвоение контрольной точки, обычно это "невыполненная работа";
  • оценка, можно ли классифицировать проблему как "up-for-grabs" или лучше передать ее в проекты для участников сообщества .NET.

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

  • P0. Пропуск или ошибка в документации не позволяет клиентам успешно выполнить стандартный сценарий.
    • Проблемы уровня P0 решаются в течение трех недель и считаются более приоритетными, чем ранее запланированная работа.
  • P1. Пропуск или ошибка в документации существенно затрудняет стандартный сценарий или блокирует хорошо известные сценарии.
    • Проблемы уровня P1 вносятся в расписание на приоритетной основе. Чаще всего проблемы P1 назначаются на ближайшую контрольную точку.
  • P2. Проблемы, которые приводят к незначительным неудобствам или влияют на статью с низкой частотой просмотра.
    • Проблемы уровня P2 обычно исправляются одновременно с обновлением статьи, связанным с более приоритетными причинами.
  • P3. Проблемы, которые относятся к запросам для пограничных случаев.
    • Проблемы уровня P3 помещаются в список невыполненных работ и оцениваются в том случае, когда соответствующие статьи обновляются по более приоритетным причинам.

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

Метка up-for-grabs применяется, когда проблема хорошо подходит для исправления членом сообщества (возможно, автором статьи). Член группы, который применяет метку up-for-grabs, постарается помочь члену сообщества в работе над запросом на включение изменений или найти другого помощника. Проблемы с меткой "up-for-grabs" часто добавляются в проекты участников сообщества.

Примечание. Приведенное выше соглашение принято сравнительно недавно. Тот, кто добавляет эту метку, может предоставить вам контактные данные другого члена команды, который окажет помощь в работе.

Этап решения

Присланные клиентами проблемы включаются в обычный процесс планирования задач. Каждый участник команды выделяет 4 часа в неделю на решение присланных клиентом проблем с наибольшим приоритетом.

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

  • P0. Как можно скорее, в любом случае не позднее трех недель.
  • P1. В плановом режиме наряду с другими запланированными работами уровня P1. Обычно задачи этого приоритета решаются в течение трех месяцев.
  • P2. В плановом режиме наряду с другими запланированными работами уровня P2. Проблемы уровня P2 регулярно планируются к выполнению с учетом затронутой ими области и рейтинге. Чаще всего проблемы P2 устраняются при плановом обновлении статьи.
  • P3. Дата исправления не гарантируется. При обновлении каждой статьи мы изучаем список невыполненных задач на предмет наличия других проблем в той же статье.

Приоритет проблемы может измениться с учетом новых отзывов и данных о рейтинге статей.