Asking Questions

    From KDE UserBase Wiki
    Revision as of 17:32, 21 October 2011 by Yurchor (talk | contribs) (Marked this version for translation)
    The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

    Using IRC to get help

    Here are a few tips on asking questions, especially in #kde on Freenode, in a way that is more likely to get answers:

    • Don't ask to ask, just ask: the irc.freenode.net channel #kde is a user support channel, so we expect your questions - go right ahead .
    • Be ready with any relevant details about your system: What distribution (what version?), what version of KDE you are running, how you installed it and so on. You probably won't need to give all of this information straight away, but you should have it available in case someone asks.
    • Try to do some troubleshooting yourself before asking: Google is your friend (entering error messages into Google often finds something useful). You should take a look at Troubleshooting KDE Problems - the advice there is probably what you'll be told in #kde anyway, so try it first .
    • Also, try to make sure that the problem you're having is a problem with KDE and not some other component of your system (for example, a problem with X or with ALSA). If possible, try an alternative, non-KDE application to see whether the problem also occurs there. Of course, if you're not sure, please ask.
    • Make sure that you have Read The Fine Manual and the Troubleshooting pages. Although not every question is answered there, many are. If that doesn't produce a result, try asking it on the forum. If the discussion brings up interesting information you might add it to UserBase, so that it can help others.
    • Be prepared to wait! Often on IRC, someone will notice your question a little while after you ask it, so wait around for a while after you ask. There's nothing more annoying than typing out a long answer for someone, only to realise that they left 3 minutes after asking their question!
    • If you don't get an answer on #kde, you can also try the channel for your distribution (eg, #suse, #kde-freebsd, etc), or an appropriate mailing list: see lists.kde.org or forum.
    • Above all, be patient and polite. Remember that the people who help are all volunteers, and could be spending their time doing other things than helping.

    If your problem is with sound in KDE, you might want to first read Sound Problems.

    If your question relates to development, please see KDE TechBase's contribute page

    The forums

    Another great place to get help is the KDE Community Forums. It is always a good idea to search the forums first. Maybe your question has already been answered. If not, find an appropriate forum and start a thread. Don't expect an immediate answer, but remember to come back regularly to participate in the discussion as it gets going. Remember that the forums are run by users like yourself.

    Most distributions have forums of their own; these can also be valuable. The web pages of your distribution should provide links to its forums.

    Operating-System-Specific Questions

    For questions relating to the desktop use of KDE with a particular OS, you can try the above methods, but unless the question directly involves KDE or KDE/GNU/Linux you are unlikely to find the answer. If your question does not directly involve KDE, please do not post the question on the "normal" KDE mailing lists. Examples of questions that do not directly involve KDE: my sound card does not work. In that case, please direct your questions at sites devoted to helping users of that system. For example, for GNU/Linux questions you may try looking at www.linuxnewbie.org or www.linuxnewbie.com, or the kde-linux mailing list mentioned above.

    If you are not using GNU/Linux, you might want to try the kde-nonlinux (subscribe) mailing list. Also particularly useful are searches on your favorite search engine, such as Google, and searches on the Usenet archives.

    In addition, many OS distributors have their own mailing lists which can address distribution-specific issues. You can find out more about these mailing lists at your distribution's website.

    If you are searching for packages you may consider checking the ftp servers for your distribution, including the "contrib" sections, as well as indexing servers such as rpmfind.net.

    Reporting KDE Bugs

    Reporting bugs is a small but valuable contribution to KDE, and there's a website where you can report any bug or feature request you have about KDE: bugs.kde.org. The only requirement on your side is basic knowledge of English. With that, and following some additional guidelines, you'll be able to report helpful bug reports and thus help the whole KDE community and yourself.

    The first thing you need is to open an account in the website. You can start here. Once you have a validated account, you can report.

    There are usually two different situations to report a bug:

    • You notice something which is not working properly or not working at all, a bad design, a missed functionality... If this is your case, open the application Help -> Report Bug... menu. You will then be guided to bugs.kde.org. Some information will be automatically picked up, like the application version number.
    • Your program disappears and another window appears named "The KDE crash Handler". Don't get scared! You will be guided to efficiently report this crash. The link in the dialog "Learn more about bug reporting" will explain you the process. If you choose to report the problem, click on Report Bug and an assistant will guide you through the steps. The requisite to report a crash is to have your distribution debug packages installed in order to provide a valid backtrace.

    And these are a few tips on how to write good bug reports:

    • Write it in English. You can switch every KDE application language through Help -> Switch Application Language..., so go there and choose American English as the primary language. Then restart the application. That can help you in explaining what happens.
    • Be specific. One bug per report only! Do not mix different problems in the same report.
    • Be clear. Explain the steps that lead to the bug so that we can reproduce them easily.
    • Include screenshots: a picture is worth many words so attach a screenshot to the bug report. You can use KSnapshot to take screenshots. Also, do not link to an external web link which can expire, use the Attachments link at the bottom of the bug report.
    • Include the backtrace within the bug report as a comment, it makes it easier to find duplicates for us (do not attach the backtrace as a text file).
    • Clearly separate facts from speculation: only describe what happens. For a design problem, include a mock-up if possible.

    If you are testing trunk or the beta, if you kept your precedent settings, sometimes you will want to check with a new user or by setting a new $KDEHOME (and restarting your user). Do not delete your $KDEHOME as you will maybe need the current files to compare with the new ones and also you would lose your settings!

    Also notice that Forums have a section about Beta Releases.

    An good guide to bug reporting can be found here.


    How to open a console

    Typically when reporting a problem in IRC or on a mailing list, your helpers will ask you to open a console. A console is a text-based window that you can use to give commands for your computer to execute. You can open a console by typing ALT_F2. An input box opens. Type the following to open a console:

    konsole

    If this does not work, you may not have it installed. In this case, type ALT_F2 and input:

    xterm


    Back to Getting_Help