Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.
Launchpad Entry: autohelpsys
Summary
This a specification for a help system that finds help on an error message, bypassing the need to search through possibly unrelated webpages.
Rationale
When getting an error message, we typically Google the error message to find out what it means and how to fix it. Unfortunately digging through all the false leads can be time consuming. This inconveniences the user and also means that often the same question gets asked over and over again. Thus a system that allows the user to go straight the the answer would be a boon to both users and developers.
Use Cases
- Alice wants finds tracking down help for error messages time consuming, and wants to go straight to the answer.
- Bob has found a workaround to an obscure error that has been bugging him for months. Bob want a convenient way to share his solution with the world.
Carol is writing a GUI application and is frustrated with the number of people asking the same question over and over. She would like a backend that would allow her to easily link each error dialog to a unique webpage so that she can answer each question once and once only. She adds code to the her dialog class so each dialog has a button that runs autohelpsys with the error message.
Dave has intermittent network access, and would like to be able to download all the answers to common problems. To do this he downloads the archive of answers used by autohelpsys.
Scope
This system is intended to cover virtually any application that writes error messages to stderr. It is also hoped that GUI applications could use it as a back end for providing up-to-date help.
Design
The help system will search "answer files" like the following:
COMMAND=gcc make ld KEYWORD=ld REGEX="ld: cannot find -l(.*)" ANSWER="It appears that the library $1 is not installed. You can search for the library by typing: dpkg -S lib$1"
The system will maintain an index of all answers with a particular keyword. The output to stderr will be broken into words, and for each word, the line will be tested against the REGEX in each answer file for that keyword.
If no satisfactory answer is found it creates a "question file" consisting of the version of the software, version of Ubuntu, the output from stderr and stdout (possibly shortened), and offers to mail this to the autohelpsys mailing list. As autohelpsys grows, the mailing list may be split by command.
When a solution is found, an answer file is posted to the list, which is then added to the archive by a maintainer.
Initially users will keep up to date with the archive using svn up. Later, a more efficient method, perhaps zsync may be adopted.
Autohelpsys could be applied to GUI applications in a number of ways:
- Manually changing the application to have links to autohelpsys in error dialogs.
- Overriding or modifying the GTK Dialog widget.
- Scanning stderr for GUI applications that dump info there.
- Having autohelpsys as a separate application that invites the user to cut and paste the error message.
Initial prototypes need not support localization. If an unlocalized version of autohelpsys becomes popular, the following approaches could could be considered:
- Request untranslated strings, e.g. by passing LANG_C to cli apps
- Build a separate database for each language.
Implementation
Not implemented yet.
Outstanding Issues
Not implemented yet.