?

Log in

No account? Create an account
 
 
24 Сентябрь 2009 @ 12:09
Публичный багтрекер  
Один из клиентов предложил на форуме поднять публичный багтрекер, для генерации What's new. Публичный багтрекер не нравится вот по каким причинам:

1) Проблему с генерацией What's new он все равно не решает, т.к. это лишь один из ресурсов.  Многие все равно будут слать почтой, по аське, через форум, очень много багов с закрытой информацией (скриншоты, дампы, логи). Это все либо надо сводить в одно место самому, либо заставлять делать пользователей. А что делать, если бага была публичной, но потом для исправления понадобился бекап базы, "как повторить", скриншоты - к публичной баге все это уже не приложишь.

2) На каком языке вести этот публичный багтрекер ? У нас российских и иностранных клиентов - 50/50. What's new на русском и английском вперемешку мне не нравится :-)

3) История с JIRA показывает, что никто толком не знает, чего ждать после внесения баги в багтрекер. Если на e-mail не ответили в течение 24 часов, то получатель письма "наверное, умер".
Отвечать на каждый комментарий в трекере - глупо. Просто накапливать информацию и ничего не сообщать пользователям - еще хуже. Если бага висит в трекере на первом месте 3 года, то часть пользователей решит, что мы этим интенсивно занимаемся или займемся в самое ближайшее время, а другая часть - что мы этого вообще делать не будем.
 
 
 
vit_rvit_r on Сентябрь, 24, 2009 09:26 (UTC)
Проще завести отдельный блог (не форум) где раз в неделю писать общий обзор. Главное, чтоб регулярно.

Максим Крамаренкоmaximkr on Сентябрь, 24, 2009 12:45 (UTC)
А нечего там обозревать, правим глюки, которые появляются на очень специфических конфигурациях, в основном.

Сейчас понял, чем мне еще формат публичного багтрекера не нравится - он практически не подразумевает немедленную помощь пользователю. Например, если нужна какая-то фича, а ее нет, то проблему очень часто можно решить скриптом или если базу чуть по-другому сконфигурировать. А если пользователь просто видит request и голосует - никак об этом не узнаешь, выяснять зачем это нужно и как используется прямо в комментариях к баге - тоже плохо.
(no subject) - vit_r on Сентябрь, 24, 2009 13:07 (UTC) (Развернуть)
Сергей Слесаревsergeyslesarev on Сентябрь, 24, 2009 15:11 (UTC)
А, кстати, сделайте сообщество в ЖЖ про TrackStudio. Один участник и читатель (я) - гарантирован :)
Максим Крамаренкоmaximkr on Сентябрь, 24, 2009 22:04 (UTC)
Сделал, называется "trackstudio". Теперь бы еще придумать что там писать :-)
anonymous_l_j on Сентябрь, 24, 2009 21:21 (UTC)
вообще для генерации what's new логичнее использовать комменты коммитов в svn (или что там у вас).
т.е. если коммит добавляет какую функциональность, добавляем его комменту префикс "TO_NEW:", после сборки релиза grepаем свн лог по этому слову и получаем список.
Максим Крамаренкоmaximkr on Сентябрь, 24, 2009 22:03 (UTC)
А у нас там только id-номера задач во внутреннем трекере.
(no subject) - anonymous_l_j on Сентябрь, 25, 2009 10:52 (UTC) (Развернуть)
(no subject) - maximkr on Сентябрь, 25, 2009 11:12 (UTC) (Развернуть)
necro_log on Сентябрь, 25, 2009 05:52 (UTC)
Не конечно можно сделать отдельным разделом форума и у англичан и и у россиян.
Создали ветку скажем Bags and Features. Написали номер версии и обсуждаем. Новая версия вышла закрыли тему создали новую. Ток вот впорос модераторства надо будет чистить не сосвсем относящиеся по теме вопросы. Таким образом получается ри закрытии темы надо будет учесть что мы принимаем состояние закрыто как выполненную работу. Тоесть все что написано было - исправили или добавили.
Но вот что делать с письмами которые пришли и содержат ту же информацию. Можно их опускать конечно только надо лазить на форум и выяснять получается было такое или нет + работа. А если письмо сожержит новую информацию то можно впринципе добавлять в онец темы перед ее закрытием.
Из этого вывод. В какойтомере это удобнее для пользователей, но не удобно для разработчиков.
Макс Васенковwinzard on Сентябрь, 25, 2009 09:02 (UTC)
Форум-то есть, но формат блога подходит больше. Собственно, уже создали, буду писать.
Teoteo_bon on Сентябрь, 25, 2009 09:03 (UTC)
Почему нужен багтрекер:
1) у многих возникают схожие проблемы, не стоит их дублировать. Форум не позволяет быстро понять, была ли у кого подобная проблема, багтрекер же с помощью различных классификаций ускоряет этот процесс.
2) Допустим, что баг принят в работу, возникает вопрос - когда он будет исправлен? Тут нужна его привязка к конкретным релизам (например, этот баг мы исправим в следующей бете, этот - в бете через одну, а это вообще не баг, и править его не будем, а если и будем - то только в пятой версии). Эта привязка позволяет на автомате генерить ченджлоги для каждого билда. В любом случае, у клиента есть четкое понимание текущего состояния бага и сроки его исправления (или же дата исправления)
3) Помимо багов, в багтрекере могут отражаться и разного рода улучшения и просто смена отдельных компонентов системы. С той же привязкой к релизам, со всеми вытекающими эффектами.

