О работе багтрекера

[Parasite]

К чему картинка, не совсем понял.

"Состояние, при котором инцидент считается отработанным"

[Tolik]

Аттач.

Я по-русски не понимаю. Что такое "отработан"? Какие ещё бывают статусы?

[gpsMax]

А, теперь ясно. Просто сначала одна мысль, потом другая, а потом снова первая сбили с толку.

Я в трекере с английским интерфейсом сижу, поэтому как бы привык к оригинальному термину resolved, но это к слову. А те настройки со скриншота - скорее, для статистики, иногда любопытно же её посмотреть.

Статусы можно посмотреть там же, на трекере: new, feedback, assigned, acknowledged, confirmed, resolved.

[Tolik]

А чем вызвана сегодняшняя буря в багтрекере? Внезапно всё пожелтело - решили использовать статус confirmed? Что это означает?

[vdemidov]

Я решил что слегка неправильно использовал статусы.
confirmed означает что бага или хотелка подтверждена разработчиками и поставлена в очередь.
acknowledged это несколько более слабое состояние. Мне бы хотелось, что бы добровольцы gpsMax и может еще пару человек выставляли его для действительно содержательных хотелок и воспроизводимых багов. Что бы мне не отвлекаться на баги типа 0000521, 0000555, 0000541

[Tolik]

А как бы мне стать манагером?

[vdemidov]

Не вопрос. Занимайтесь

[vasketsov]

Единственно, что мне странно и неудобно - что жизнь тикета заканчивается на стадии resolved, после чего reporter не может даже добавить комментарий.

И в чем тут странность? Resolved - is resolved, а если разработчик не уверен - просто не изменяет состояние тикета пока не будет уверен. Сие уже не к багтреккеру

Это весьма спорно. Когда я писал для нашей софтверной конторы что-то типа багтреккера и CRM в одном флаконе (и всё это в тесной связи с ERP, там была и система согласований всяких заявок и документов), возможность изменения полей в зависимости от статуса была изначально настраиваемой, и когда дело дошло до реальной эксплуатации, очень быстро разрешилось править описание после закрытия доработки. Естественно с учётом полномочий. Просто потому что комментарий и статус - это разные атрибуты одной сущности, и все они могут использоваться для поиска, генерации дочерних сущностей и прочего, а редактируемость комментария - это вычислимый атрибут ДРУГОЙ сущности. От подобных транзитивных зависимостей должна быть либо совершено конкретная польза (аналогия - общая дата закрытия), либо их быть не должно вовсе. Максимум на что можно пойти в случае необходимости ограничения - это запретить модифицировать поля до некоторой даты (даты закрытия). Другой пользы нет.

Тем более, что установить закрывающий статус может один человек, а пожелать прокомментировать - другой человек. В простейшем случае - другой разработчик или некий "выпускающий" чел. А в принципе может и сам. Например, если комментарии после даты закрытия вообще не показываются левым товарищам, то непосредственно после закрытия сам разработчик при необходимости напишет новый комментарий типа TODO, потом как-нибудь к нему (поиском) вернётся и поглядит, потом удалит (как комментарий с датой больше даты закрытия), создав новую доработку или ничего не создав.

Тем более, что в случае мантиса речь идёт о новых комментариях с новой датой, которые никак не затрагивают старую информацию (на основании которой выполняется доработка, принимаются решения и т.п.). В этом смысле ограничение создания новых комментариев не несёт цели ограничить изменение (возможно существенных) старых данных. И никакой другой цели не несёт. То есть фактически это излишне грубое решение достаточно простой (не в смысле конкретной реализации мантиса, а вообще) проблемы. При том что в принципе можно откатить статус, поправить чего надо и накатить статус по новой (замечу, всё это публично и не в рамках одной транзакции). Таким образом, это "решение" создаёт ещё и неудобство в том случае, если создание нового комментария действительно необходимо.

ЗЫ. Кстати, разработчики в багтреккере в нормальной ситуации никогда не бывают главными.

[vdemidov]

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

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

[gpsMax]

Я решил что слегка неправильно использовал статусы. :)
confirmed означает что бага или хотелка подтверждена разработчиками и поставлена в очередь.
acknowledged это несколько более слабое состояние. Мне бы хотелось, что бы добровольцы gpsMax и может еще пару человек выставляли его для действительно содержательных хотелок и воспроизводимых багов. Что бы мне не отвлекаться на баги типа 0000521, 0000555, 0000541

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

То есть, со статусами сейчас так?
new - первоначальное вхождение, неопределенное, разработчики особо не отвлекаются на него
acknowledged - слегка устаканенное и прояснённое, готовое к следующему этапу
confirmed - просмотренное разработчиками и поставленное в очередь
feedback - ?
assigned - ?
отличия resolved от closed - ?

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