Wie man Fragen richtig stellt

Diese Übersetzung basiert auf Revision 3.8 vom 19. Juni 2012 des Originaldokuments http://www.catb.org/~esr/faqs/smart-questions.html.

Sie startete als Projekt der Linux User Group Bolzano/Bozen/Bulsan und steht unter der Creative Commons Attribution-Share Alike 3.0 Unported Lizenz. Kommentare zur Übersetzung bitte an Thomas Pircher, <tehpeh-web@tty1.net>

Eine andere deutsche Übersetzung findest du auf der Homepage von Richard Voss (www.fruiture.de).

Vielen Dank an Michael Schröpl, Martha Pircher, Andreas Waschbuesch, Karsten Desler, Christian Peer, Erkan Yilmaz und Martin Gerdes für die Korrekturen und Verbesserungsvorschläge zu dieser Übersetzung.

Copyright © 2001,2006 Eric S. Raymond, Rick Moen

Inhaltsverzeichnis

Übersetzungen
Disclaimer
Einführung
Bevor du fragst
Wenn du fragst
Wähle das Forum sorgfältig
Web- und IRC-Foren für Newbies liefern oft am schnellsten eine Antwort
Verwende Projekt-Mailinglisten als zweite Anlaufstelle
Verwende aussagekräftige, genaue Betreffzeilen
Mache es deinem Ansprechpartner einfach, dir zu antworten
Schreibe in klarer, grammatikalisch korrekter Sprache
Sende Fragen in zugänglichen, offenen Formaten
Sei genau und informativ über dein Problem
Masse ist nicht Genauigkeit
Behaupte nicht übereilt, du hättest einen Fehler gefunden
Selbsterniedrigung ist kein Ersatz für nicht gemachte Hausaufgaben
Beschreibe die Problemsymptome, nicht deine Vermutungen
Beschreibe die Symptome deines Problems in chronologischer Reihenfolge
Beschreibe das Ziel, nicht einen Schritt
Verlange keine Antworten durch private Mails
Stelle eine deutliche Frage
Wenn du nach Code fragst
Poste keine Hausaufgaben
Vermeide aussagenlose Fragen
Kennzeichne deine Fragen nicht als Wichtig, auch wenn sie es für dich sind
Höflichkeit tut nie weh und hilft manchmal
Poste anschließend eine kleine Anmerkung zur Lösung
Wie man Antworten interpretiert
RTFM und STFW: Wie man mitteilt, dass du wirklich danebengelangt hast
Wenn du nicht verstehst...
Umgang mit Grobheit
Nicht wie ein Loser reagieren
Fragen, die man nicht stellen sollte
Gute und schlechte Fragen
Falls du keine Antworten bekommst
Fragen auf eine hilfreiche Art beantworten
Sachverwandte Ressourcen
Besonderer Hinweis für FAQ Listen-Maintainer und Webmaster
Danksagung

Übersetzungen

Übersetzungen: Englisch (Originaldokument) Bahasa Indonesisch Weißrussisch Brazilo-Portugisisch Chinesisch Niederländisch Französisch Georgisch Deutsch Griechisch Hebräisch Japanisch Polnisch Portugisisch Rumänisch Russisch Spanisch Thai Türkisch.

Wenn du dieses Dokument oder Teile davon kopieren, spiegeln, übersetzen willst, siehe Eric Raymonds copying policy.

Disclaimer

Die Webseiten vieler Projekte enthalten in dem Abschnitt, in dem aufgelistet wird, wo man Hilfe erhält, einen Link auf dieses Dokument. Das ist gut so, dafür wurde es geschrieben – aber wenn du ein Webmaster bist, der einen solchen Link erstellt, füge bitte gut sichtbar in der Nähe des Links eine Randnotiz ein, dass wir kein Helpdesk für euer Projekt sind!

Wir haben schmerzhaft lernen müssen, dass wir ohne eine solche Erklärung andauernd von Volltrotteln belästigt werden, die glauben, dass die Tatsache, dieses Dokument veröffentlicht zu haben, uns dazu verpflichtet, alle technischen Probleme dieser Welt lösen zu müssen.

Wenn du diesen Text liest, weil du Hilfe brauchst, und du den Eindruck hast, du kannst sie direkt von den Autoren dieses Dokuments bekommen, dann bist du einer der genannten Idioten. Stelle uns keine Fragen. Wir werden dich einfach ignorieren. Wir zeigen dir, wie du Hilfe von Leuten bekommst, welche sich mit deiner Hardware oder Software auskennen, aber zu 99% werden nicht wir diese Leute sein. Sofern du nicht genau weißt, dass einer der Autoren ein Experte im fraglichen Gebiet ist, lass uns in Ruhe, und alle werden glücklicher sein.

Einführung

In der Welt der Hacker hängen die Antworten, die du auf deine technische Frage erhältst, sowohl von der Art ab, wie du die Frage gestellt hast, als auch von der Schwierigkeit, eine Antwort zu finden. Dieser Text zeigt dir, wie man Fragen so stellt, um eher eine zufrieden stellende Antwort zu bekommen.

Da Open Source Software mittlerweile weit verbreitet ist, kannst du nicht nur von Hackern, sondern auch von erfahrenen Benutzern eine Antwort bekommen. Das ist gut; User sind in der Regel toleranter gegenüber Fehlern, die oft von Neulingen gemacht werden. Der erfolgversprechendste Weg, von solchen Usern hilfreiche Antworten zu bekommen, ist der, mit ihnen so umzugehen, wie du es mit Hackern tun würdest.

Zu allererst ist es wichtig, zu verstehen, dass Hacker schwierige Probleme und gute, zum Denken anregende Fragen darüber mögen. Wenn wir das nicht täten, wären wir nicht hier. Wenn du uns eine interessante Frage zum Durchkauen gibst, sind wir dir dankbar; gute Fragen sind stimulierend und ein Geschenk. Gute Fragen helfen, unser Verständnis zu entwickeln und oft enthalten sie Probleme, die wir sonst nicht bemerkt und worüber wir sonst auch nicht nachgedacht hätten. Unter Hackern ist der Ausruf Gute Frage! ein großes und ehrliches Kompliment.

Trotzdem haben Hacker den Ruf, auf einfache Fragen mit Feindseligkeit und Arroganz zu reagieren. Scheinbar sind wir grob zu Neulingen und Nicht-Eingeweihten. Das ist aber nicht wirklich der Fall.

Wir verhalten uns allerdings (und das soll keine Entschuldigung sein) feindselig Leuten gegenüber, die nicht willens zu sein scheinen, selbst zu denken und ihre Hausaufgaben zu machen, bevor sie ihre Fragen stellen. Solche Menschen sind ein Fass ohne Boden, sie nehmen, ohne etwas zurückzugeben und verbrauchen Zeit, die mit interessanteren Fragen und Personen, die eher eine Antwort verdient hätten, besser verwendet wäre. Wir nennen solche Menschen Loser (manchmal als luser geschrieben, oder im deutschsprachigen Raum DAUs, Dümmste Anzunehmende User).

Uns ist bewusst, dass viele Leute nur unsere Software verwenden wollen und kein Interesse für technische Details aufbringen. Für die meisten Leute ist der Computer einfach ein Werkzeug, ein Mittel zum Zweck. Sie haben wichtigere Dinge zu tun. Wir akzeptieren das und erwarten nicht, dass jeder sich für die technischen Belange erwärmen kann, die uns faszinieren. Trotzdem sind unsere Antworten auf Leute abgestimmt, die dieses Interesse haben und aktiv bei der Problemlösung teilnehmen wollen. Dieser Umstand wird sich nicht ändern, und er sollte es auch nicht tun. Denn wenn das geschehen würde, wären wir weniger effektiv in dem, was wir bisher sehr gut machen.

Wir sind (vorwiegend) Freiwillige. Wir verwenden Zeit unseres vielbeschäftigten Lebens dafür, Fragen zu beantworten und manchmal werden diese einfach zu viel. Deshalb wird rücksichtslos gefiltert. Genauer gesagt, wir eliminieren Fragen von Leuten, die sich wie Loser benehmen und verwenden die gewonnene Zeit effizienter mit anderen.

Wenn du dieses Verhalten für widerlich, herablassend oder arrogant hältst, denk noch einmal darüber nach. Wir wollen nicht, dass du vor uns niederkniest – im Gegenteil, den meisten von uns wäre nichts lieber, dich als Gleichen unter Gleichen zu behandeln und dich in unserer Kultur willkommen zu heißen, wenn du dir die Mühe machst, das zu ermöglichen. Aber es ist für uns einfach nicht tragbar, Leuten zu helfen, die nicht gewillt sind, sich selber zu helfen. Es ist OK, nicht alles zu wissen; es ist nicht OK, sich dumm zu stellen.

Während es nicht notwendig ist, bereits technisch kompetent zu sein, um unsere Aufmerksamkeit zu erlangen, ist es nötig, die Art von Verhalten zu zeigen, mit der man sich Wissen aneignet – Geistesgegenwart, Bedachtheit, Aufmerksamkeit, den Willen, ein aktiver Partner bei der Entwicklung einer Lösung zu sein. Wenn du mit dieser Art Diskriminierung (im Sinne von Unterscheidung) nicht zurecht kommst, raten wir dir, für einen kommerziellen Supportvertrag zu bezahlen, anstatt von Hackern kostenlose Hilfestellung zu erwarten.

