incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Rose <robert.w.r...@gmail.com>
Subject Re: Bloodhound thoughts
Date Mon, 20 Feb 2012 23:18:09 GMT
On Mon, Feb 20, 2012 at 12:14 PM, Ian Wild <ian.wild@wandisco.com> wrote:
> On Mon, Feb 20, 2012 at 8:01 PM, Felix Schwarz <felix.schwarz@oss.schwarz.eu
>> 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.

Mime
View raw message