On Mon, Feb 20, 2012 at 12:14 PM, Ian Wild <[email protected]> wrote: > On Mon, Feb 20, 2012 at 8:01 PM, Felix Schwarz <[email protected] >> wrote: > >> I think that's overly simplified. As an system administrator the most >> important source of information is email (e.g. customer reporting a >> problem). >> So replying to an email just makes sense because I'm interacting with my >> mail >> client anyway. >> >> Indeed - We have implemented this internally and that's one of our key use > 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. >> However I'd agree if you say that the information in Trac's notification >> emails are not optimally layed out for that task. > > > 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.