Wenn du dich für uns entscheidest und Hilfe brauchst, willst du kein Loser sein. Du willst auch nicht wie einer wirken. Die beste Art, schnelle und brauchbare Antworten zu bekommen, ist die, wie sie jemand mit Grips, Selbstvertrauen und Wissen an den Tag legt, welcher die Hilfe nur bei einem bestimmten Problem braucht.

(Verbesserungsvorschläge, Fehlerhinweise zu diesem Text sind willkommen. Du kannst eine Mail an den Autor des Originaldokuments <esr@thyrsus.com> oder <respond-auto@linuxmafia.com> schicken (oder wegen Übersetzungsfehlern an <tehpeh-web@tty1.net>, Anm.d.Übers.). Dieses Dokument ist keine allgemeine Netiquette, und ich werde keine Vorschläge aufnehmen, die nicht speziell für technische Foren ausgelegt sind.)

Bevor du fragst

Bevor du eine technische Frage per E-Mail verschickst, in eine Newsgroup oder ein Web-Forum postest, befolge bitte folgende Schritte:

Anleitung 1.

  1. Versuche, eine Antwort in den Archiven des Forums zu finden, in dem du die Frage stellen willst.
  2. Versuche, eine Antwort durch Suchen im Web zu finden.
  3. Versuche, eine Antwort durch Lesen des Handbuches (Manuals) zu finden.
  4. Versuche, eine Antwort durch Lesen der FAQ zu finden.
  5. Versuche, eine Antwort durch eigene Untersuchungen und Tests zu finden.
  6. Versuche, eine Antwort zu bekommen, indem du einen erfahrenen Freund fragst.
  7. Wenn du ein Programmierer bist, dann versuche, eine Antwort durch Lesen des Source-Codes zu finden.

Wenn du deine Frage stellst, lass durchblicken, dass du diese Dinge bereits getan hast; das stellt sicher, dass du nicht als Schmarotzer und Zeitverschwender angesehen wirst. Besser, du gibst zu verstehen, dass du dabei gelernt hast. Wir mögen es, Leuten zu antworten, die gezeigt haben, dass sie durch Antworten lernen können und wollen.

Verwende die Methode, mit Google nach der exakten Fehlermeldung, die du erhältst, zu suchen (suche sowohl in den Google-Groups als auch nach Webseiten). Das wird dich wahrscheinlich zu Dokumentationen oder zu einer Mailingliste führen, die deine Frage beantworten. Wenn du nichts gefunden hast, ist es hilfreich, den Satz ich habe nach folgenden Stichworten gegoogelt, aber nichts wirklich Hilfreiches gefunden in einer Mail oder einem Posting anzuführen. Zumindest hält dies in den Archiven fest, welche Suche zu keinem Ergebnis führt. Später können andere mit einem ähnlichen Problem deinen Thread finden und, sofern sie eine Lösung gefunden haben, diese dort posten oder auf einen hilfreiche Seite verlinken.

Nimm dir Zeit. Erwarte nicht, ein kompliziertes Problem mit wenigen Sekunden Google-Suche lösen zu können. Lies und verstehe die FAQs, lehne dich zurück, entspanne und denke ein wenig über das Problem nach, bevor du damit zu Experten gehst. Aus deiner Frage werden wir ablesen können, wie viel du über dein Problem gelesen und nachgedacht hast. Es wird dir eher geholfen werden, wenn du vorbereitet kommst. Lade nicht gleich deinen gesamten Vorrat an Fragen ab, nur weil deine erste Suche keine (oder zu viele) Antworten geliefert hat.

Bereite deine Frage vor. Denke sie gut durch. Hastig geschriebene Fragen erhalten hastige Antworten, wenn überhaupt welche. Je mehr du zeigst, dass du schon Energie in Lösungsversuche investiert hast, desto wahrscheinlicher erhältst du Hilfe.

Vermeide es, die falsche Frage zu stellen. Wenn du eine Frage auf Grund falscher Annahmen stellst, wird J. Random Hacker wahrscheinlich mit einer nutzlosen Antwort parieren, während er sich Dumme Frage... denkt. Er erhofft sich damit, dass du die Erfahrung, das bekommen zu haben, wonach du gefragt hast, und nicht das, was du brauchtest, dir eine Lehre ist und du in Zukunft bessere Fragen stellst.

Nimm niemals an, du hättest ein Recht auf eine Antwort. Das hast du nicht; schließlich hast du für diese Dienstleistung nicht bezahlt. Du wirst eine Antwort bekommen, indem du eine sinnvolle, interessante und zum Denken anregende Frage stellst, die indirekt zum Wissen der Gemeinschaft etwas beiträgt, und nicht nur passiv das Wissen anderer anzapft.

Auf der anderen Seite ist das Signalisieren der Bereitschaft zu lernen und in der Lösungsfindung zu helfen, ein sehr guter Anfang. Die Fragen Kann mir jemand einen Tipp geben?, Was fehlt in meinem Beispiel? und Gibt es eine Web-Seite, die ich gesehen haben sollte? sind wesentlich erfolgversprechender als Bitte gebt mir die exakte Anleitung, die ich befolgen soll. Damit zeigst du, dass du den Prozess wirklich zu Ende führen willst, wenn Dir jemand die richtige Richtung weist.

Wenn du fragst

Wähle das Forum sorgfältig

Suche dir den Ort, wo du fragst, gut aus. Du wirst wahrscheinlich ignoriert oder als Loser abgestempelt werden, wenn du:

Hacker schmettern unpassende Fragen ab, um ihren Kommunikationskanal vor der Überflutung durch Irrelevantes zu schützen. Du willst nicht, dass dir das passiert.

Der erste Schritt ist deshalb, ein geeignetes Forum zu finden. Wieder einmal sind Google und andere Web-Suchmethoden deine Freunde. Verwende sie, um die passendste Projekt-Webseite zu deiner Hardware oder Software, die Probleme macht, zu finden. Normalerweise enthält sie Links zu FAQs (Frequently Asked Questions) und zu Projekt-Mailinglisten und deren Archiven. Das sind dann die Orte, in denen du um Hilfe suchen kannst, wenn deine eigenen Bemühungen der Problemlösung (einschließlich dem Lesen der FAQs) nichts gebracht haben. Wenn die Projektseite eine Anleitung zur Zusammenstellung von Bug-Reports pflegt oder auf eine solche Anleitung verweist, halte dich daran.

E-Mails an Personen oder an Foren zu verschicken, die du nicht kennst, ist im besten Fall riskant. Erwarte zum Beispiel nicht, dass der Autor einer informativen Webseite dein Gratis-Berater ist. Mache keine optimistischen Einschätzungen, ob deine Mail willkommen ist – wenn du unsicher bist, sende sie anderswo hin oder lass es ganz bleiben.

Bei der Auswahl eines Web-Forums, einer Newsgroup oder Mailingliste vertraue nicht blind auf deren Namen; schaue in ihre FAQ oder Charta und vergewissere dich, dass dein Posting dort on-topic ist. Lies einige Beiträge mit, um zu verstehen, wie die Dinge in der Gruppe gehandhabt werden. Es ist eine gute Idee, eine Stichwortsuche mit Worten, die mit deinem Problem zu tun haben, im Archiv der Mailingliste oder Newsgroup durchzuführen, bevor du postest. Du könntest dort eine Antwort finden, und wenn nicht, wird es dir helfen, die Frage besser zu formulieren.

Mülle nicht alle Kanäle die du finden kannst, gleichzeitig mit derselben Frage voll. Dies wird als Schreien empfunden und wirkt unangenehm. Verwende einen Kanal nach dem anderen.

Sei dir bewusst, was dein Thema ist! Klassische Fehler sind Fragen über Unix- oder Windows-Programmierschnittstellen in einem Forum zu stellen, das sich einer Sprache oder Bibliothek widmet, die auf beide Plattformen portiert ist. Wenn du nicht verstehst, warum das ein Schnitzer ist, wäre es für dich am besten, solange keine Frage zu stellen, bis du es verstanden hast.

Im Allgemeinen werden Fragen in einem gut ausgewählten, öffentlichen Forum eher sinnvoll beantwortet als in einem privaten. Dafür gibt es verschiedene Gründe. Dort schreiben einfach mehr potentielle Helfer. Es lesen dort aber auch mehr Leute, und Hacker antworten lieber auf Fragen, aus denen viele Leute etwas lernen können, als auf Fragen, die nur wenigen nützen.

Verständlicherweise bekommen bekannte Hacker und Autoren von populärer Software schon mehr fehlgeleitete Mails, als ihnen lieb ist. Wenn du diese Flut noch vergrößerst, kannst du im Extremfall der Tropfen sein, der das Fass zum Überlaufen bringt – schon oft genug haben Mitarbeiter von populären Projekten ihre Hilfe wegen zu großer Belastung ihrer E-Mail-Konten durch sinnlose Mails zurückgezogen.

Web- und IRC-Foren für Newbies liefern oft am schnellsten eine Antwort

Eine User-Group in deiner Nähe oder deine Distribution betreiben vielleicht ein Web-Forum oder einen IRC-Kanal, in denen Neulinge Hilfe erhalten. (In nicht englischsprachigen Ländern sind Foren für Neulinge eher in der Form einer Mailingliste anzutreffen.) Diese Orte sind die ersten Anlaufstelle für Fragen, ganz besonders, wenn du glaubst, über ein relativ einfaches oder häufiges Problem gestolpert zu sein. Ein auf Webseiten beworbener IRC-Kanal ist eine offene Einladung, dort Fragen zu stellen und Antworten häufig in Echtzeit zu bekommen.

