On 20/02/12 23:18, Robert Rose wrote:
On Mon, Feb 20, 2012 at 12:14 PM, Ian Wild<[email protected]> wrote:
cases for the project in question. We get:
* Recording of an email discussion, including the ability to quickly
contribute from a mobile device (no interface can achieve that in a
low-data environment better than email).
* Easy integration with third party notification systems that generate
alerts (eg mails from monitoring tools like Nagios)
* Very easy ability to turn an email thread with history into a ticket
* Very easy ability for anyone in the business with no training and no
hassle to raise a ticket
It's not right for every project / case we deal with, but that model is
working very well for us in one of our internal projects at least.
Just to add to what Ian wrote:
It's definitely not right for everyone, but I would recommend it be
included out-of-box (disabled by default?) if possible.
Recording discussion is a big thing for my group. Where I work, we
consider it shameful to discuss a trac ticket over email and not "on
the ticket," we want an archive of every discussion so that we can
refer back to it later. And because we require all svn changes to
link to a trac ticket, its great because you can query svn/trac and
read the discussion that led to a line of code being written. The
problem is it's just too easy to reply-all to a ticket update email,
so email discussions happen more often than we would like. And if
you're on a mobile device, or you're not logged into the VPN, it means
you're less-likely to take part in the ticket discussion.
We also would like to use trac emails to modify the state of a ticket,
not just add discussion. We have two other (non-trac) issue
management systems that do this, and its very handy. For example, if
your ticket workflow requires an approval before the ticket goes on to
the next state, you can have the approver just reply to the ticket
with "approve" and then the state gets updated.
Quite true. Is it acceptable in todays day and age to default to HTML
styled emails? Is there even any point in providing a text alternative
(Surely not even the geekiest geek is still using Pine?).
I don't personally mind the non-html emails that much. The trick with
HTML email is getting it right for all email clients, especially
mobiles. If Bloodhound does HTML email, its got to work on an iPhone.
One nice thing about HTML email though is you could run the ticket
description through a fancy diff tool that paints the text red/green
for changes, rather than a giant before/after block (that's not very
useful in email). See
http://code.google.com/p/google-diff-match-patch/
We also modded our trac instance to reverse the order of the email
updates, so changes are first and ticket state is on the bottom.
I have to say that I am very much in favour of being able to use email
to interact with Bloodhound. Clearly we would expect Bloodhound to have
the ability to notify interested users of ticket changes so that they
are not required to remember to look at tickets. Taking that a step
further to allowing users to raise and modify tickets by email does not
seem particularly controversial.
I am also in favour of being able to modify ticket state by email.
Installing by not enabling is a possible strategy. I don't yet know if
we will be able to provide it in a fully working state anyway.
Cheers,
Gary
