Правила для правильно организованного багтрекера (Mantis et al)

Question

Над конкретным проектом мы работаем с 10 членами команды.

После примерно года работы над проектом (и использования Mantis как средства отслеживания ошибок / возможностей), средство отслеживания ошибок становится все более и более сложным, поскольку не было установлено ни одного стандарта, объясняющего, как создавать новые задачи, как комментировать задачи и т. д. Это приводит к появлению нескольких записей об одних и тех же ошибках, невозможности легко находить ошибки при их поиске и т. д.

Как вы организуете свой багтрекер? Используете ли вы много (под) категорий для разных частей вашего приложения (GUI, Backend и т. Д.), Используете ли вы теги в заголовке задач (т. Е. «[GUI] [OptionPage] Ошибка»)?

Разрешено ли кому-либо в вашей команде вводить новые задачи или этот шаг передается через одного "Мастера-богомола" (который затем узнает, является ли новый отчет дубликатом или полностью новой записью)?

Answer 1

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

Answer 2

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

Новое: любой может ввести ошибку.

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

Подтверждено: устанавливается лицами, принимающими решения, которые в основном говорят: «Мы будем делать это».

Я на самом деле не помню, где это было, и что более важно Я не знаю, насколько хорошо это работало .

Answer 3

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

Лучше для общего понимания, если роль не отводится людям, работающим в (основной) команде.