Wenn du das Programm, welches dir Probleme bereitet, (wie heutzutage üblich,) von einer Linux-Distribution bezogen hast, dann ist es wahrscheinlich besser, für deine Frage ein Forum oder eine Mailingliste deines Distributors zu wählen, bevor du das Forum oder die Mailingliste des Projektes in Anspruch nimmst. Die am Projekt beteiligten Hacker könnten dir antworten: verwende unsere builds.

Noch bevor du in ein Web-Forum postest, solltest du dich vergewissern, ob es eine Suchfunktion bereitstellt. In diesem Fall, suche nach ein paar Schlüsselwörtern, die mit deinem Problem zu tun haben; schon das könnte dir weiter helfen. Auch wenn du schon zuvor im Web gesucht hast, (was du in jedem Fall getan haben solltest,) stelle diese Suche auch im Forum an; deine verwendete Suchmaschine könnte einige aktuelle Seiten noch nicht indiziert haben.

Immer mehr Projekte verlegen Supportdienste auf ein Web-Forum oder einen IRC-Kanal und verwenden E-Mail vorwiegend für Entwickler-Informationen. Suche also nach diesen Kanälen, wenn du Hilfe zu einem bestimmten Projekt benötigst.

Verwende Projekt-Mailinglisten als zweite Anlaufstelle

Wenn ein Projekt eine Entwickler-Mailing-Liste unterhält, schreibe an die Liste, nicht an einzelne Personen, auch wenn du zu wissen glaubst, wer deine Frage möglicherweise am besten beantworten könnte. Suche in der Dokumentation und der Projekt-Seite nach der Adresse der Mailing-Liste und verwende sie. Es gibt mehrere gute Gründe dafür:

Wenn ein Projekt eine Benutzer- und eine Entwickler- (oder Hacker-) Mailing-Liste oder Web-Forum betreut, und du nicht am Sourcecode arbeitest, verwende die User-Liste oder das User-Forum. Nimm auf keinen Fall an, deine Frage sei im Entwickler-Kanal willkommen, da sie leicht als lästiges Rauschen empfunden wird, das die Kommunikation der Entwickler stört.

Wenn du keine Projekt-Mailingliste finden kannst, und nur die Adresse des Projektleiters findest, kannst du ihm schreiben. Aber auch in diesem Fall solltest du nicht davon ausgehen, dass keine Liste existiert. Erkläre in der Mail, dass du keine Mailingliste finden konntest. Erwähne auch, dass du nichts dagegen hast, wenn die Mail weitergeleitet wird. (Manche Menschen sind der Auffassung, dass private Mails privat bleiben sollten, auch wenn darin nichts Geheimes enthalten ist. Durch die Einwilligung gibst du dem Maintainer die Möglichkeit, die Mail seinem Ermessen nach zu behandeln.)

Verwende aussagekräftige, genaue Betreffzeilen

In Mailinglisten, Newsgroups oder Internet-Foren ist die Betreffzeile eine nicht zu unterschätzende Möglichkeit, in 50 oder weniger Zeichen die Aufmerksamkeit von Experten auf dich zu ziehen. Verschwende sie nicht für Geplapper wie Bitte helft mir! (oder gar BITTE HELFT MIR !!!; solches Zeugs wird reflexartig entsorgt). Versuche nicht, uns mit der Größe deiner Pein zu beeindrucken; verwende den Platz besser für eine kurze Beschreibung des Problems.

Eine sinnvolle Konvention für Betreffzeilen, die von vielen Support-Organisationen verwendet wird, ist Objekt–Abweichung. Das Objekt beschreibt, welches Ding oder welche Gruppe von Dingen ein Problem aufweist, und die Abweichung beschreibt eben die Abweichung vom erwarteten Verhalten.

Dumm:
Hilfe! Video geht nicht richtig auf meinem Laptop!
Intelligent:
X.org 6.8.1 verzerrter Mouse Cursor, Fooware MV1005 vid. Chipsatz
Schlauer:
X.org 6.8.1 Mouse Cursor auf Fooware MV1005 vid. Chipsatz - ist verzerrt

Der Denkprozess, eine Beschreibung vom Typ Objekt–Abweichung zu verfassen, hilft dir dabei, deine Gedanken über das Problem zu ordnen. Was ist betroffen? Nur der Mauszeiger oder auch andere grafische Elemente? Ist es spezifisch für X.org? Oder Version 6.8.1? Ist das ein Problem des Fooware Video Chipsatzes? Von Modell MV1500? Ein Hacker, der das sieht, kann auf den ersten Blick verstehen, womit du Probleme hast und in welcher Art sie auftreten.

Wenn du eine Frage in einem Antwort-Beitrag stellst, ändere die Betreff-Zeile entsprechend. Eine Betreffzeile wie Re: test oder Re: neuer Bug zieht womöglich nicht die erhoffte Aufmerksamkeit auf sich. Reduziere auch das Zitieren vorangegangener Nachrichten auf ein notwendiges Minimum, damit neue Leser verstehen, worum es geht.

Drücke nicht einfach auf antworten, um einen komplett neuen Thread anzufangen. Das würde deine Leserschaft verkleinern. Einige Mailreader wie Mutt erlauben es, Beiträge nach Threads zu sortieren und dann den gesamten Diskussionsfaden zu verstecken, indem sie ihn zusammenfalten. Leute, die das tun, werden deinen Beitrag niemals sehen.

Die Betreffzeile zu verändern reicht nicht aus. Mutt und wahrscheinlich auch andere Mailprogramme verwenden zusätzliche Informationen im Header der Mail, um sie einem Thread zuzuordnen, nicht nur die Betreffzeile. Beginne stattdessen eine komplett neue Nachricht.

In Web-Foren gelten ein wenig andere Regeln, denn dort sind Mitteilungen meist eng an einen Diskussionsfaden gebunden und selten außerhalb dieses Threads sichtbar. Einfach die Betreffs-Zeile zu ändern ist nicht genug. Manchmal erlaubt die Foren-Software gar keine unterschiedliche Betreffszeilen für Antworten und auch wenn dem so ist, würde fast niemand sie lesen. Eine Frage in einem Antwort-Thread zu stellen ist keine gute Idee, da sie nur von den Forenteilnehmern im aktuellen Thread gelesen würde. Wenn du von allen Foren-Teilnehmern gelesen werden willst, dann starte einen neuen Thread.

Mache es deinem Ansprechpartner einfach, dir zu antworten

Wenn du die Frage mit einem Bitte schickt eure Antworten an... versiehst, verringerst du die Aussichten auf eine Antwort. Wenn du dir nicht die paar Sekunden leisten kannst, einen korrekten Reply-To Header zu setzen, können wir es uns nicht leisten, über dein Problem nachzudenken. Falls dein Mail-Programm dir das nicht erlaubt, nimm ein besseres Mail-Programm. Falls es für dein Betriebssystem kein Programm gibt, welches dazu in der Lage wäre, nimm ein besseres Betriebssystem.

In Web-Foren gilt es als äusserst unhöflich, Antworten als Mails zu verlangen, außer du kannst annehmen, die Antwort könnte empfindliche Daten beinhalten (und jemand will aus unerfindlichen Gründen zwar dich, aber nicht das gesamte Forum daran teilhaben lassen). Wenn du per E-Mail benachrichtigt werden willst, sobald jemand in deinen Thread schreibt, dann lass dies die Foren-Software tun; fast alle Diskussionsforen unterstützen diese Möglichkeit unter dem Namen watch this thread oder schicke E-Mail bei Antworten usw.

Schreibe in klarer, grammatikalisch korrekter Sprache.

Wir wissen aus Erfahrung, dass Leute mit oberflächlichem und schlampigem Schreibstil auch oberflächliche und schlampige Denker und Coder sind (jedenfalls oft genug, um darauf wetten zu können). Solchen Leuten Fragen zu beantworten, lohnt sich nicht; mit dieser Zeit können wir etwas Besseres anfangen.

Es ist also wichtig, deine Fragen klar und deutlich zu formulieren. Wenn dir das zu mühsam ist, ist es für uns zu mühsam, auf deine Frage einzugehen. Verwende ein wenig Zeit darauf, an deiner Sprache zu feilen. Sie muss nicht steif und formal sein – in der Hackerkultur schätzt man zwanglose, humorvolle und präzise Sprache. Aber sie muss präzise sein; das ist ein Anzeichen, dass du mitdenkst und aufmerksam bist.

Verwende korrekte Rechtschreibung, Interpunktion und Großschreibung. Schreibe NICHT ALLES GROSS, das wird als Schreien empfunden und gilt als unhöflich. (Vollständige Kleinschreibung ist einen Deut weniger nervtötend, ist aber auch schwer zu lesen. Einem Alan Cox wird man so etwas vielleicht durchgehen lassen – dir nicht.)

Im Allgemeinen, wenn du wie ein halb-alphabetisierter Dussel schreibst, wirst du wahrscheinlich ignoriert werden. Verwende keine SMS-Kürzel; Wenn du einfach Buchstaben im Wort weglässt, präsentierst du dich selbst als halbgebildeter Dummkopf der zu faul ist, ein paar Tasten mehr zu drücken. Schlimmer noch: der Schreibstil eines l33t script kiddie hax0r ist der absolute Tod und garantiert dir eisiges Schweigen (oder bestenfalls eine Portion Hohn und Sarkasmus) als Rückantwort.

