Триажирование ошибок и курация проблем#

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

Работа над проблемами для их улучшения#

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

  • документирование проблем, в которых отсутствуют элементы для воспроизведения проблемы, такие как примеры кода

  • предлагая лучшее использование форматирования кода

  • предлагая переформулировать заголовок и описание, чтобы сделать их более явными относительно решаемой проблемы

  • ссылки на связанные проблемы или обсуждения с кратким описанием их связи, например, «См. также #xyz для аналогичной попытки этого» или «См. также #xyz, где то же самое произошло в SomeEstimator», предоставляют контекст и помогают обсуждению.

Работа над PR для помощи в ревью#

Также рекомендуется проверка кода. Участники и пользователи приглашаются к участию в процессе проверки, следуя нашему руководство по рецензированию.

Триажирование операций для членов команд ядра и опыта участников#

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

  • Обновить метки для issues и PRs: см. список доступные метки github.

  • Определить, нужно ли перемаркировать PR как застрявший или нуждается в помощи (это особенно важно в контексте спринтов, где есть риск создания множества незавершённых PR)

  • Если застрявший PR взят на себя более новым PR, то пометьте застрявший PR как «Заменен», оставьте комментарий в застрявшем PR со ссылкой на новый PR и, вероятно, закройте застрявший PR.

  • Триаж проблем:

    • вопросы по использованию и вежливо указать автору использовать Stack Overflow вместо этого.

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

    • закрыть проблемы, которые не могут быть воспроизведены, после предоставления времени (не менее недели) для добавления дополнительной информации

Сохранённые ответы полезны для экономии времени и при этом оставаться гостеприимными и вежливыми при сортировке.

См. описание на github для роли в организации.

Типичный рабочий процесс для сортировки проблем#

Следующий рабочий процесс [1] является хорошим способом подхода к триажированию проблем:

  1. Поблагодарить автора за создание issue

    Трекер проблем для многих людей является первым взаимодействием с проектом scikit-learn, выходящим за рамки простого использования библиотеки. Поэтому мы хотим, чтобы это был приятный и гостеприимный опыт.

  2. Это вопрос по использованию? Если да, закройте его вежливым сообщением (вот пример).

  3. Предоставлена ли необходимая информация?

    Если важная информация (например, версия scikit-learn), отсутствует, не стесняйтесь запросить её и пометить проблему меткой "Needs info".

  4. Это дублирующаяся проблема?

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

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

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

  6. Является ли проблема минимальной и воспроизводимой?

    Для сообщений об ошибках мы просим предоставить минимальный воспроизводимый пример. См. этот полезный пост от Мэтью Роклина для хорошего объяснения. Если пример не воспроизводим, или если он явно не минимален, не стесняйтесь спросить репортера, может ли он предоставить пример или упростить предоставленный. Признайте, что написание минимальных воспроизводимых примеров - тяжелая работа. Если репортер испытывает трудности, вы можете попытаться написать его самостоятельно.

    Если предоставлен воспроизводимый пример, но вы видите упрощение, добавьте свой более простой воспроизводимый пример.

  7. Добавьте соответствующие метки, такие как «Документация», если проблема касается документации, «Ошибка», если это явная ошибка, «Улучшение», если это запрос на улучшение, …

    Если проблема чётко определена и исправление кажется относительно простым, пометьте issue как «Good first issue».

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

  8. Удалить метку «Needs Triage» из задачи, если она существует.