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. 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. Ian