Wenn du in ein Forum postest, das nicht deine Muttersprache verwendet, darfst du mit einer gewissen Nachsicht für Rechtschreib- und Grammatikfehler rechnen – nicht aber mit Gnade für Faulheit (und ja, wir erkennen in der Regel den Unterschied). Schreibe in Englisch, wenn du die Sprache des betreffenden Forums nicht kennst. Beschäftigte Hacker neigen dazu, unverständliche Fragen zu löschen, und Englisch ist nun einmal die Lingua franca im Internet. Wenn du in Englisch schreibst, minimierst du die Wahrscheinlichkeit, dass deine Frage ungelesen bleibt.

Wenn Du als Nichtmuttersprachler auf Englisch schreibst, weise deine Leser darauf hin und biete Möglichkeiten an, die Sprachschwierigkeiten zu umschiffen:

Sende Fragen in zugänglichen, offenen Formaten

Wenn du das Lesen deiner Frage künstlich erschwerst, wird sie möglicherweise zugunsten einer zugänglicheren Nachricht übergangen. Also:

Wenn du einen grafischen Mail-Client verwendest (wie Netscape Messenger, MS Outlook, oder dergleichen), sei gewarnt, dass viele in ihren Standardeinstellungen diese Regeln missachten. Die meisten dieser Programme ermöglichen es, den tatsächlich gesendeten Text anzusehen (View Source). Verwende diese Option an einer gesendeten Nachricht, um dich zu vergewissern, dass du reinen Text ohne unnützen Dreck versendest.

Sei genau und informativ bei der Beschreibung deines Problems

Versuche, den Fragen eines Hackers zuvorzukommen und beantworte sie schon in deiner Mail, zusammen mit der Bitte um Hilfe.

Wenn du einen Fehler meldest, von dem du denkst dass er ein Bug in einem Programm ist, dann ist es besonders wichtig zu beschreiben, wie man einen Fehler in einem kontrollierten Umfeld reproduzieren kann. Damit erhöhst du sowohl die Wahrscheinlichkeit, dass du eine hilfreiche Antwort bekommst, als auch die Geschwindigkeit, mit der du die Antwort bekommst.

