README.md

DISS - Debian Integrated Support System

Project with the ambitious aim to synergistically integrate all Debian's support resources and offer a simple and intuitive interface to well-tested diagnostic procedures.

This is by no means meant to replace, and in fact very much depends upon, all our existing resources. The rationale here is that our system is growing exponentially and we ARE "the universal OS", and that we have limited support resources and not everyone knows how and in what order to use them all properly which results in many well known and easily observable issues.

Issues we want to address

1. Support team burnout through handling repetitively, the known issues we've already solved, having to explain our procedures and policies, and gather (at times pry out) information relevant to the issue at hand, etc

2. User alienation through lack of understanding of the systems, and unproductive interaction with supporters and such. It's been a well documented mindset among some of our best supporters, myself included that we don't really want those kinds of users who are inexperienced because they're just going to become a draw on our resources without contributing to our project. It is also an easily observable FACT that the developers and more experienced users are often the last people to find bugs and issues because they not only tend to be less adventurous in trying different software because they already know what they like and use, and they use it in the way it was intended to be used. It takes someone inexperienced to try out all sorts of options and use things in ways that will uncover obscure errors. This is a valuable commodity to have masses of inexperienced users scouring over our ever growing software base, uncovering issues we would otherwise miss. However we need to ensure that the feedback we get from this valuable resource is meaningful and winds up in the right place without the aforementioned issue occuring, thus we need a filter of sorts that caters to their needs as well as ours.

3. We also need to make sure that all the effort toward those two issues gets utilized. That is we cannot keep having users coming to us with self-interest of solving an issue, and that effort being underutilized because it was not properly documented. Some users come back and share solutions to problems, sometimes we wind up creating a factoid about it, sometimes there ends up being a wiki page, bug report, etc.. but most of the time that is not the case. Furthermore, we don't always know this has been done when the issue comes up again. Our current system relies on our supporters to remember these things, and when those people who remember it are not looking in at the time, we can wind up falling back to issue #2 and alienating our users, or not getting the issue documented or resolved at all, even ineffectively.

Software components

Client/Frontend (readline, curses, GTK, Qt), Diagnostics (Signed diagnostic tree files), Bot (IRC), Server (Issue Tracker)

Client

The client will be a reportbug style wizard that will allow a user to select a program (on lower skill levels, use generic names like "filemanager" and have it automatically detect the actual program name or use a grab fuction where the user can click on a window and get the command) and enter a description of their issue and should have various classes of issues (Network, Sound, Crashes, Build errors, Package system problems, etc.) and optionally a CC address (email can be masked by the tracker with a issue ID and email bounced back to the user for privacy, with ability for the user to then opt out of further CC by emailing the tracker with the ID telling it to stop).

The first tier will then use Diagnostics to perform simple tests and ask further quetions, and gather information and compile a report/log on the issue.