bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary <>
Subject Re: Bloodhound thoughts
Date Tue, 21 Feb 2012 02:26:33 GMT
On 20/02/12 23:18, Robert Rose wrote:
> On Mon, Feb 20, 2012 at 12:14 PM, Ian Wild<>  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
> 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.


View raw message