Simon Tatham hat ein ausgezeichnetes Essay mit dem Titel How to Report Bugs Effectively (in englischer Sprache, Anm. d. Übers.) geschrieben. (Eine deutsche Übersetzung gibt es auf http://www.chiark.greenend.org.uk/~sgtatham/bugs-de.html, Anm.d.Ü.) Ich empfehle dir wärmstens, es zu lesen.

Masse ist nicht Genauigkeit

Sei präzise und informativ! Uns ist nicht mit großen Mengen an Code oder Daten gedient. Wenn du einen großen, komplizierten Testfall hast, der einem Programm Probleme bereitet, versuche ihn zu optimieren und so klein wie möglich zu machen.

Das ist aus mindestens drei Gründen nützlich. Erstens: Wenn du zeigst, dass du dir Mühe und Gedanken machst, das Problem zu vereinfachen, erhöhst du die Chance auf eine Antwort. Zweitens: Die Frage zu vereinfachen macht es wahrscheinlicher, eine hilfreiche Antwort zu bekommen. Drittens: Beim Prozess der Umformung des Problems könntest du selbst einen Fix oder ein Workaround schreiben.

Behaupte nicht übereilt, du hättest einen Fehler gefunden

Triffst du bei einem Software-Teil auf Probleme, dann behaupte nicht sofort, du hättest einen Fehler gefunden, bevor du deiner Sache nicht sehr, sehr sicher bist. Hinweis: du bist dir wahrscheinlich dann nicht hinreichend sicher, wenn du keinen Patch, der das Problem behebt, oder alternativ dazu einen Regressionstest, der das inkorrekte Verhalten belegt, vorweisen kannst.

Denke daran, dass das Problem bei einer Menge anderer Benutzer des Programms nicht auftritt. Andernfalls hättest du etwas darüber in der Dokumentation gelesen, oder etwas darüber im Web gefunden. (Du hast natürlich die entsprechende Dokumentation gelesen und im Web gesucht, bevor du gefragt hast, oder?) Vielleicht ist ja nicht das Programm defekt, sondern du setzt es nur falsch ein.

Software-Entwickler bemühen sich, ihre Software so gut wie möglich zu machen. Behauptest du nun, du habest einen Fehler gefunden, hältst du ihnen vor, sie hätten einen Fehler produziert -- und sowas hört keiner gern, selbst wenn es stimmt. Es ist nicht besonderns diplomatisch, in der Betreffzeile von Fehlern zu sprechen.

Wenn du deine Frage stellst, ist es am besten, du formulierst sie in der Annahme, du hättest einen Fehler gemacht, auch wenn du absolut sicher bist, einen Bug gefunden zu haben. Wenn ein Softwarefehler vorliegt, wirst du in der Antwortmail darüber hören. Betrachte es so, dass die Entwickler sich bei dir entschuldigen, wenn du wirklich auf einen Fehler gestoßen bist, anstatt dass du dich beim Programmierer für eine unwahre Behauptung entschuldigen musst.

Selbsterniedrigung ist kein Ersatz für nicht gemachte Hausaufgaben

Einige Leute, die verstanden haben, dass sie sich nicht unfreundlich oder arrogant benehmen sollen, wenn sie um Hilfe bitten, wählen das Gegenteil, nämlich extreme Selbsterniedrigung. Ich weiß, ich bin nur ein lächerlicher kleiner Newbie Loser, aber.... Das wirkt ablenkend und ist nicht hilfreich. Es ist besonders lästig, wenn es zusammen mit Ungenauigkeit über das eigentliche Problem auftritt.

Verschwende unsere und deine Zeit nicht mit plumper Höflichkeit. Beschreibe dagegen die Tatsachen und Begleitumstände deines Problems, und formuliere deine Frage so klar wie du nur kannst. Das ist eine bessere Art, dich zu präsentieren, als es Erniedrigung je sein kann.

Manchmal haben Web-Foren eine eigene Abteilung für Fragen von Neulingen. Wenn du glaubst, deine Frage fällt in diese Kategorie, scheue dich nicht, dort hinzugehen. Erniedrige dich aber auch nicht dort.

Beschreibe die Problemsymptome, nicht deine Vermutungen

Es ist nicht hilfreich, Hackern zu sagen, was du als Ursache deines Problems vermutest. (Wenn deine diagnostischen Theorien so toll wären, würdest du dann andere zu Rate ziehen?) Also erzähle ihnen lieber die reinen Symptome, und nicht deine Interpretationen und Theorien. Lass die Helfenden die Diagnose stellen. Wenn du denkst, es ist wichtig, deine Vermutung mit anzugeben, erkläre es ausdrücklich als solche und beschreibe, warum dich diese Antwort nicht weiter bringt.

dumm:
Ich bekomme ständig einen SIG11 Fehler beim Compilieren des Kernels, und vermute einen Haar-Riss bei einer Leiterbahn auf dem Motherboard. Wie kann ich die am besten finden?
intelligent:
Mein selbst zusammengebauter K6/233 auf einem FIC-PA2007 Motherboard (VIA Apollo VP2 Chipsatz) mit 256MB Corsair PC133 SDRAM bekommt wiederholte SIG11 Fehlermeldungen nach ca. 20 minütiger Einschaltzeit während des Kernelcompilierens, aber niemals während der ersten 20 Minuten. Ein Reboot verschafft mir diese zwanzigminütige Fehlerfreiheit nicht, lediglich das Ausschalten über Nacht hilft. Ein Austauschen des RAMs hat nichts gebracht. Der relevante Teil eines typischen Compilier-logs sieht so aus:

Beschreibe die Symptome deines Problems in chronologischer Reihenfolge

Manchmal liegen die hilfreichen Indizien in den Ereignissen unmittelbar vor dem Auftreten des Problems. Also sollte deine Beschreibung genau alles das beinhalten, was du tatest, und was der Computer und die Software taten, als es zum Fehler kam. Bei Kommandozeilenprogrammen ist es hilfreich, ein Log der Sitzung (zum Beispiel mit dem Utility script erstellt) an die Mail anzufügen. Die letzten (relevanten) 20 vor dem Fehler können Hinweise auf den Fehler beinhalten und sind sehr hilfreich.

Wenn das Programm Diagnose-Optionen (wie -v für verbose, ausführlich) hat, versuche die Optionen zu verwenden, die hilfreiche Informationen zur Ausgabe anfügen. Bedenke, dass mehr nicht immer besser ist; wähle ein Debuglevel, welches informiert und nicht den Leser mit nutzlosen Informationen plattwalzt.

Ist deine Beschreibung lang (mehr als 4 Absätze), kann es hilfreich sein, kurz das Problem am Beginn der Mail zu umschreiben, und danach die ganze Geschichte in zeitlicher Abfolge zu erzählen. Dadurch weiß der Hacker schon im Voraus, worauf er in der Beschreibung achten muss.

Beschreibe das Ziel, nicht einen Schritt

Wenn du herausfinden willst, wie du etwas bewerkstelligen kannst (und nicht etwa einen Bug melden willst), beginne damit, dein Ziel zu beschreiben. Erst danach solltest du den Schritt, der dich aufhält, beschreiben.

Oft haben Leute einen Weg eingeschlagen, von dem sie glauben, dass er zum Ziel führt. In Wirklichkeit stecken sie aber in einer Sackgasse. Sie bitten um Hilfe mit einem bestimmten Schritt, erkennen aber nicht, dass der gewählte Weg nicht weiterführt. Es kostet dann oft viel Mühe, sie aufs richtige Gleis zu setzen.

dumm:
Wie bringe ich den Farb-Wähler des FooDraw Zeichenprogramms dazu, einen hexadezimalen RGB-Wert anzunehmen?
intelligent:
Ich versuche, die Farbpalette eines Bildes mit anderen Werten zu besetzen. Bis jetzt habe ich dazu jeden Tabelleneintrag verändert, aber ich kann FooDraws Farb-Wähler nicht dazu bringen, einen hexadezimalen RGB-Wert anzunehmen.

Die zweite Version der Frage ist schlauer, denn sie ermöglicht es, ein besseres Werkzeug für diese Arbeit vorzuschlagen.

Verlange keine Antworten durch private Mails

Hacker glauben, dass das Lösen von Problemen ein öffentlicher, transparenter Prozess sein sollte. Ist der erster Versuch einer Antwort unvollständig oder fehlerhaft, kann jemand mit genaueren Kenntnissen ihn korrigieren oder ergänzen. Das geht nur in einem öffentlichen Diskurs. Zudem ziehen sie einen Teil ihrer Belohnung für die Tätigkeit als Beantworter aus der Tatsache, sich vor ihren Kollegen als kompetent und kenntnisreich zeigen zu können.

Wenn du um eine private Antwort bittest, zerstörst du sowohl den Prozess als auch die Belohnung. Tu das nicht. Es ist die Entscheidung des Antwortenden, ob er privat antwortet – und wenn er das tut, dann üblicherweise, weil er die Frage als zu schlecht gestellt oder zu offensichtlich einschätzt, um für andere interessant zu sein.

Es gibt eine bestimmte Ausnahme dieser Regel: Wenn du denkst, auf die Frage wahrscheinlich eine große Anzahl gleich lautender Antworten zu erhalten, dann sind die magischen Worte: Mailt mir und ich werde die Antwort für die Gruppe zusammenfassen angebracht. Es zeugt von gutem Benehmen, die Mailingliste oder Newsgroup vor einer Flut inhaltlich identischer Beiträge zu bewahren – du musst dein Versprechen der Zusammenfassung dann aber auch halten.

Stelle eine deutliche Frage

Nicht klar abgegrenzte Fragen werden als (zeitlich) nicht abgegrenzte Zeitverschwendung aufgefasst. Die Personen, die dir am ehesten eine hilfreiche Antwort geben könnten, sind meistens auch sehr beschäftigt (und sei es nur, weil sie sich die meiste Arbeit aufhalsen lassen). Solche Leute reagieren allergisch auf nicht abgegrenzte Zeitverschwendung und deshalb auch auf nicht abgegrenzte Fragen.

Du wirst eher eine hilfreiche Antwort bekommen, wenn du genau sagst, was du als Antwort erwartest (gebt mir Starthilfen, schickt Code, kontrolliert euren Patch, was auch immer). Das wird ihre Aufmerksamkeit bündeln und implizit eine Obergrenze der Zeit setzen, in der man damit beschäftigt ist, dir zu helfen. Das ist gut.

Um die Welt, in der Experten leben, zu verstehen, stelle dir Expertenmeinung als eine üppig vorhandene Ressource und Zeit zum Antworten als knappe Ressource vor. Je weniger Zeitaufwand du implizit verlangst, desto wahrscheinlicher wird dir von einem wirklich guten und beschäftigten Experten geholfen.

Es ist also sinnvoll, die Frage einzugrenzen, um den Zeitaufwand für die Antwort eines Experten möglichst gering zu halten – das ist oft nicht gleichbedeutend mit Vereinfachung der Frage. So ist die Frage Kann mir jemand einen Verweis auf gute Dokumentation zu X geben? geschickter als Kann mir bitte jemand X erklären?. Hast du fehlerhaften Code, ist es üblicherweise klüger zu fragen, ob dir jemand den Fehler erklären, kann, als um eine fehlerbereinigte Version zu bitten.

Wenn du nach Code fragst

Bitte nicht andere, deinen eigenen fehlerhaften Code zu debuggen, ohne anzugeben welche Art von Problem darin enthalten ist. Wenn du einige hundert Zeilen Code postest und nur sagst es geht nichti, dann wirst du wahrscheinlich ignoriert werden. Wenn du hingegen ein Dutzend Codezeilen präsentierst und sagst: in Zeile 7 erwarte ich mir <x>, erhalte aber <y>, dann ist es sehr viel wahrscheinlicher, dass man dir hilft.

Die effektivste Weise, einen Fehler zu beschreiben, ist einen minimalen Test vorzulegen, der den Fehler aufzeigt. Was ist ein minimaler Test? Es ist eine Darstellung des Problems; genug um den Fehler aufzuzeigen und nicht mehr. Wie stellt man einen minimalen Test her? Wenn du weißt, in welcher Zeile oder welchem Bereich der Fehler liegt, dann kopiere diesen Teil und füge genau so viel eigenen Code ein, um ein vollständiges Programm zu erhalten (das heißt: genau so viel, um das Beispiel zu übersetzen/interpretieren/was auch immer). Wenn du den bestimmten Bereich nicht verkleinern kannst, kopiere den Code und entferne Teile, die den Problem-Bereich nicht beeinflussen. Je kleiner der Test ist, desto besser (siehe auch Masse ist nicht Genauigkeit).

Man kann nicht immer einen wirklich kleinen Test zusammenstellen, aber es ist eine gute Übung, es trotzdem zu versuchen. Es könnte dir, helfen herauszufinden, was das Problem ist und wie du es selber lösen könntest. Und wenn nicht, dann werden Hacker es honorieren zu sehen, dass du es versucht hast. Das wird sie kooperativer machen.

Wenn du einfach nur einen Code-Review willst, sag das so früh wie möglich und nenne auch die Bereiche, in welchen deiner Meinung nach eine Besprechung des Codes besonders notwendig ist.

Poste keine Hausaufgaben

Hacker kennen Hausaufgaben sehr gut; die meisten von uns haben selber welche gemacht. Diese Aufgaben sind aber für dich gedacht, damit du damit arbeitest und daraus lernst. Es geht in Ordnung, nach kleinen Hilfen zu fragen, aber nicht nach ganzen Lösungen.

Wenn du vermutest, du hast eine Frage, welche leicht als Hausaufgabe durchgehen würde, und du sie trotzdem nicht lösen kannst, frage in einem Benutzer-Forum oder (als letzte Anlaufstelle) eine user-Liste oder im Forum eines Projektes. Obwohl die darin vorhandenen Hacker deine Frage wahrscheinlich als Hausaufgabe entlarven werden, wird dir vielleicht ein erfahrener User zumindest einen Tipp geben.

Vermeide aussagenlose Fragen

Widerstehe der Versuchung, mit inhaltslosen Fragen wie Kann mir jemand helfen? oder Gibt es eine Antwort darauf? zu schließen. Erstens: Wenn du deine Frage halbwegs kompetent gestellt hast, sind solche angehängte Floskeln allerhöchstens überflüssig. Zweitens: Weil sie überflüssig sind, werden sie als störend empfunden, und Hacker neigen dazu, logisch unantastbare, aber wenig hilfreiche Antworten zu schicken wie Ja, jemand kann dir helfen oder Nein, dir ist nicht mehr zu helfen.

Allgemein sind Ja-oder-nein-Fragen zu vermeiden, außer du willst eine Ja-oder-nein-Antwort.

Kennzeichne deine Fragen nicht als wichtig, auch wenn sie es für dich sind

Das ist dein Problem, nicht unseres. Dringlichkeit anzumelden ist eher kontraproduktiv: Viele Hacker werden die Mitteilung als frechen und selbstsüchtigen Versuch, sofortige und besondere Aufmerksamkeit zu erheischen, löschen.

Es gibt eine halbe Ausnahme zu dieser Regel: Es kann hilfreich sein, es anzumerken, wenn du das Programm in einem hoch-technischen oder wichtigen Bereich verwendest, welcher aufregend für Hacker ist. Wenn das der Fall ist, und du unter Zeitdruck stehst, und es freundlich sagst, könnten Leute interessiert genug sein, um dir schneller zu antworten.

Das ist aber ein riskanter Schachzug, weil dein Maßstab, was aufregend ist und was nicht, möglicherweise von dem eines Hackers verschieden ist. Die Tatsache, dass du von der internationalen Raumstation aus schreibst, könnte zum Beispiel genügen, aber ein Posting für eine karitative oder politische Einrichtung wird wahrscheinlich nicht als so wichtig empfunden. Ein Posting wie Wichtig! Helft mir, die kleinen flauschigen Seehunde-Babies zu retten wird wahrscheinlich ignoriert oder geflamed werden, sogar von Hackern, denen kleine flauschige Seehunde-Babies wichtig sind.

Wenn du das unverständlich findest, lies den Rest dieses Textes noch einmal durch, solange, bis du es verstanden hast, bevor du irgend etwas postest.

Höflichkeit tut nie weh und hilft manchmal

Sei höflich. Verwende Bitte und Danke für eure Aufmerksamkeit oder Danke für die Mühe. Zeige, dass du die Zeit schätzt, die andere damit verbringen, dir unentgeltlich zu helfen.

Um ehrlich zu sein, ist Höflichkeit nicht so wichtig wie (und auf keinen Fall Ersatz für) grammatikalische Korrektheit, Klarheit, Genauigkeit und inhaltliche Vollständigkeit, Fehlen von proprietären Formaten usw.; Hacker honorieren im Allgemeinen eher kurz angebundene, aber technisch korrekte Bug Reports als höfliche Verschwommenheit. (Wenn dich das wundert, denke daran, dass wir eine Frage nach ihrem Lerneffekt beurteilen.)

In jedem Fall, wenn du deine Hausaufgaben in technischer Hinsicht gemacht hast, erhöht Höflichkeit die Wahrscheinlichkeit einer Antwort.

(Es sei angemerkt, dass sich der einzige ernsthafte Einwand von Hackerveteranen zu dieser HOWTO auf die Empfehlung bezieht, Danke im Voraus zu verwenden. Manche Hacker empfinden dies als Ankündigung, dass kein Dank nach der Antwort zu erwarten ist. Die Empfehlung ist, dich davor und danach zu bedanken, oder eine andere Höflichkeitsformel zu verwenden, wie etwa Vielen Dank für eure Bemühungen.)

Poste anschließend eine kleine Anmerkung zur Lösung

Sende eine kleine Anmerkung an alle, die dir geholfen haben; lass sie wissen, wie du die Lösung gefunden hast und bedanke dich nochmals für ihre Hilfe. Wenn ein Problem öffentliches Interesse z.B. in einer Mailing-Liste oder einer Newsgroup erregt hat, poste dort.

Am besten sollte sie im Diskussionsfaden erfolgen, den die Frage angestoßen hat, und sollte 'FIXED' oder 'GELÖST' oder ein ähnlich aussagekräftiges Wort in der Betreffzeile enthalten. In hoch frequentierten Mailing-Listen kann ein potentieller beantworter einen Thread, der mit GELÖST endet, auslassen, ohne Zeit zu verlieren (es sei denn, er/sie findet das Problem X interessant) und kann stattdessen die Zeit verwenden, ein anderes Problem zu lösen.

Deine Mitteilung muss nicht lang und ausführlich sein; ein einfaches Hallo - es war ein kaputtes Netzkabel! Danke an alle - Bill ist besser als nichts. Tatsächlich ist eine kurze und nette Zusammenfassung besser als eine längliche Ausführung, es sei denn, sie hat ausreichend technischen Gehalt. Sage, welche Aktion geholfen hat, ohne die gesamte Fehlersuche zu wiederholen.

Für Probleme mit einiger Tiefe ist es angebracht, eine Zusammenfassung des Lösungsvorganges zu posten. Beschreibe die Fehlerursache und deren Symptome. Gib eine Lösung an und zeige eventuelle Sackgassen auf. Die Sackgassen sollten nach der Beschreibung der Lösung und eventueller Zusammenfassung wichtiger Details kommen: verwandle deine Zusammenfassung nicht in eine Detektivgeschichte. Nenne die Namen derer, die dir halfen; du machst dir auf diese Art Freunde.

Neben Höflichkeit und Information hilft dieses Antwortschreiben anderen, die das Archiv der Mailing-Liste/Newsgroup oder des Forums durchsuchen, die Lösung zu finden. Du kannst ihnen viel Mühe ersparen.

Des Weiteren gibt diese Art von Antwortschreiben den Helfern ein befriedigendes Gefühl, dass das Problem abgeschlossen ist. Wenn du selber kein Technikfreak oder Hacker bist, glaub uns, dass das ein sehr wichtiges Gefühl für die Experten und Gurus ist, die du um Hilfe gebeten hast. Probleme, die in ein ungelöstes Nichts aufgehen, sind frustrierend; Hacker juckt es in den Fingern, sie gelöst zu wissen. Der gute Eindruck, den du dadurch hinterlässt, wird dir sehr sehr hilfreich sein, wenn du das nächste mal um Hilfe bittest.

Überlege, wie du das Problem in Zukunft anderen ersparen kannst. Frage nach, ob eine Dokumentation oder eine Änderung der FAQ hilfreich wäre, und wenn du eine positive Antwort bekommst, schicke diese Änderung an die zuständige Stelle.

Unter Hackern ist solches Benehmen viel wichtiger als konventionelle Freundlichkeit. Ein Ruf, gut mit anderen zusammenarbeiten zu können, ist nützlich.

Wie man Antworten interpretiert

RTFM und STFW: Wie man mitteilt, dass du wirklich danebengelangt hast

Es gibt eine alte und ehrwürdige Tradition: Wenn du eine Antwort bekommst, die sich wie RTFM liest, glaubt der Antwortende, du solltest das verdammte Handbuch lesen (Read The Fucking Manual). Er hat aller höchstwahrscheinlich recht. Lies es.

RTFM hat einen jüngeren Verwandten. Wenn du eine Antwort bekommst, die sich wie STFW liest, meint er, du solltest das verdammte Web danach absuchen (Search The Fucking Web). Er hat allerhöchstwahrscheinlich recht. Such danach.

In Web-Foren kann dir auch gesagt werden, im Archiv zu suchen. Auch mag der eine oder andere so freundlich sein, dir einen Link zu einem älteren Diskussionsfaden zu geben, in dem dein Problem gelöst wurde. Vertraue aber nicht auf diese Möglichkeit; suche selber danach, bevor du fragst.

Oft hat die Person, die eine dieser Antworten gibt, das Handbuch oder eine Webseite mit den gesuchten Informationen während des Tippens vor sich liegen. Eine solche Antwort bedeutet, dass (a) die gesuchte Information einfach zu finden ist, und (b) du mehr lernen wirst, wenn du sie dir selber suchst, anstatt sie dir bequem einlöffeln zu lassen.

Du solltest dich dadurch nicht angegriffen fühlen; auf Hackerart wird dir in ungeschliffener Weise einfach schon dadurch Respekt gezeigt, dass du nicht völlig ignoriert wirst. Du solltest stattdessen für solche großmütterliche Güte dankbar sein.

Wenn du nicht verstehst...

Wenn du eine Antwort nicht verstehst, schick nicht sofort eine Rückantwort, mit einer Bitte um Klärung. Verwende die gleichen Quellen, die du zur Lösung deines Problems herangezogen hast (Handbücher, FAQs, das Web, erfahrene Freunde) um die Antwort zu verstehen. Danach, solltest du immer noch Hilfe brauchen, zeige in deiner Frage, was du gelernt hast.

Nimm an, es wird dir gesagt: Es schaut nach einem festgefahrenen Zentry (das Beispiel verwendet absichtlich ein Wort, das gar keine Bedeutung hat, um das 'Nachhaken' zu provozieren, Anm.d.Übers.) aus. Den musst du wieder lösen. Hier ist eine schlechte Frage: Was ist ein Zentry? Und hier ist eine gute Frage: Ich habe die manpage gelesen und Zentries werden nur bei den Optionen -z und -p erwähnt. Aber nirgends wird beschrieben, wie man Zentries löst. Ist eine der beiden Optionen das, was ich brauche oder habe ich etwas übersehen?

Umgang mit Grobheit

Vieles, das wie Grobheit aussieht, ist in Hacker-Kreisen nicht als Beleidigung gedacht. Es ist im Gegenteil das Produkt einer direkten Art der Kommunikation ohne Umschweife, die Personen zu eigen ist, die mehr daran interessiert sind, Probleme zu lösen, als andere sich liebgehabt und geborgen fühlen zu lassen.

Wenn dir rohes Verhalten entgegengebracht wird, reagiere gelassen. Wenn jemand wirklich übertreibt, wird ihn sehr wahrscheinlich ein alter Hase in der Gruppe zurechtweisen. Wenn das nicht passiert und du deine Beherrschung verlierst, hat die betreffende Person sich wahrscheinlich an die in der Gruppe herrschenden Regeln gehalten, und du dich falsch benommen. Das wird deine Chance auf kompetente Hilfe verringern.

Auf der anderen Seite wirst du gelegentlich auf sinnlose oder ungerechtfertigte Rüpelhaftigkeit stoßen. Die andere Seite des oben Gesagten ist, dass es akzeptiertes Verhalten ist, wirklich ausfallende Personen hart zurechtzuweisen und deren falsches Benehmen mit scharfem Messer verbal zu sezieren. Sei dir deines Grundes deshalb sehr sehr sicher, bevor du so etwas tust. Der Grat zwischen dem Korrigieren eines Missgriffs und dem Lostreten eines endlosen Flamewars ist schmal genug, dass selbst Hacker ihn gelegentlich übertreten; wenn du ein Neuling oder ein Außenseiter bist, stehen die Chancen schlecht, eine solche Übertretung zu vermeiden. Wenn du auf Informationen aus bist und nicht auf Unterhaltung, dann ist es besser, du lässt die Finger von der Tastatur, anstatt so etwas zu riskieren.

(Manche Leute behaupten, dass viele Hacker an einer schwachen Form von Autismus oder des Aspergerschen Syndroms leiden, und ihnen einige der Hirnwindungen fehlen, welche die 'normalen' zwischenmenschlichen Beziehungen steuern. Das mag stimmen oder auch nicht. Wenn du selber kein Hacker bist, kann es dir helfen, unsere Exzentrizitäten als die von geistig Gestörten anzusehen. Sieh darüber hinweg. Uns macht das nichts aus; uns gefällt die Art, wie wir sind, und normalerweise haben wir ein gesundes Misstrauen klinischen Bezeichnungen gegenüber.)

Im nächsten Abschnitt werden wir über ein anderes Thema sprechen; die verschiedenen Arten von 'Grobheit', die dir entgegengebracht werden, wenn du dich falsch verhältst.

Nicht wie ein Loser reagieren

Gelegentlich wirst du dich in einem Forum einer Hackergemeinschaft falsch benehmen – in einer hier beschriebenen oder ähnlichen Art. Und dir wird genauestens gesagt werden, wo du dich falsch benommen hast, möglicherweise gespickt mit derben Bemerkungen. Öffentlich.

Wenn das passiert, ist das Schlimmste, was du tun kannst, über diese Erfahrung zu heulen, behaupten, verbal angegriffen worden zu sein, Entschuldigungen zu fordern, schreien, deinen Atem anhalten, Strafanzeigen androhen, bei Arbeitgebern anschwärzen, die Klobrille nicht herunterklappen usw. Du wirst dich hingegen besser folgendermaßen benehmen:

Sieh darüber hinweg. Es ist normal. Ausserdem ist es gesund und angemessen.

Gemeinschaftliche Regeln erhalten sich nicht von alleine: Sie werden von Leuten am Leben gehalten, die sie aktiv anwenden, öffentlich. Weine nicht darüber, dass jede Kritik über private Mail verschickt werden sollte: So wird das nicht gehandhabt. Auch ist es wenig hilfreich zu behaupten, du seist persönlich beleidigt worden, wenn jemand deine Behauptungen als falsch darstellt oder auf anderen Standpunkten steht. Das sind Loserattitüden.

Es hat Hackerforen gegeben, in denen aus übertriebener Freundlichkeit Beiträge, die auf Fehler anderer Teilnehmer aufmerksam gemacht haben, unerwünscht waren und mit einem Sag nichts, wenn du nicht helfen willst! beantwortet wurden. Durch das darauf folgende Abwandern erfahrener Teilnehmer sind diese Foren in inhaltsloses Geplapper abgerutscht und als technische Gruppen nutzlos geworden.

Übertrieben freundlich (in diesem Sinn) oder nützlich: Wähle eines davon.

Nota Bene: Wenn ein Hacker dir sagt, du hättest dich falsch benommen, und dir (ganz egal wie grob) sagt, es nicht wieder zu tun, tut er es erstens dir und zweitens seiner Gemeinschaft zu liebe. Es wäre für ihn viel leichter, dich zu ignorieren und aus seinem Leben herauszufiltern. Wenn du es nicht schaffst, dankbar zu sein, behalte wenigstens ein wenig Würde; heule nicht herum und erwarte auch nicht, wie eine zerbrechliche kleine Puppe behandelt zu werden, nur weil du ein Neuling mit einer theatralisch überempfindlichen Seele und zu hohen Ansprüchen bist.

Hin und wieder wird dich jemand persönlich angreifen, ohne ersichtlichen Grund flamen oder ähnliches anstellen, ohne dass du dich falsch benommen hättest (oder du dich nur in der Einbildung des Angreifers falsch benommen hast). In diesem Fall ist sich darüber zu beschweren, der beste Weg, sich wirklich zu blamieren.

Solche Angreifer sind entweder Schwachköpfe, die sich als Experten aufspielen oder Möchtegern-Psychologen, die testen wollen, ob du dich darauf in die Nesseln setzt. Die Mitleser ignorieren sie entweder oder sie finden einen Weg, mit ihnen umzugehen. Mit ihrem Verhalten bereiten sich die Angreifer selber Probleme, die aber nichts mit dir zu tun haben.

Lass dich nicht dazu verleiten, selbst ein Flamer zu werden. Die meisten Flamer ignoriert man am besten – nachdem man sich vergewissert hat, dass es sich wirklich um eine Flame und nicht um einen Wink mit dem Zaunpfahl handelt, der informieren sollte, dass man sich falsch benommen hat. Manchmal ist ein solcher angeblicher Flame aber auch die mehr oder weniger schlau verschlüsselte Antwort auf die Frage.

Fragen, die man nicht stellen sollte

Hier sind einige klassische und dumme Fragen aufgeführt, und was sich Hacker denken, wenn sie sie nicht beantworten.

Wo kann ich Programm oder Ressource X finden?
Wie kann ich X verwenden, um Y zu tun?
Wie kann ich meinen Shell Prompt ändern?
Kann ich ein AcmeCorp Dokument mit dem Bass-o-matic File Converter im TeX-Format abspeichern?
Mein {Programm, Konfiguration, SQL Ausdruck} geht nicht.
Ich habe Probleme mit meiner Windows-Maschine. Kann jemand helfen?
Mein Programm geht nicht. Ich glaube, die Systemeinheit X ist kaputt.
Ich habe Probleme bei der Installation von Linux oder X. Kann jemand helfen?
Wie kann ich Channel-Operatoren Passworte/Rechte stehlen/cracken, jemandes E-Mail lesen?
Wo kann ich Programm oder Ressource X finden?
Am gleichen Ort, wo ich es gefunden habe, Dummkopf – auf der anderen Seite einer Web-Suche. Mein Gott, gibt es immer noch jemanden, der nicht weiß, wie man Google verwendet?
Wie kann ich X verwenden, um Y zu tun?
Was du willst, ist Y tun, also solltest du diese Frage stellen, ohne verfrühte Annahmen über eine bestimmte Methode zu treffen. Fragen dieser Art kennzeichnen oft Menschen, die zwar nicht vollständig unwissend über X sind, aber sich nicht im Klaren darüber sind, was für ein Problem Y sie lösen sollen und zu sehr auf Details fixiert sind. Es ist im Allgemeinen am besten, solche Personen solange zu ignorieren, bis sie ihr Problem besser definieren.
Wie kann ich meinen Shell Prompt ändern?
Wenn du schlau genug bist, diese Frage zu stellen, dann bist du auch schlau genug, RTFM zu betreiben und es selber herauszufinden.
Kann ich ein AcmeCorp Dokument mit dem Bass-o-matic File Converter im TeX-Format abspeichern?
Probiere es und du wirst es wissen. Wenn du das getan hättest, hättest du (a) die Antwort gefunden und (b) nicht meine Zeit verschwendet.
Mein {Programm, Konfiguration, SQL Statement} geht nicht.
Das ist keine Frage und ich bin nicht bereit, zwanzig Minuten damit zu verbringen, die Frage aus dir herauszukitzeln – ich habe Besseres zu tun. Wenn ich so etwas sehe, ist meine Reaktion eine der folgenden:
  • hast du da nichts hinzuzufügen?
  • oh, das ist jammerschade. Ich hoffe, du bekommst das noch hin.
  • und was hat das jetzt bitte mit mir zu tun?
Ich habe Probleme mit meiner Windows-Maschine. Kann mir jemand helfen? (Eine Bemerkung: du darfst Fragen zu Windows stellen, wenn das Programm, welches du verwendest, einen offiziellen Windows-Port besitzt, oder mit der Windows-Welt interagiert (wie es zum Beispiel Samba tut). Sei aber nicht überrascht über die Antwort, Windows selber sei das Problem, und nicht das Programm, da Windows an sich so kaputt ist, sodass dieser Fall tatsächlich oft zutrifft.)
Ja. Wirf diesen Microsoft-Müll aus dem Fenster und installiere ein Open Source-Betriebssystem wie beispielsweise Linux oder BSD.
Mein Programm geht nicht. Ich denke, die Systemeinheit X ist kaputt.
Obwohl es möglich ist, dass du der einzige bist, der einen augenfälligen Fehler in Systemroutinen gefunden hat, die von hunderten oder tausenden von Leuten verwendet werden, ist es wahrscheinlicher, dass du daran etwas nicht verstanden hast. Besondere Aussagen brauchen besondere Beweise; wenn du eine solche Aussage tätigst, musst du sie mit einer ausführlichen Dokumentation des Fehlerfalls belegen.
Ich habe Probleme bei der Installation von Linux oder X. Kann jemand helfen?
Nein. Es braucht physikalischen Zugriff auf die Maschine, um das zu bewerkstelligen. Frag deine lokale Linux User Group. (Du kannst eine Liste der User Groups hier finden.)
Wie kann ich Channel Operatoren-Rechte stehlen/cracken, jemandes E-Mail lesen?
Du hast wenig Ehrgefühl, so etwas tun zu wollen, und bist schwachsinnig, einen Hacker zu bitten, dir dabei auch noch zu helfen.

Gute und schlechte Fragen

Zum Schluss werde ich einige Beispiele anführen, wie man Fragen auf eine intelligente Weise stellt; paarweise werden Fragen zu einem gleichen Problem gestellt, einmal auf eine dumme, einmal auf eine schlaue Art.

Dumm: Wo kann ich etwas über Foonly Flurbamatic herausfinden?
Diese Frage schreit förmlich nach einem STFW als Antwort.
Schlau:
Ich habe im Web gegoogelt, um Informationen über Foonly Flurbamatic 2600 zu finden, konnte aber nichts Brauchbares finden. Weiß jemand, wo ich eine Programmieranleitung für dieses Gerät finden kann?
Hier wurde schon ge'STFW't, und es schaut so aus, als ob ein wirkliches Problem existieren würde.
Dumm: Ich kann den Code von Projekt Foo nicht compilieren. Warum ist er kaputt?
Er nimmt an, dass jemand anderes Mist gebaut hat. Arrogant von ihm.
Schlau:
Der Code von Projekt Foo compiliert nicht unter Nulix, Version 6.2. Ich habe die FAQ gelesen, aber es steht dort nichts über Probleme in Verbindung von Nulix. Hier ist eine Abschrift meines Compilierversuches; was habe ich falsch gemacht?
Er hat die Umgebung angegeben, die FAQ gelesen, er zeigt den Fehler und er nimmt nicht an, dass andere den Fehler verschuldet hätten. Dieser Typ kann ein wenig Aufmerksamkeit verdienen.
Dumm: Ich habe Probleme mit meinem Motherboard. Kann jemand helfen?
J. Random Hackers Antwort darauf kann sein: Sicher. Musst du auch ein Bäuerchen machen oder sollen die Windeln gewechselt werden?, gefolgt von einem beherzten Druck auf die Delete-Taste.
Schlau:
Ich versuchte X, Y und Z auf dem S2464 Motherboard. Als das nichts fruchtete, habe ich A, B und C probiert. Beachtet das komische Symptom, wenn ich C probiert habe. Natürlich grommickt das Florbish, aber die Ergebnisse sind nicht die, die man erwarten könnte. Was sind die üblichen Ursachen für Grommicks auf einem Athlon Motherboard? Hat jemand eine Idee für weitere Tests, wie ich das Problem eingrenzen könnte?
Diese Person scheint dagegen einer Antwort wert zu sein. Sie zeigte Intelligenz zur Problemlösung, anstatt passiv auf Hilfe von oben zu warten.

Beachte in der letzten Frage den subtilen Unterschied zwischen den Fragen Gib mir eine Antwort und Bitte helft mir, zusätzliche Tests auszudenken, um Erleuchtung zu finden.

Tatsächlich ist die Form der letzten Frage einem wirklichen Fall entnommen, der sich im August 2001 in der Linux Kernel-Mailingliste (lkml) ereignete. Ich (Eric) war derjenige, der damals um Hilfe bat. Ich erlebte mysteriöse Hänger mit meinem Tyan S2462 Motherboard. Die Listenteilnehmer gaben mir die notwendigen Informationen, die ich brauchte.

In der Art, wie ich die Frage stellte, gab ich anderen die Möglichkeit, daran zu kauen; ich machte es ihnen leicht und attraktiv, sich damit zu beschäftigen. Ich zollte meinen Gegenübern Respekt und lud sie ein, mich als Gleichen zu behandeln. Ich zeigte auch, dass ich ihre Zeit respektiere, indem ich fruchtlose Versuche angab, die ich schon ausprobiert hatte.

Nachher, als ich allen dankte und anmerkte, wie gut die Lösung funktionierte, bemerkte ein lkml-Mitglied, mein Posting sei deshalb gut angekommen, nicht weil ich einen Namen auf der Liste hatte, sondern weil ich die Frage in der richtigen Form gestellt hatte.

Hacker bilden in einer bestimmten Hinsicht eine sehr leistungsorientierte Gemeinschaft; ich bin sicher, er hatte recht und ich wäre, wenn ich mich wie ein Depp verhalten hätte, ignoriert und geflamed worden, ganz gleich, welche Stellung ich einnahm. Seine Anregung, den gesamten Vorfall als Beispiel für andere aufzuschreiben, hat direkt zu der Veröffentlichung dieses Textes geführt.

Falls du keine Antwort bekommst

Wenn du keine Antwort bekommen kannst, nimm es bitte nicht persönlich, dass wir uns nicht in der Lage fühlen, dir zu helfen. Manchmal wissen die Teilnehmer einer Gruppe ganz einfach die Antwort nicht. Keine Antwort ist nicht das gleiche wie ignoriert zu werden, auch wenn es von außen schwierig ist, das zu unterscheiden.

Im Allgemeinen ist ein einfaches Wiederposten eine schlechte Idee. Das wird als zwecklose Belästigung angesehen. Habe Geduld: die Person mit deiner gesuchten Antwort könnte gerade schlafen. Oder deine Frage war von Anfang an nicht gut gestellt.

Es gibt andere Quellen, derer du dich bedienen kannst; oft sind sie den Anforderungen von Neulingen besser angepasst.

Es gibt viele lokale User Groups oder welche im Web, die die Programme, die wir schreiben, gut finden, auch wenn sie nie im Leben Software geschrieben haben. Diese Gruppen sind oft gebildet worden, um sich untereinander und Einsteigern zu helfen.

Es gibt auch massenweise große und kleine kommerzielle Firmen, die du um Hilfestellung kontaktieren kannst (Red Hat und Linuxcare sind die zwei bekanntesten; es gibt viele andere). Lass 'dich nicht von der Idee abschrecken, ein wenig für die erhaltene Hilfe zu zahlen! Wenn dein Automotor den Geist aufgibt, wirst du auch zu einem Mechaniker gehen und ihn für die Reparatur bezahlen. Auch wenn die Software an sich nichts kostet, darfst du nicht erwarten, dass auch die Kundenbetreuung dafür immer kostenlos sei.

Für populäre Software wie Linux kommen etwa 10.000 Benutzer auf einen Entwickler. Es ist für eine Person einfach nicht möglich, den Rufen von 10.000 Benutzern nachzukommen. Bedenke, dass du selbst bei zahlungspflichtiger Hilfe viel weniger bezahlen musst, als wenn du die Software kaufen müsstest (und Kundenbetreuung für kommerzielle Produkte ist in der Regel teurer und weniger kompetent als die für Open Source-Projekte).

Fragen auf eine hilfreiche Art beantworten

Sei freundlich. Problembezogener Stress kann Leute grob oder dumm aussehen lassen, auch wenn sie es nicht sind.

Beantworte die erste Übertretung der Netiquette offline. Es gibt keinen Grund, jemanden öffentlich abzukanzeln nur weil er einen kleinen Fehler gemacht hat. Ein wirklicher Neuling weiß manchmal wirklich nicht, wie man im Web sucht oder wo FAQs gespeichert oder gepostet werden.

Wenn du die Antwort nicht sicher weißt, sag das! Eine falsche aber kompetent klingende Antwort ist schlechter als gar keine. Weise niemandem einen falschen Weg, nur weil es lustig ist, sich wie ein Experte anzuhören. Sei bescheiden und ehrlich; sei ein gutes Beispiel für Fragende und für deine Kollegen.

Wenn du nicht helfen kannst, behindere niemanden. Erlaube dir keine Späße, die die Einstellungen des Fragenden durcheinander bringen könnten – der arme Tropf könnte sie als Anleitung verstehen.

Stelle Fragen, um mehr Details herauszufinden. Wenn du gut darin bist, kann der Fragende etwas lernen, und du nebenbei auch. Versuche, die schlechte Frage in eine gute zu verwandeln. Denke daran, das wir alle einmal Anfänger waren.

Einfach RTFM zu brummeln ist manchmal bei einem sehr faulen Fragesteller gerechtfertigt, ein Fingerzeig auf die richtige Dokumentation (sei es auch nur der Vorschlag guter Stichworte für Google) ist besser.

Beantwortest du eine Frage vollständig, dann beantworte sie gut. Schlage keine wackligen Workarounds vor, wenn jemand eine falsche Methode oder ein unangemessenes Tool vorgeschlagen hat. Schlage gute Programme vor. Formuliere die Frage neu.

Beantworte die eigentliche Frage! Wenn der Fragesteller schon gründlich gesucht hat und in seiner Frage geschrieben hat, dass er schon X, Y, Z, A, B, und C ohne Erfolg ausprobiert hat, dann ist es nicht sehr hilfreich, mit versuche A oder B zu antworten oder mit einem Link auf eine Seite zu verweisen, die vorschlägt, X, Y, Z, A, B, oder C zu probieren.

Hilf der Gemeinschaft, aus der Frage zu lernen. Wenn du auf eine gute Frage triffst, frage dich Wie müsste die betreffende FAQ oder Dokumentation geändert werden, damit niemand mehr diese Frage beantworten muss? Dann schicke einen Verbesserungsvorschlag an den Zuständigen.

Wenn du für eine Antwort nachforschen musstest, zeige deine Fähigkeit zur Suche, anstatt so zu tun, als ob du dir die Antwort aus dem Ärmel geschüttelt hättest. Eine Frage zu beantworten ist wie einer hungrigen Person ein Essen zu geben; an Beispielen zu zeigen, wie man Informationen findet, heißt zu zeigen, wie man ein Leben lang Essen produziert.

Wenn du Informationen zu den Grundlagen suchst, wie Computer, Unix und das Internet funktionieren, siehe The Unix and Internet Fundamentals HOWTO.

Wenn du Software freigibst oder Patches für Software schreibst, versuche den Richtlinien in Software Release Practice HOWTO zu folgen.

Besonderer Hinweis für FAQ Listen-Maintainer und Webmaster

Viele Webseiten, Newsgroups und andere Online-Foren verlinken diesen Text als Hilfe für Newbies. Die Autoren freuen sich darüber. Aber: Bitte füge neben dem Link einen fett gedruckten Hinweis, dass wir kein Help-Desk für dein Projekt sind. Wir bekommen zu viele Anfragen von Leuten, die das Gegenteil annehmen.

Danksagung

Evelyn Mitchell ergänzte einige Beispiele zu dummen Fragen und inspirierte den Teil Wie man gute Antworten gibt. Mikhail Ramendik trug zwei besonders wertvolle Verbesserungsvorschläge bei.