It seems to me it might overly complicate things to build the issue tracker into a mail system or into git.
The core functionality of tracking issues can be implemented in a meta-language. For instance, you have one file per issue, and the issue files would look something like this. [timestamp] : Issue #XXX [Issue name] Opened by [user1 name] [timestamp] : Issue #XXX Status set to ABC by [user1 name] [timestamp] : Issue #XXX Description at (/path/to/description) by [user1 name] [timestamp] : Issue #XXX added tags (tag1,tag2,tag3) by [user1 name] [timestamp] : Issue #XXX assigned to [user2 name] by [user1 name] [timestamp] : Issue #XXX related email at (/path/to/email) sent by [user2 name] [timestamp] : Issue #XXX related email at (/path/to/email) received by [exter...@external.com] etc etc. You then have different daemons reading and writing to the file and carrying out various functions. For instance, you have some mailer that reads that an issue was assigned to a particular person, so it knows it should send an email to that person. A CI server could create issues when it detects a regression. Any daemon reading the file should ignore lines it doesn't understand, that way as new features are added to the meta-language the daemons won't break if they don't understand them. Issue files could be stored in a directory structure organised by time. There could be special directories containing symlinks to the issue files, for instance an 'Active issues' directory. Cheers, Alex
