Информация, которая должна быть в системе отслеживания ошибок, теряется где-то в электронных письмах. Что делать?

Question

Я разработчик из небольшой компании, которая собирается взять на себя большой проект.
В настоящее время мы используем электронную почту для отслеживания проблем, и я намереваюсь настроить систему отслеживания ошибок / проблем
(возможно, ошибка genie, mantis или trac - нам нужно что-то на основе веб, php, с открытым исходным кодом , mysql)
У нас есть контроль версий (SVN)

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

Что вы делаете для того, чтобы информация в электронных письмах была доступна людям, проверяющим ошибки в вашем программном обеспечении для отслеживания ошибок?

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

Answer 1

Одна из моих любимых шуток звучит так:

Пациент: "Док, мне больно это».

Доктор: «Не делай этого».

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

Answer 2

Я не использую ни одну из систем, которые вы рассматриваете (нет php ;-), но в системах, которые я использую, электронные письма, отправленные в ответ на любое письмо с трекера ошибок, попадают на сам трекер ошибок (reply-to header), если респондент не совершит очень явного действия, чтобы остановить это; средство отслеживания ошибок делает содержимое письма еще одним комментарием к ошибке, сохраняет вложения как «загруженные файлы» и так далее. Если ни один из трекеров, которые вы рассматриваете, не имеет такой функциональности, я предлагаю вам расширить свои соображения до трекеров, которые имеют ее (любой язык, на котором они реализованы, менее важен, чем их функциональность).

электронная почта слишком важна, слишком полезна, слишком широко распространена; такие системы, как системы отслеживания проблем, ДОЛЖНЫ иметь возможность беспрепятственно взаимодействовать с электронной почтой (входящей и исходящей), чтобы считаться исправными.

Answer 3

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

Я успешно реализовал Близнецы в нескольких магазинах. Это простой в использовании, очень эффективный и бесплатный до 5 пользователей. Но так как вы уже используете SVN, Trac может показаться естественным выбором.

Также см .:

• Какое программное обеспечение для отслеживания ошибок вы используете?

• Инструмент отслеживания / управления проектом

• Каков ваш инструмент отслеживания ошибок / задач?

• Бесплатное / дешевое ПО для управления задачами / ошибками

Answer 4

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

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

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

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