Do we need a tool to help users providing information on their system?

Question

As you all know, a lot of questions on the site are being asked without proper information. For new or inexperienced users facing an issue, this is something I do understand. However, no matter how well we are trying to help them, a lot of questions will be cluttered with several comments asking for more information and the OP does not do exactly what we ask (e.g. dpkg -1 rather than dpkg -l), or replies in a comment similar to "I'm new to Ubuntu, I don't know how to do that...".

This is not efficient, it's discouraging a new user to run terminal commands, it's taking a lot of time to teach users how to do stuff in the terminal, etc.

That's why I was thinking about a dead simple system information tool, completely designed for use with AskUbuntu (or even Ubuntu forums). On the chat, I've had a nice discussion (starting here) on this with Alvar and this made me realize I had to post this on Meta to ask your thoughts on this. I may have missed another (failed) attempt in the past, or some of you might have serious concerns about the practical issues we will then face with it.

I'm posting my rough idea as an answer.

I'd like to keep this discussion within these boundaries (else, it would be going nowhere) before we're already designing and coding it:

• Should we even bother creating one? Or is there a tool out there already?
• Basics on UI: Wizard/non-wizard, One set of checkboxes or a "nice" UI, etc.
• Basics on non-functional requirements: should it run on 10.04? should it be a "portable" app without external dependencies?
• Basics on functionality to include: automatic upload of info? even automatic attach to question? how much of heuristics? warn the user about current state of the system?
• Basics on safety: should it have the ability to do (usually harmless) changes? (modprobe this, restart that, run apt-get update, etc.)
• What's are the musts, shoulds, coulds, wishes?

Answer 1

Yes, we should have one. A simple one.

Audience

• New and inexperienced users.
• Ready for first encounter with Ubuntu.
• Ubuntu Desktop use related.
• Running any supported Ubuntu release.

Idea / recipes

1, one, ONE single functionality: gather the information requested for in the Q. Following the KISS principle from head to toes.

A set of extendible recipes (or scriptlets) to gather a set of information and guide the user in what to gather. See below for some examples (mock-up). The tool may ship with let's say 50-200 common ones and they consist of four things: title, category, description, what/how to gather.

Experts on AU just ask for information in plain English and the tool is able to suggest the right recipe which the user selects based on words that actually exist in a dictionary.

---

mock-up

A very rough idea of what's in my head, mocked up quickly, should look a lot nicer after some UI designer created nice graphics:

Note (not yet drawn): the description of the recipe selected should be shown in the middle (now below the search suggestion box) along with a button "Yes, this one!", which will add it to the list on the right.

---

musts

• A dead simple, clean and user friendly UI.

• Limit it to what the user specifies (what is being requested for).

• Transparency to the user. What is being gathered, and what isn't. E.g. description on recipe List of installed packages should be like this:

  This gathers the state of all known packages on your system. It does not include personal information, but it may reveal some of your personal preferences.

• Ability to run on unsupported releases, with just one message: "You're running an unsupported release."

• Static binary "portable" "runnable" version as well as proper .deb. Ship stuff we rely on, but which might not be available on all the systems.

• Tested all the way down. Not crashing. Ever.

shoulds

• Finding the right recipe(s) should work much like Synapse (image) or the HUD (image).

• Use tools already available to do this job. E.g. Apport, as suggested by rafalcieslak.

• A little bit of heuristic to ease the use. For example, don't even show a "save to file" button if it's connected to the internet and vice versa.

• Basic integration with AU if internet connected. Upload button for large amounts, copy/paste Markdown for small amounts.

• Ability to guide the user in transferring the output via a flash drive to another computer in case he's not connected. This includes cross-platform awareness (e.g. CRLF-line-endings) as the user might only have Windows to boot with an internet connection.

• We maintain the set of recipes/scriptlets in the community and we can accept pull requests for improvements/additions. (see also could-have online database below)

coulds / future ideas

• Hint some possible relevant recipes based on the selection of one or more.

• Translations for the descriptions.

• Minimal bootable CD that can chroot into existing installation.

• An online database with some more and possibly updated bunch of recipes, GPG-signed by multiple trusted members making sure the commands are harmless, safe and useful. Public keys hardcoded into the tool.

• Custom URI schema to use in the comments to ease the user finding the right recipe. It could also be used to specify arguments to the recipe (escaped properly - security concers here!) E.g. ausysinfo://recipe/a123/eth0 to run ip addr list eth0.

• Unfoldable embedded terminal to show the user what is going on in the background, for example: screenshot of system update. This serves both the learning aspects as well as the transparency we need.

don'ts