Прервусь, дополню как будет время.
Nick Fedchik: SkyEyenick_fedchik on Сентябрь, 25, 2009 10:59 (UTC)
Обратите Ваш взор на Мантис
http://www.mantisbt.org/bugs/changelog_page.php
(также см. мой пост в этой ветке)
(no subject) - teo_bon on Сентябрь, 27, 2009 09:29 (UTC) (Развернуть)
(no subject) - nick_fedchik on Сентябрь, 28, 2009 07:25 (UTC) (Развернуть)
(no subject) - maximkr on Сентябрь, 28, 2009 09:47 (UTC) (Развернуть)
(no subject) - maximkr on Сентябрь, 25, 2009 11:12 (UTC) (Развернуть)
(no subject) - nick_fedchik on Сентябрь, 25, 2009 12:21 (UTC) (Развернуть)
Nick Fedchik: Crazy Nicknick_fedchik on Сентябрь, 25, 2009 10:55 (UTC)
Пример ChangeLog-а
Пример ChangeLog-а (журнал изменений)
http://www.mantisbt.org/bugs/changelog_page.php
и RoadMap-а (план работ)
http://www.mantisbt.org/bugs/roadmap_page.php

Nick Fedchik: Glasgownick_fedchik on Сентябрь, 25, 2009 10:57 (UTC)
Re: Пример ChangeLog-а
Чего мне не хватало в их Журнале, так это выборка за период, например я хочу посмотреть в пятницу перед митингом что было сделано за прошедшую неделю.
Re: Пример ChangeLog-а - maximkr on Сентябрь, 25, 2009 11:03 (UTC) (Развернуть)
Re: Пример ChangeLog-а - nick_fedchik on Сентябрь, 25, 2009 12:18 (UTC) (Развернуть)
Тимур Василенкоtimur0 on Октябрь, 1, 2009 15:38 (UTC)
off
установил сегодня trackstudio попробовать. как я понял, продукт создавался в основном как багтрекер, но мне он интересен для такой работы: на завод приходят заявки от клиентов, в каждой заявке - несколько изделий. мы оцениваем, можем ли мы их изготовить и сколько это будет стоить, что и сообщаем клиенту. если он согласен, то заключаем договор и выполняем заказ. с момента заключения договора все просто - стандартный функционал ERP-системы; меня интересует trackstudio для первой части задачи - для обработки заявок. все равно 90% их идет в корзину - нагружать ERP этим смысла нет; к тому же заявки достаточно индивидуальны - это не совсем линейный бизнес-процесс, там маршруты могут быть очень причудливыми. самое оно для системы управления инцидентами. есть одна трудность - членение на задачи. в начале у нас есть один объект - письмо. потом он распадается на несколько - по числу содержащихся в нем изделий. в конце они собираются вместе (для ответа на письмо), но иногда не все - к примеру, по одному из изделий клиент прислал неполный чертеж и отвечаем пока по остальным изделиям, а с этим - ждем. как можно организовать это соотношение объектов? иерархия - группа/элементы - не совсем подходит, т.к. в конце может все собраться не полностью, в одном заказе часть, и в другом - остальное (или в двух-трех).
Максим Крамаренкоmaximkr on Октябрь, 1, 2009 16:58 (UTC)
Re: off
Да, для подобных задач (автоматизация неосновных бизнес-процессов, не связанных с IT) TrackStudio используется очень часто, особых проблем не ожидается.

Ваша ситуация с членением на задачи хорошо укладывается в иерархическую модель TrackStudio. Т.е. приходит письмо, его forward-им в TrackStudio и создается задача типа письмо. В этой задаче создаем несколько задач типа "деталь", назначаем там ответственных и разбираемся с ними. Как со всеми (или не всеми) деталями разобрались - отвечаем по основному письму и закрываем соот. задачу.

Кроме того, задачи-детали можно переносить между задачами-письмами (например, если решили делать, но в рамках другого заказа).

Еще можно делать двухсторонние связи между письмами и задачами и полностью обойтись без иерархии. Например, все письма собираем в одной папке, все детали - в другой, каждая задача-письмо указывает на 1 или несколько задач-деталей, при этом если зайти на задачу-деталь, то будут автоматически видны все задачи-письма, которые на нее ссылаются. Такой подход может быть удобнее и в плане обеспечения безопасности - люди которые оценивают возможность изготовления детали могут не иметь доступа к задачам-письмам, они будут видеть только ссылки-номера, вроде #123.

Re: off - timur0 on Октябрь, 1, 2009 19:15 (UTC) (Развернуть)
Re: off - maximkr on Октябрь, 1, 2009 19:20 (UTC) (Развернуть)
Re: off - timur0 on Октябрь, 1, 2009 19:34 (UTC) (Развернуть)
Re: off - maximkr on Октябрь, 1, 2009 19:37 (UTC) (Развернуть)
Re: off - timur0 on Октябрь, 1, 2009 19:46 (UTC) (Развернуть)
nafairanafaira on Октябрь, 2, 2009 05:56 (UTC)
А почему не запустить публичный багтрекинг собственно на TrackStudio, чтобы зарегистрированные пользователи сразу туда ставили свои требования. Это еще и как демо-версия вполне пойдет. Просто сделать юзера, который тока смотрит и все...
Максим Крамаренкоmaximkr on Октябрь, 2, 2009 07:06 (UTC)
А мы делали такое для приема от клиентов задач по заказной разработке. В итоге как слали все почтой/аськой, так и шлют.
nafairanafaira on Октябрь, 2, 2009 07:17 (UTC)
А не надо принимать по почте/аське. Особенно по аське ;))