Registering bugs by email

Question

What is a best way to parse an email with bug description. One client decided recently that it would be nice for user to be able to send an email to known mailbox and a bug would be registered in bug tracker (not exactly bu close).

The problem is bug description has lot of fields like dates, times, descriptions, comments, losses, attachments etc. Relying on user to use some specific mail format is not the smartest thing to do.

The question is how could one parse email to get all needed information. The format should be not to strict, but enough to guess what fields mean what. I would also be interested to hear both correct and easiest solutions for this.

P.S. Actually this feature was requested by a bank. They have a public mailbox where clients would sends discovered issues. The problem is to get as much information from these letters before bank employee will actually look at it.

Answer 1

We do something similar to this with RT, however the email isn't really parsed. All the emails go into a single queue where it is evaluated by our IT staff. Basically, the parsing is done by humans - they modify the ticket to have as much information as they can glean from the email.

You're unlikely to get users to adhere (correctly) to any special syntax or formatting you come up with - unless they are employees, highly trained, or have some incentive to follow your rules.

Another option would be to have the initial email respond with an email that is formatted as a questionaire. In other words, the user writes an initial bug report and immediately (or as soon as your email server can respond) gets back a "thank you - can you provide more info" message with prompts for more info. You could then parse that email and have it populate your bug tracking system with more accurate info,

Good luck! Sounds like a cool idea!

Answer 2

Categorizing a bug based on freeform text is a difficult proposition. Very little besides the defect submitter name and the date the bug is reported is easily gleened from an email. Is there a reason you are limiting yourself to email? If you provide a form to submit the bugs via a webpage you can categorize the defect/bug based on dropdown menu items you present to the user. In addition you can point them to common answers in a dynamic information portion of the page. Have a look at Apple iTunes support request page for a slightly annoying but effective method to force the user to give you decent information. Banking applications are not a good domain to allow ambiguity nor are they a good domain to have multiple rounds of communication.

Answer 3

FogBugz has the ability to monitor an email address and add emails sent to that address as a new FogBugz cases.

There's also a feature called ScoutSubmit that accepts HTTP GET arguments and uses those to submit a new case. Very handy for having a application automatically submit bug reports from the field.