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

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

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

Также см:

• What bug tracking software do you use?

• Project tracking/management tool

• What is your bug/task tracking tool?

• Free/Cheap Task/Bug Management software

Answer 3

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

Пациент: «Доктор, это больно, когда я делаю это ».

Врач: «Не делай этого».

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

Answer 4

Прикрепите по электронной почте (-ам) к проблеме в вашем программном обеспечении для отслеживания ошибок.

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

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

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