Hey guys,
Sorry for reviving a ten day old thread, but I think it’s a really interesting idea.
As Alan said, it’s a tough problem to crack for a lot of reasons. Many of them technical, but more of them human interaction related. Technical problems are easy…you just have to write the code. The human problems are harder, and that’s the majority of this feature.
NOTE: I’m just think out loud here, because this is a great idea, and I think going forward it is exactly the kind of thing we want to address. Things that are hard to solve for any individual hosting company, but might be easy if we all sit down and come up with a good, simple, and elegant design. One that either backs up to an existing issue tracking product, or is implemented in such a simple and clean manner that it doesn’t eat all of our time.
So, what’s the problem really look like?
First up, we have to solve the problem of “who wants this issue?” Alan explained this problem very well, so I’ll just expand on that and suggest a possible solution.
When an end user, like a customer at your hosting provider, asks a question, it’s probably not really something we here at Virtualmin can answer. It’s probably “What are the correct DNS servers for my domain?” or “How do I update my billing address?” Even if it is “How do I create a mail alias?”, and we can answer it and are happy to do so, the hosting provider probably wants those responses to come from their email address and with their own personal touch.
So, we need a way for the built-in issue system to automatically determine who to notify about the problem, and whether to store it in the local issue tracker or in the Virtualmin.com issue tracker.
If it’s a domain account holder or a mailbox account holder, it stays local (or goes to the hosting providers public instance). If it’s the system administrator, it comes here to Virtualmin.com. Seems easy, but is gonna be a source of confusion…what if there are multiple sysadmins and they want to use the tracker for their own local stuff. We use our bug tracker here to talk to each other all the time, as it’s just the best way to deal with a lot of communication.
As Stephan noted, we don’t need any fields for the user to fill in version/OS/contact/etc. information because we already know it all. This is a beautiful thing, and really simplifies the issue filing process for users–it becomes “Describe your problem?” and then all subsequent responses are discussion and finally a “Close this ticket”. Most issue trackers are way too complicated for normal users to get any value from, and part of that is because the issue tracker has to gather so much information that the user is not well-equipped to provide. Our issue tracker here at Virtualmin.com is no exception. It’s stupidly complicated…it’s just an instance of the bug tracker configured slightly differently. It’ll go away when we move to the new website, and all things will be handled via a single bug tracker (unless and until we get something like what we’re talking about here implemented).
So, really, the hard problem is just “Who needs to know what?” Some issues from customers might need to be upgraded to a Virtualmin issue, since they may very well be bugs in the software that we need to know about. And sometimes we want to hear about it when the user is just confused–we view having a confusing interface a bug, but sometimes we don’t know what is confusing unless someone tells us. We’re kinda stupid that way.
I spent some time several months ago looking at the existing issue tracking products and they are all way too heavy for what we’re talking about here, unfortunately. They are all way too flexible.
The good ones in Perl are huge: RT and OTRS. There is a command line one called BATTS that could probably be modified to fit our requirements, but it’d probably be faster to start from scratch. I believe there’s probably a sweet spot solution that involves a mailbox with a few custom headers: X-Issue-Status: Resolved, X-Issue-OS: debian-linux, etc. Then we’d have a modified mailbox viewer that allows searching based on those tags, and a custom mail filter that would parse the messages looking for special tags–so one could open/close/discuss an issue via email and it would all work in the web UI.
We already have a great mail client in Usermin. So we’d just need to modify it to accommodate the needs of an issue tracker. Add tabs for “Closed” issues and a search box that knows about the special headers. Also would need an “Ask a support question” button instead of “Compose”, and compose form would be very different from the current one.
Hmmm…I wonder why no one has built such a tool before? Writing custom interfaces to the data would be easy because there’s already great MIME and email libraries out there. You could even do a rich desktop UI for it and connect via IMAP.
I’ll have to do a little experimenting. This might just turn out brilliant, if I do say so myself…
Anyway, I should warn that this is a pretty big project, even though I use the words “easy” and “simple” when talking about it. It still has a lot of components, and they’d have to integrated cleanly into whatever kind of environment it’s deployed into (so, MTA agnostic…though we’ll have to require that delivery does go through our filter, if mail support is desired).
So, it won’t be happening next week. But I feel pretty good about it, and it feels like a really interesting problem with some really cool possible solutions. I’ll try to get back to it in a few weeks.