Wie man besser Hilfe bekommt

Ingo Strauch, http://www.the-one-brack.org/, <brack@the-one-brack.org>

Originaldokument: http://www.the-one-brack.org/linux/getting-help_de.html

Copyright © 2005 Ingo Strauch

Historie der Änderungen
Version 1.0 14 Dez 2005 is
Erstfassung

Inhaltsverzeichnis

Motivation
Die häufigsten Fehler bei der Hilfesuche
Suchmaschinen richtig bedienen
An der richtigen Stelle fragen
Die Distribution inkl. Versionsnummer angeben
Fehlermeldungen immer exakt angeben
Hardware-Angaben
Paketmanagement lernen
Anweisungen ausführen
Lösungen posten
Private Kommunikation
Rechtschreibung etc.
Schlußbemerkung

Motivation

Warum diese Webseite? Eigentlich ganz einfach: erstens weil man in Internet-Foren, Newsgroups oder Mailinglisten immer wieder auf die gleichen "Fehler" der Fragesteller stösst. Und zweitens, weil das bekannteste Dokument, das sich dieser Problematik annimmt (How To Ask Questions The Smart Way) viel zu lang ist und sich eines Tones bedient, so dass klar sein müßte, dass die Zielgruppe nach wenigen Sätzen aufhört zu lesen.

Dieses Dokument beschränkt sich der Einfachheit halber auf Linux (da ich das am besten kenne), aber in der ein oder anderen Form gilt das Gesagte auch für andere Betriebssysteme. Konkrete Tipps/Kommandos/Informationsquellen sind mit Absicht hier nicht enthalten. Ich finde es sinnvoller, diese Dinge in ein (noch zu schreibendes) separates Dokument auszulagern, das man dann auch immer wieder als Referenz zur Hand nehmen kann, ohne sich durch Grundsatz-Überlegungen wühlen zu müssen.


Die häufigsten Fehler bei der Hilfesuche

Suchmaschinen richtig bedienen

Mir ist bewußt, dass es oft nicht einfach ist, die richtigen Suchbegriffe zu finden oder die brauchbaren Suchergebnisse aus der Ergebnisliste herauszufiltern. Aber ein paar Grundregeln sollten bereits helfen, in Zukunft schneller Antworten zu finden.