• "Hi there, what's your issue about?" it's not about issues
• Trying to write code that would save braintime and outsmart humans. People are way smarter to see what's going on. Don't try to fit this heuristics in this tool, please. I want to vote for good answers, rather!
• Dependencies on stuff unavailable desktop images of all supported releases. No shiny new Qt5 stuff, please! That would make it huge if we would need to ship it with it.
• Gathering more information than requested. This will have the opposite result: taking a lot of time going through all the output.
• Running arbitrary commands automated (e.g. fetching commands from comments). Big no-no to shell injection threats!
• Allowing remote access tool. security concerns
• Touching the system. even no to harmless changes
• Attempt to extend a current tool. This is confusing "yes, I started it, but I don't see this button" "you need to install this plugin first...".
• Attempt to include all possible commands we would like them to run. Instead of focussing on the numbers, it should focus on quality of the most common ones. Also, if it covers 90% of the now terminal-tasks, that's already very powerful. Aiming for the 99% is not what I have in mind - would be too hard.

Some of the above don'ts explain some key differences between my idea and George Edison's idea.

Answer 2

I personally think that there is no need for such a tool, for the following reasons:

1. If the tool were too simple, the risk is to collect private information. Apport is a simple tool, and in fact most of the bugs reported using Apport are private.

   If we were using a tool like that, we would need the ability to mark questions private and/or have a special review queue to which only privileged users could have access. This is out of the scope of Ask Ubuntu.

2. If the question requires too many specific information about the user's system, then it should be closed as too localized.

3. I'm against this sentence:

   This is not efficient, it's discouraging a new user to run terminal commands, it's taking a lot of time to teach users how to do stuff in the terminal, etc.

   People are not forced to use the terminal. Most of the problems can be solved using graphical applications. Also, if explaining something takes really too long, either the question is off-topic (as specified in the FAQ) or the Ubuntu documentation should be used.

   The Ubuntu documentation is very well written and when it is incomplete, remember that every community member is free to propose changes. Instead of investing efforts in writing a new tool, you can expand the documentation.

4. People who seek answers generally want to learn, not just to solve their own problems. A tool like the one proposed would hide the operation details, therefore removing the learning part.

   And remember that people who seek answers are not just people who ask questions, this is one of the basic principles of Ask Ubuntu.

Answer 3

Ask Ubuntu is not here to spoon-feed people into troubleshooting their problems. Ask Ubuntu is a Q&A site, people are expected to put effort into making their question useful, well researched, well specified, atomic and most importantly: useful to other people.

I see far too many questions of like this:

Title: Problem with Ubuntu wireless, and WoW

I just installed Ubuntu and my wireless isn't working [without including any details]. Also, can I run World of Warcraft?

Questions like these should be down-voted (or even closed). Don't hesitate to downvote a bad question, it doesn't cost any rep. We're here to help the community first, the lurkers second, and the OP third. Bad questions waste everyone's time, and they turn Ask Ubuntu into a low-quality wasteland.

Now imagine if the question had at the end the output of some sort of Apport-like debugging tool. Would the question be any better? My answer is no: it's still a bad question. It still needs to be edited to cut it down to only one question, to actually specify what the problem is, to demonstrate research, to have a specific question title. Otherwise, it's still useless to other people. For starters, how will other people suffering from the same problem even find the question?

So should we ask users to post the output of some sort of Apport-like debugging tool? Yes, but we shouldn't consider it a good question until the rest of the question is fixed. That debugging information may be useful to editors, but it may not be. Editors are there to improve a medium-quality question. OPs are expected to put a minimum of effort in first, though.

---

Other avenues, such as the ubuntuforums.org or the IRC channel are more appropriate for helping people step-by-step into troubleshooting a problem. I recognise that some people are completely unfamiliar with computer technology, and need that kind of help, and I'm really grateful for those who volunteer their time for them on sites like ubuntuforums.org, or even in person with Ubuntu Hour. On Ask Ubuntu, though, we're trying to reach as many people possible at once, rather than one-on-one support.

tl;dr: adding automatically collected system information doesn't magically make a question a good question.

Answer 4

Note: please see this question for further discussion.

Okay, so I decided to get something started here - no promises since I am a really busy man penguin. Without any further discussion, I present to you "Ask Ubuntu Troubleshooter":

The basic idea is that the application is a simple wizard with dependencies only on the base Qt5 libraries - which are set to be included with the upcoming 13.04 release.

You can find the code for the application here on Launchpad: autroubleshooter

So here's where the community comes in:

What information / command output should be included with each of the options in the screenshot above? Feel free to edit this answer and add to the list below:

• Graphics / display driver
  • lspci
• Wireless connectivity
  • ifconfig

Feel free to add categories too!

Answer 5

There is already a tool in Ubuntu that collects all the data that is useful for developers for having a glimpse of user's system state. Actually, that's what Apport does. Of course we don't need to collect debgging data, but things like package list, module list, or anything we may want can be obtained via Apport.

By no means can we ask anyone to run custom apport commands in order to get it to collect all needed data, this would be too confusing. But it may make sense to reuse existing hooks that can gather the data from system (and can already deal with privacy etc.).

I am not knowledgable about Apport, but I believe it should be easy to create a GUI wrapper over some of it's hooks (or maybe create some new hooks - if needed - that would be managed by apport?), so that we reuse it's potential.