Hi,
we took a different direction here and due to usability consinderations decided not to use package keys for bug-tracker components in the first place since most users don't know what the key stands for the most cases. Instead we decided for more abstract components like "Account Management", "Notification System", "Group Administration", "File System", "Calendar System"...
Next we map these more general components to the actual package. This happens manually at present by the responsible user of the component.
Also we use bug-tracker as a support center and not as a bug-tracking system. Therefore I suggest defining a new initial setting in bug-tracker-procs.tcl proc bug_tracker::get_default_configurations. This was important because the given ones don't really make sense. Too much redundant info like severity "critical" and priority "high" or bug type "sugestion" and severity "enhancement"!
"Support-Center" {
categories {
"Message Type" {
"Problem"
"Suggestion"
"Error"
}
"Priority" {
"1 - High"
"*2 - Normal"
"3 - Low"
}
}
parameters {
TicketPrettyName "message"
TicketPrettyPlural "messages"
ComponentPrettyName "area"
ComponentPrettyPlural "areas"
PatchesP "0"
VersionsP "0"
}
}
So an automated solution would be to offer a message form in bug-tracker as soon as an error occurred, display the more general component name, map to the actual package where the error occurred, autofill the important info like referer, requested url, query, error log and switch on the notification for that user so that he receives a reply once the message was handled.
There is still a problem here. We don't want users to submit a message that was already submitted by someone else. Also beside of real bugs you have user mistakes like duplicate upload of a file. These cases should get caught and if there is a "solution" available displayed before the form is offered.
We could use Patches as solutions for user mistakes. In this case PatchesP has to be 1. So with time we would have a large solution database. A "patch" corresponds to a "solution" in this context.
Some important things that we need consideration:
- automatically turning on notification for users. most forget or don't know that this is required. Otherwise the admin will reply and it will never reach the user.
- automatically close a bug once the admin has resolved the message. Otherwise you will end up with a large list of users who simply don't close them manually. The policy here should be reopen it, if you are not satisfied. The user should also be unsubscribed once the message was closed.
- bug-tracker is awful slow
- maybe with the new AMS package it would make sense to create a new support package from scratch in the long run. AMS would also allow displaying info depending on roles. While the user entry should be displayed for instance automatically filled info like referer, requested url, error log shouldn't be visible for others but maintainers
- I also think that in the longrun it would be important to protokoll more information for forms where errors occur. Like what was the value of the input fields to reconstruct the error better.
- Change OpenACS to display request errors inside the master template.
- maybe it would make sense to define automatically error ids that map to solution ids to better with a 1:n relation since some errors can have different reason and therefore different solutions.
- and finally we shouldn't forget i18n for the solution system. Since there is a 1:1 relationship between package and solution I would use the unique solution id to create a solution message key in the corresponding catalog file with its corresponding solution the maintainer has created and display the solution i18n-ized from the very beginning. This way we can easily spread the solution database simply by committing the catalog file back to cvs. of course we need to ensure globally unique keys which is no real problem.
Greetings,
Nima
