bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Wild <>
Subject Re: Bloodhound thoughts
Date Mon, 20 Feb 2012 20:14:53 GMT
On Mon, Feb 20, 2012 at 8:01 PM, Felix Schwarz <
> 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.

I can also see value in allowing for non-authenticated forms and other
systems to be used to raise tickets with this as the gateway. It's easy to
do that using some easy formmail, or even something like the Google form
tool in Google Docs.

> 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'm planning to reach out to a couple of the GPL Plugin developers this
week to see how they would feel about allowing Bloodhound to use these
plugins under a different license. Hopefully we'll be able to find a way
forward on that, but if not I would think it's inevitable that we'll need
to build-in equivalent functionality.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message