Phrasen lassen sich üblicherweise in Hochkommata (") setzen, dann wird nach genau dieser Wortkombination gesucht. Das bietet sich vor allem für (nicht zu lange) Fehlermeldungen an. Dadurch spart man sich jede Menge Ergebnisseiten, die nur zufällig die gesuchten Wörter, aber ohne Zusammenhang über die gesamte Seite verteilt, enthalten. Bekommt man viele Treffer zu einem ganz anderen Themengebiet, kann man durch Voranstellen eines Minuszeichens bestimmte Begriffe von der Suche ausschliessen.

Suchmaschinen liefern mehr als nur eine Ergebnisseite. Auch wenn man sich daran gewöhnt hat, viele Dinge gleich unter den ersten 5 Treffern zu finden, ist es nicht zu viel verlangt, mehr als nur die erste Ergebnisseite anzugucken und gegebenenfalls auch mal einem Dutzend Links zu folgen, bevor man aufgibt. Und wenn man schon nicht auf Anhieb das Gesuchte findet, kann man immer noch mal andere Suchbegriffe ausprobieren oder sogar eine andere Suchmaschine (ja, es gibt mehr als nur Google).

Generell bleibt zu sagen, dass in vielen Fällen die Lösung schneller per Suchmaschine zu finden ist, als in Foren/Newsgroups eine brauchbare Anfrage zu verfassen und auf eine brauchbare Antwort zu warten. Es passiert oft genug, dass man aus dem Text eines vorschnellen Fragestellers nur zwei oder drei signifikante Begriffe in eine Suchmaschine tippen braucht, um genau die richtige Lösung/die gesuchte Information/das gesuchte Programm unter den ersten drei Treffern zu finden.

Ach ja, je nach Anzahl der Mitglieder des Forums/der Newsgroup/Mailingliste und der Komplexität des Problems ist es durchaus normal, dass die erste Antwort auf sich warten lässt bzw. dass es dauert, bis die richtige Antwort kommt. Wie dringend das Problem für einen selber ist, hat nun mal keinen Einfluß darauf, ob und wer eine Antwort weiss. Also nicht einfach nur abwarten und womöglich völlig verfrüht Antworten einfordern ("will mir hier eigentlich keiner helfen?"), sondern parallel weiter aktiv nach der Lösung suchen.

An der richtigen Stelle fragen

Man sollte seine Fragen thematisch richtig einordnen, d.h. an den Stellen fragen, die auch dafür "zuständig" sind. Auch wenn z.B. in anderen Foren schlicht mehr Leute unterwegs sind, wird man in spezialisierten (Unter-)Foren deutlich schneller kompetente Antworten erhalten. Erst recht, wenn das gut besuchte Forum, in das man halt einfach so gepostet hat, einem ganz anderen/viel allgemeinerem Thema gewidmet ist. Eine gute Antwort ist besser als 10 falsche bzw. als 50 mal "keine Ahnung, woran das liegen könnte".

Nicht nur das richtige Einordnen der Frage hilft, auch ein aussagekräftiger Titel ist wichtig. Damit verbessern sich die Chancen, dass diejenigen, die etwas zur Problematik sagen können, auch auf die Frage aufmerksam werden. Die meisten Leute dürften nicht genug Freizeit bzw. ausreichend andere Interessen haben, als dass sie in jeden Thread/jede E-Mail des Internets reingucken können und wollen.

Und wenn man schon den richtigen Platz für seine Frage gefunden hat (Projekthomepage, Usergruppe zum Thema, etc.), kann man dort auch gleich erstmal nach vorgefertigten Hilfen gucken, so dass sich eine eigene Frage evtl. erübrigt.

Die Distribution inkl. Versionsnummer angeben

Auch wenn die Lösung eines Problems in den meisten Fällen für alle Distributionen sehr ähnlich sein sollte, bricht man sich keinen ab, seine Problembeschreibung mit einem Satz zu beginnen, der die eingesetzte Distribution und deren Version angibt. Vielleicht ist das Problem gerade für diese Distribution/Version bekannt und die Lösung bereits bestens dokumentiert. Genausogut könnte sein, dass eine Distribution komfortable Werkzeuge für die Aufgabe bereitstellt, während für eine andere eine ausführlichere Anleitung "zu Fuss" nötig ist (womit man auch schon mal eine Stunde Arbeit einsparen kann). Spätestens wenn man lange verzweifelt einen Lösungsvorschlag nicht nachvollziehen konnte, weil der Hilfesteller mangels genauer Information einfach den Lösungsweg für seine Distribution angegeben hat, sollte man einsehen, dass man besser 10 Sekunden investiert hätte, diese Information gleich zu Beginn mitzuteilen.

Alle Distribution betreiben übrigens so etwas wie eine FAQ, Errata-Seiten, eine Support-Datenbank und/oder Knowledge-Base. Die betreffende Seite zur eigenen Distribution gehört in die Bookmarks und sollte eine der ersten Stellen sein, bei denen man nach Lösungen sucht. Die werden nicht zum Spass gepflegt und wer sonst ausser dem Hersteller sollte bei bekannten Problemen genau sagen können, was zu tun ist?

Zu guter Letzt sollte man tunlichst vermeiden, so etwas zu schreiben wie "Ich habe Linux 10.0". Man wird nur Spott und Belehrungen ernten, da "Linux" streng genommen nur der Betriebssystem-Kern ist. Das, was man letztendlich benutzt, ist eine Distribution mit jeder Menge Programmen um diesen Kern herum. Man hat also beispielsweise "SUSE Linux 10.0", aber der dabei eingesetzte Kern trägt die Versionsnummer "2.6.13" (und das ist ziemlich weit weg von 10.0).

Fehlermeldungen immer exakt angeben

Fehlermeldungen nicht zum Wegklicken da, sondern dazu, bei der Hilfesuche wortgetreu wiedergegeben zu werden. Idealerweise kopiert man den Fehlertext in die Zwischenablage und fügt ihn unverändert in die E-Mail/das Forum-Posting ein (ok, Passwörter sollte man schon herausnehmen). Wenn sich der Text nicht markieren läßt (soll vorkommen), dann etnweder abschreiben oder einen Screenshot anfertigen. Es schadet auch nicht, Fehlermeldungen, auch wenn sie etwas länger sind, in Ruhe durchzulesen ohne gleich in Panik zu geraten. Auch wenn es durchaus Fehlermeldungen gibt, die für Laien unverständlich sind, sind oft genug welche dabei, die beinhalten, was man konkret zur Behebung tun bzw. wie man der Ursache auf den Grund gehen kann.

Außerdem ist es sehr wichtig, präzise zu beschreiben, was man gemacht hat (das komplette Kommando, die Abläufe bis zum Problem, etc.), was daraufhin passiert ist und was eigentlich hätte passieren sollen. Sollte es mehrere Meldungen geben, sind in der Regel alle wichtig. Gibt es gar keine, hilft es häufig, das betreffende Programm nicht aus dem Startmenü oder über ein Icon aufzurufen, sondern durch Aufruf aus einer konsole heraus. Dort werden üblicherweise viele Meldungen ausgegeben, die man sonst nicht zu sehen bekommt.

Gut gemeinter Rat: sollte die eigene Fehlerbeschreibung Wörter enthalten wie "irgendwie", "was mit ...", "geht aber nicht", etc. kann man davon ausgehen, dass sie unbrauchbar ist und man eh nur die Aufforderung ernten wird, genau zu beschreiben, was man gemacht hat, was dann passiert ist (oder eben nicht passiert ist) und welche Fehlermeldungen man erhalten hat. Dann kann man das auch gleich richtig machen.
"Geht aber nicht" könnte z.B. bedeuten, dass der gesuchte Menüpunkt/das gesuchte Programm nicht existiert, dass das Programm sang- und klanglos abstürzt, dass gar keine Reaktion erfolgt, dass der Rechner runterfährt, dass beim Eintippen von Passwörtern keine Sternchen erscheinen (das tun sie in manchen Fällen absichtlich nicht!) oder dass eine hoffentlich aussagekräftige Fehlermeldung kommt.

Hardware-Angaben

Auch hier kommt es hauptsächlich auf eins an: Präzision. Außerdem: lieber zu viel Information als zu wenig. Völlig unzureichend ist es z.B., keine weiteren Angaben zu machen als "ich habe den Aldi-Rechner vom letzten Jahr". Woher soll man wissen, welche Hardware darin steckt, wenn man nicht zufällig genau das gleiche Modell hat? Ähnliches gilt für Produktbezeichnungen. Zwar ist es sinnvoll, die genaue Modell-Bezeichnung anzugeben, aber es empfiehlt sich immer, noch ein paar Worte darüber zu verliegen, um was es sich handelt. Oder ist nach einem "meine Logi XYZ-0815 funktioniert nicht, obwohl ich schon alles versucht habe" klar, ob es sich um eine Maus oder doch um eine Webcam handelt?

Weiter zum Thema "lieber zu viel Info als zu wenig" ist zu sagen, dass beispielsweise bei Peripherie-Geräten die Anschlußart anzugeben ist (USB, Firewire, Ethernet, PS/2, etc.), was auch teilweise für interne Komponenten gilt (z.B. IDE oder SATA bei Festplatten). Bei manchem Gerät ist es erstmal wichtig, ob es sich um eine interne oder externe Komponente handelt. Gehören mehrere Komponenten zusammen, sollte man gleich die Details zu allen angeben, auch wenn man primär nur eine für den Problemverursacher hält. Das gilt z.B. für Monitor und Grafikkarte, wenn das Problem darin besteht, dass man die grafische Oberfläche nicht ans Laufen bekommt.

Bei Linux ist es i.a. wichtiger zu wissen, welcher Chip verwendet wird, und weniger, wer das Gerät als Ganzes hergestellt hat. Also dass es sich um einen Radeon 9600 Grafikchip handelt und nicht, dass die Grafikkarte von Sapphire ist. Oder dass sich auf der WLAN Karte ein Prism Chip befindet und nicht, dass sie von D-Link ist. Wenn es also geht, zu Hersteller und Modellname immer auch gleich angeben, welcher Chip verbaut ist (auch wenn diese Informationen nicht immer in großen Lettern auf der Verpackung stehen).

Paketmanagement lernen

Es empfiehlt sich, möglichst frühzeitig das Paketmanagement kennenzulernen, das die eigene Distribution benutzt. Gerade Umsteiger aus der Windows-Welt, die sonst nur den Umgang mit einer "setup.exe" kennen, sollten sich ein wenig Zeit nehmen, die Paketverwaltung unter Linux zu verstehen. Leider ist es etwas verwirrend, da es mehrere Paketformate gibt (DEB und RPM z.B.), manche Software mit einem Installer änlich einer "setup.exe" daherkommt und wieder eine andere aus den Quelltexten kompiliert werden muss. Und in einigen Fällen hat man sogar die Möglichkeit, sich bei einem Programm für alle drei Arten entscheiden zu können.

Die wichtigste Lektion, die es zu lernen gilt, ist dass man erstmal Software aus dem Fundus installiert, die die Distribution selbst anbietet. Dazu gehören die Installations-Medien und die Webseite/der FTP-Server der Distribution (am besten einen Mirror in der Nähe benutzen!). Diese sind über die vorkonfigurierten Werkzeuge zugänglich, mit denen man umgehen können sollte. Wenn man auch sonst nicht gerne Dokumentation liest, in diesem Fall ist das eine gute Investition, um sich jede Menge Frust zu ersparen.

Anweisungen ausführen

Viele Leute neigen dazu, die angebotene Hilfe nicht effektiv zu nutzen. Dies äußert sich in mehreren Symptomen.

Wenn man gebeten wird, eine Reihe von Schritten durchzuführen oder die Ausgabe mehrerer Befehle zu posten, dann ist das genau das, was man machen sollte. Und nicht, sich den trivialsten Schritt/Befehl aussuchen, und nur den ausführen. Im allgemeinen hat es schon einen Sinn, Probleme in mehreren Schritten anzugehen. Bekommt man z.B. drei Anweisungen mitgeteilt, macht es wenig Sinn, sich nach jeder einzelnen davon sagen zu lassen, dass das Ergebnis der restlichen Schritte noch aussteht.

Viele Menschen neigen dazu, im Verlauf einer Problemlösung nur einem Hilfesteller zu folgen. Das mag Sinn machen, wenn man Dinge ändern muss, und somit vermeidet, durcheinander zu geraten. Geht es aber rein um abzuliefernde Informationen (typischerweise die Ausgabe bestimmter Befehler oder den Inhalt gewisser Log-Dateien), ist es sinnvoll, allen Hilfestellern das zu liefern, wonach sie fragen. Erstens kann jeder vergessen, nach einer wichtigen Information zu fragen, und zweitens kann es sein, dass derjenige, auf den sich der Fragesteller exklusiv konzentriert, das Problem vollkommen falsch verstanden hat und sich in eine gänzlich falsche Richtung bewegt. Es ist schon oft genug vorgekommen, dass nach langer Suche die Lösung doch durch den Hinweis gefunden wurde, den jemand frühzeitig eingestreut hatte, ohne zunächst beachtet zu werden.

Der letzte Punkt zu diesem Thema ist vielleicht weniger eindeutig: Wenn sich dem Fragesteller eine geforderte Information nicht auf Anhieb erschließt, dann ist es durchaus legitim, nach dem Sinn zu fragen. Trotzdem ist man gut beraten, diese Information gleich mitzuliefern. Dann bekommt man neben der Erklärung, warum es jetzt wichtig war, dies und jenes auszuprobieren, evtl. gleich die Lösung des Problems. Denn oft kann man an Kleinigkeiten rein durch Erfahrung die Ursache erkennen, obwohl ein Neuling da keinerlei Zusammenhang sieht.
Beispiel: man hat Probleme mit dem Ton und bekommt gesagt, alle Soundeinstellungen (Ausgabe von "amixer") zu posten, auch wenn man sich dreimal vergewissert hat, die Lautstärke über das Lautsprechersymbol in der Kontroll-Leiste auf Maximum gestellt zu haben. Dass das nur den Master-Kanal regelt und man zusätzlich in den erweiterten Einstellungen noch andere Kanäle hochdrehen und die Stummschaltung deaktivieren muss, kann man natürlich nicht wissen. Gibt man dem Hilfesteller die komplette Information, kann der sofort helfen, und man muss nicht erst ausdiskutieren, worauf es letztendlich eh hinausläuft.

Lösungen posten

Ganz wichtig: wenn man sich wegen eines Problems an ein Forum/eine Newsgroup/Mailingliste wendet, immer auch am Ende nochmal posten, wie das Problem gelöst wurde (wenn es denn eine Lösung gab). Damit haben dann alle was davon und dem nächsten mit dem gleichen Problem kann schneller geholfen werden, weil sich entweder jemand an genau diese Lösungsbeschreibung erinnert oder sie vielleicht sogar über eine Suchmaschine gefunden werden kann.

Private Kommunikation

Wenn man seine Hilfesuche an einem "öffentlichen Platz" begonnen hat, sollte man im weiteren Verlauf auch dort bleiben. Das heißt, dass man - von expliziten Aufforderungen abgesehen - nicht der erstbesten Person, die auf die eigene Frage geantwortet hat, E-Mails direkt oder private Nachrichten eines Forum-Systems schickt.

Zunächst einmal hat der Rest der Welt nichts davon. Es könnte ja jemand mitlesen (oder später nachlesen), der das gleiche oder ein sehr ähnliches Problem hat. Zum anderen legt man sich damit auf einen Hilfesteller fest. Schreibt man dagegen weiterhin an die Liste/das Forum, können sich andere einklinken, die das Thema erst später entdeckt haben oder bisher keine Zeit für eine Antwort hatten. Außerdem könnte es auch sein, dass die direkt kontaktierte Person gar nicht weiter helfen kann, als mit dem, was sie bisher schon geschrieben hat. Vielleicht ist sie auch gerade dann mehrere Wochen im Urlaub und man wartet ewig auf Antwort.

Mal abgesehen davon, dass es evtl. etwas dreist sein könnte, andere Leute zu seinem privaten Support-Mitarbeiter zu machen. In den meisten Fällen antworten Freiwillige, die nicht dafür verantwortlich sind, die Probleme anderer zu lösen.

Rechtschreibung etc.

Ja, wir sind hier im Internet und nicht mehr in der Schule beim Diktat, aber wie naiv muss man eigentlich sein, wenn man annimmt, dass ein dahingerotzter Haufen Buchstaben ohne ein Mindestmaß an Rechtschreibung, Interpunktion und Groß-/Kleinschreibung genauso schnell eine brauchbare Antwort bringt wie eine Anfrage, bei der man sich ein bisschen die Mühe gemacht hat, damit andere den Inhalt nicht erst nach dem dritten Mal durchlesen verstehen können? Oder wäre man auch mit einer Antwort zufrieden, bei der man 5 Minuten braucht, um die Wörter zu entziffern, die Satzenden zu identifizieren und thematische Abschnitte voneinander zu unterscheiden? Bevor man überhaupt anfangen kann, den eigentlichen Inhalt zu verstehen... Beim sorgfältigen Verfassen einer Frage ist es auch durchaus möglich, dass einem die Lösung dabei selbst auffällt.

Man muss ja nicht gleich den Literatur-Nobelpreis anpeilen, aber abgeschlossene Sätze sollten schon als solche erkennbar sein. Im übrigen hilft es auch sehr, ab und zu einen neuen Abschnitt zu beginnen, falls der Text länger als 5 Sätze ist. Und bitte die Anzahl der Rechtschreibfehler auf unter einen pro Satz drücken. Das ist doch nicht zu schwer, oder?


Schlußbemerkung

Auch wenn ich nicht mit allen Aussagen in How To Ask Questions The Smart Way übereinstimme und den dort benutzen Tonfall als viel zu schroff erachte, sind die Kernaussagen in den meisten Fällen durchaus richtig und ich empfehle, dieses Dokument mal in einer ruhigen Minute durchzulesen.
Bei einem Punkt stimme ich den Autoren jedenfalls voll uns ganz zu: nur weil man einmal ein hilfreiches Dokument geschrieben, jemandem in einem Forum/auf einer Mailingliste auf eine Frage geantwortet hat oder generell in Foren/Mailinglisten aktiv ist, heißt das nicht, dass man bei jedem Problem direkt kontaktiert werden kann. Im Endeffekt ist jede Hilfe auch als Hilfe zur Selbsthilfe gedacht, so dass man im Laufe der Zeit immer mehr Probleme selbst lösen kann, bevor man sich an andere wendet.

--------------------
© 2005 brack@the-one-brack.org zurück zur Linux-Seite Last modified: Wed Dec 14 13:07:59 CET 2005