By lars — 30. Juli 2022

Wie Sie auf intelligente Weise Fragen stellen

Hinweis: dieser Artikel stammt nicht von mir und wurde im ursprünglichen auf Englisch verfasst. Diesen Artikel gibt es inzwischen nicht mehr im Internet, denn die Webseite ist seit einiger Zeit nicht mehr zu erreichen.

Ein Hinweis auf diesen Artikel habe ich bekommen über das Social-Media Netzwerk Fediverse. Da dieser Hinweis auch schon ewig her ist kann ich diesen ursprünglichen Post auch nicht mehr finden. Da ich den ursprünglichen Autor angeschrieben hatte aber keine rückmeldung mehr erhalten habe, das schlichtweg die E-Mail-Adresse nicht mehr existiert, habe ich mich dazu entschlossen nun diesen Artikel zu veröffentlichen, ungekürzt aber vom englischen ins Deutsche übersetzt.

Aus diesem Grunde erscheint der Artikel auch in der Sie-Form.

Haftungsausschluss

Viele Projektwebseiten verlinken in ihren Abschnitten, in denen Sie Hilfe erhalten, auf dieses Dokument. Das ist in Ordnung, das ist die Nutzung, die wir beabsichtigt haben – aber wenn Sie ein Webmaster sind, der einen solchen Link für seine Projektseite erstellt, zeigen Sie bitte deutlich sichtbar in der Nähe des Links an, dass wir kein Helpdesk für Ihr Projekt sind!

Wir haben auf die harte Tour gelernt, dass wir ohne einen solchen Hinweis immer wieder von Idioten belästigt werden, die glauben, dass es unsere Aufgabe ist, alle technischen Probleme der Welt zu lösen, weil wir dieses Dokument veröffentlicht haben.

Wenn Sie dieses Dokument lesen, weil Sie Hilfe benötigen und den Eindruck haben, dass Sie diese direkt von den Autoren dieses Dokuments erhalten können, dann sind Sie einer dieser Idioten, von denen wir sprechen. Stellen Sie uns keine Fragen. Wir werden Sie einfach ignorieren. Wir sind hier, um Ihnen zu zeigen, wie Sie Hilfe von Leuten bekommen, die sich tatsächlich mit der Software oder Hardware auskennen, mit der Sie zu tun haben, aber in 99,9% der Fälle werden das nicht wir sein. Solange Sie nicht sicher sind, dass einer der Autoren ein Experte auf dem Gebiet ist, mit dem Sie zu tun haben, sollten Sie uns in Ruhe lassen, damit alle zufrieden sind.

Einführung

In der Welt der Hacker hängt die Art der Antworten, die Sie auf Ihre technischen Fragen erhalten, ebenso sehr von der Art und Weise ab, wie Sie die Fragen stellen, wie auch von der Schwierigkeit, die Antwort zu entwickeln. In diesem Leitfaden lernen Sie, wie Sie Fragen so stellen, dass Sie mit größerer Wahrscheinlichkeit eine zufriedenstellende Antwort erhalten.

Da die Nutzung von Open Source inzwischen weit verbreitet ist, erhalten Sie von anderen, erfahreneren Benutzern oft genauso gute Antworten wie von Hackern. Das ist eine gute Sache, denn die Benutzer sind in der Regel etwas toleranter gegenüber den Fehlern, die Neulinge oft haben. Dennoch ist es in der Regel am effektivsten, erfahrene Benutzer wie Hacker zu behandeln, so wie wir es hier empfehlen, um auch von ihnen nützliche Antworten zu erhalten.

Zunächst einmal müssen Sie verstehen, dass Hacker schwierige Probleme und gute, zum Nachdenken anregende Fragen zu diesen Problemen mögen. Wenn wir das nicht täten, wären wir nicht hier. Wenn Sie uns eine interessante Frage zum Nachdenken geben, sind wir Ihnen dankbar; gute Fragen sind ein Ansporn und ein Geschenk. Gute Fragen helfen uns, unser Verständnis zu entwickeln, und decken oft Probleme auf, die wir sonst vielleicht nicht bemerkt oder bedacht hätten. Unter Hackern ist „Gute Frage!“ ein starkes und aufrichtiges Kompliment.

Trotzdem haben Hacker den Ruf, einfachen Fragen mit etwas zu begegnen, das wie Feindseligkeit oder Arroganz aussieht. Es sieht manchmal so aus, als wären wir reflexartig unhöflich gegenüber Neulingen und Unwissenden. Aber das ist nicht wirklich wahr.

Was wir sind, ist ohne Umschweife feindselig gegenüber Menschen, die nicht bereit sind, nachzudenken oder ihre eigenen Hausaufgaben zu machen, bevor sie Fragen stellen. Solche Leute sind Zeitfresser – sie nehmen, ohne etwas zurückzugeben, und sie verschwenden Zeit, die wir für eine andere, interessantere Frage und eine andere Person, die einer Antwort würdiger ist, hätten verwenden können. Wir nennen solche Leute „Verlierer“ (und aus historischen Gründen buchstabieren wir es manchmal „lusers“).

Wir wissen, dass es viele Menschen gibt, die einfach nur die von uns geschriebene Software nutzen wollen und kein Interesse daran haben, technische Details zu lernen. Für die meisten Menschen ist ein Computer lediglich ein Werkzeug, ein Mittel zum Zweck; sie haben Wichtigeres zu tun und ein Leben zu führen. Wir erkennen das an und erwarten nicht, dass sich jeder für die technischen Dinge interessiert, die uns faszinieren. Dennoch ist unser Stil der Beantwortung von Fragen auf Menschen abgestimmt, die ein solches Interesse haben und bereit sind, sich aktiv an der Problemlösung zu beteiligen. Das wird sich nicht ändern. Das sollte es auch nicht, denn sonst wären wir bei dem, was wir am besten können, nicht mehr so effektiv.

Wir sind (größtenteils) Freiwillige. Wir nehmen uns Zeit für die Beantwortung von Fragen, und manchmal werden wir von ihnen überwältigt. Also filtern wir rücksichtslos. Insbesondere werfen wir Fragen von Leuten weg, die uns als Verlierer erscheinen, um unsere Zeit für die Beantwortung von Fragen effizienter zu nutzen – für Gewinner.

Wenn Sie diese Haltung unausstehlich, herablassend oder arrogant finden, sollten Sie Ihre Annahmen überprüfen. Wir verlangen nicht, dass Sie sich vor uns verneigen – die meisten von uns würden nichts lieber tun, als Ihnen auf Augenhöhe zu begegnen und Sie in unserer Kultur willkommen zu heißen, wenn Sie sich die Mühe machen, die dafür erforderlich ist. Aber es ist einfach nicht effizient, wenn wir versuchen, Menschen zu helfen, die nicht bereit sind, sich selbst zu helfen. Es ist in Ordnung, unwissend zu sein; es ist nicht in Ordnung, sich dumm zu stellen.

Es ist zwar nicht notwendig, technisch kompetent zu sein, um von uns beachtet zu werden, aber Sie müssen die Einstellung an den Tag legen, die zu Kompetenz führt – aufmerksam, nachdenklich, aufmerksam, bereit, ein aktiver Partner bei der Entwicklung einer Lösung zu sein. Wenn Sie mit dieser Art von Diskriminierung nicht leben können, schlagen wir vor, dass Sie jemanden für einen kommerziellen Supportvertrag bezahlen, anstatt Hacker zu bitten, Ihnen persönlich Hilfe zukommen zu lassen.

Wenn Sie sich entscheiden, uns um Hilfe zu bitten, wollen Sie nicht zu den Verlierern gehören. Sie wollen auch nicht wie einer erscheinen. Der beste Weg, eine schnelle und reaktionsschnelle Antwort zu erhalten, ist, wie eine Person mit Intelligenz, Selbstvertrauen und Hinweisen zu fragen, die zufällig Hilfe bei einem bestimmten Problem benötigt.

(Verbesserungen an diesem Leitfaden sind willkommen. Sie können Ihre Vorschläge an esr@thyrsus.com oder respond-auto@linuxmafia.com schicken. Beachten Sie jedoch, dass dieses Dokument nicht als allgemeiner Leitfaden für die Netiquette gedacht ist, und dass wir Vorschläge, die sich nicht speziell auf die Erlangung nützlicher Antworten in einem technischen Forum beziehen, in der Regel ablehnen werden).

Bevor Sie fragen

Bevor Sie eine technische Frage per E-Mail, in einer Newsgroup oder in einem Website-Chatboard stellen, sollten Sie Folgendes tun:

Versuchen Sie, eine Antwort zu finden, indem Sie die Archive des Forums oder der Mailingliste durchsuchen, in die Sie schreiben möchten.
Versuchen Sie, eine Antwort zu finden, indem Sie das Internet durchsuchen.
Versuchen Sie, eine Antwort zu finden, indem Sie das Handbuch lesen.
Versuchen Sie, eine Antwort zu finden, indem Sie eine FAQ lesen.
Versuchen Sie, eine Antwort zu finden, indem Sie das Gerät inspizieren oder ausprobieren.
Versuchen Sie, eine Antwort zu finden, indem Sie einen erfahrenen Freund fragen.
Wenn Sie ein Programmierer sind, versuchen Sie, eine Antwort zu finden, indem Sie den Quellcode lesen.

Wenn Sie Ihre Frage stellen, zeigen Sie, dass Sie diese Dinge vorher getan haben. So können Sie beweisen, dass Sie kein fauler Schwamm sind und die Zeit anderer Leute vergeuden. Besser noch: Zeigen Sie, was Sie dabei gelernt haben. Wir beantworten gerne Fragen für Leute, die gezeigt haben, dass sie aus den Antworten lernen können.

Nutzen Sie Taktiken wie eine Google-Suche nach dem Text der Fehlermeldung, die Sie erhalten (durchsuchen Sie sowohl Google-Gruppen als auch Webseiten). Dies könnte Sie direkt zur Dokumentation der Fehlerbehebung oder zu einem Thread auf der Mailingliste führen, der Ihre Frage beantwortet. Selbst wenn dies nicht der Fall ist, sollten Sie in E-Mails oder News-Postings, in denen Sie um Hilfe bitten, sagen: „Ich habe nach folgendem Satz gegoogelt, aber nichts gefunden, was vielversprechend aussah“, und sei es nur, weil Sie damit festhalten, welche Suchanfragen nicht weiterhelfen. Es hilft auch, andere Personen mit ähnlichen Problemen auf Ihren Thread zu verweisen, indem Sie die Suchbegriffe mit dem Thread zu Ihrem Problem und der Lösung verknüpfen.

Nehmen Sie sich Zeit. Erwarten Sie nicht, dass Sie ein kompliziertes Problem mit ein paar Sekunden Googeln lösen können. Lesen und verstehen Sie die FAQs, lehnen Sie sich zurück, entspannen Sie sich und denken Sie über das Problem nach, bevor Sie sich an Experten wenden. Glauben Sie uns, sie werden an Ihren Fragen erkennen, wie viel Sie gelesen und nachgedacht haben, und sie werden eher bereit sein zu helfen, wenn Sie vorbereitet sind. Werfen Sie nicht gleich Ihr ganzes Arsenal an Fragen ab, nur weil Ihre erste Suche keine (oder zu viele) Antworten ergeben hat.

Bereiten Sie Ihre Frage vor. Denken Sie sie durch. Hastig gestellte Fragen führen zu hastigen Antworten oder zu gar keinen. Je mehr Sie zeigen, dass Sie sich Gedanken und Mühe gemacht haben, bevor Sie Hilfe suchen, desto wahrscheinlicher ist es, dass Sie tatsächlich Hilfe bekommen.

Hüten Sie sich davor, die falsche Frage zu stellen. Wenn Sie eine Frage stellen, die auf falschen Annahmen beruht, ist es sehr wahrscheinlich, dass J. Random Hacker mit einer nutzlosen wörtlichen Antwort antwortet und dabei denkt: „Dumme Frage…“ und hofft, dass die Erfahrung, dass Sie das bekommen, was Sie gefragt haben, anstatt das, was Sie brauchten, Ihnen eine Lektion erteilt.

Gehen Sie niemals davon aus, dass Sie ein Recht auf eine Antwort haben. Das haben Sie nicht, schließlich bezahlen Sie ja nicht für den Service. Sie werden eine Antwort erhalten, wenn Sie sie sich verdienen, indem Sie eine substanzielle, interessante und zum Nachdenken anregende Frage stellen – eine Frage, die implizit zu den Erfahrungen der Gemeinschaft beiträgt, anstatt lediglich passiv Wissen von anderen einzufordern.

Andererseits ist es ein sehr guter Anfang, wenn Sie deutlich machen, dass Sie in der Lage und bereit sind, bei der Entwicklung der Lösung zu helfen. „Könnte mir jemand einen Hinweis geben?“, „Was fehlt in meinem Beispiel?“ und „Auf welcher Website sollte ich nachsehen?“ werden mit größerer Wahrscheinlichkeit beantwortet als „Bitte posten Sie die genaue Vorgehensweise, die ich anwenden soll.“, denn Sie machen damit deutlich, dass Sie wirklich bereit sind, den Prozess zu vollenden, wenn Ihnen jemand nur die richtige Richtung weisen kann.

Wenn Sie fragen

Wählen Sie Ihr Forum sorgfältig aus
Wählen Sie mit Bedacht aus, wo Sie Ihre Frage stellen. Sie werden wahrscheinlich ignoriert oder als Verlierer abgestempelt, wenn Sie:
Ihre Frage in einem Forum stellen, in dem sie nicht zum Thema gehört
eine sehr einfache Frage in einem Forum stellen, in dem fortgeschrittene technische Fragen erwartet werden, oder umgekehrt
Cross-Posting in zu vielen verschiedenen Newsgroups
posten Sie eine persönliche E-Mail an jemanden, der weder ein Bekannter von Ihnen ist noch persönlich für die Lösung Ihres Problems zuständig ist
Hacker blasen Fragen ab, die nicht zielgerichtet sind, um ihre Kommunikationskanäle davor zu schützen, in der Belanglosigkeit zu versinken. Sie wollen nicht, dass Ihnen das passiert.

Der erste Schritt besteht also darin, das richtige Forum zu finden. Auch hier sind Google und andere Web-Suchmethoden Ihr Freund. Nutzen Sie sie, um die Projektwebseite zu finden, die am engsten mit der Hardware oder Software verbunden ist, die Ihnen Schwierigkeiten bereitet. In der Regel finden Sie dort Links zu einer FAQ-Liste (Frequently Asked Questions) und zu Projekt-Mailinglisten und deren Archiven. Diese Mailinglisten sind die letzte Anlaufstelle, wenn Ihre eigenen Bemühungen (einschließlich der Lektüre der FAQs, die Sie gefunden haben) nicht zu einer Lösung führen. Möglicherweise ist auf der Projektseite auch ein Verfahren zur Meldung von Fehlern beschrieben oder ein Link zu einem solchen Verfahren angegeben; wenn dies der Fall ist, sollten Sie es befolgen.

Eine E-Mail an eine Person oder ein Forum zu schicken, mit dem Sie nicht vertraut sind, ist bestenfalls riskant. Gehen Sie zum Beispiel nicht davon aus, dass der Autor einer informativen Webseite Ihr kostenloser Berater sein möchte. Stellen Sie keine optimistischen Vermutungen darüber an, ob Ihre Frage willkommen sein wird – wenn Sie sich nicht sicher sind, schicken Sie sie an eine andere Stelle oder verzichten Sie ganz darauf, sie zu senden.

Wenn Sie ein Webforum, eine Newsgroup oder eine Mailingliste auswählen, sollten Sie dem Namen an sich nicht zu viel Vertrauen schenken. Achten Sie auf eine FAQ oder eine Charta, um zu überprüfen, ob Ihre Frage zum Thema passt. Lesen Sie einige der früheren Beiträge, bevor Sie etwas posten, damit Sie ein Gefühl dafür bekommen, wie die Dinge dort ablaufen. Es ist sogar eine sehr gute Idee, in den Archiven der Newsgroups oder Mailinglisten nach Begriffen zu suchen, die mit Ihrem Problem zu tun haben, bevor Sie etwas posten. Vielleicht finden Sie so eine Antwort, und wenn nicht, hilft es Ihnen, eine bessere Frage zu formulieren.

Schießen Sie nicht mit Kanonen auf Spatzen, das ist wie Schreien und irritiert die Leute. Gehen Sie sie behutsam durch.

Wissen Sie, was Ihr Thema ist! Einer der klassischen Fehler ist es, Fragen zur Unix- oder Windows-Programmierschnittstelle in einem Forum zu stellen, das einer Sprache, einer Bibliothek oder einem Tool gewidmet ist, das für beide Systeme geeignet ist. Wenn Sie nicht verstehen, warum das ein Fehler ist, sollten Sie am besten gar keine Fragen stellen, bis Sie es verstanden haben.

Im Allgemeinen ist es wahrscheinlicher, dass Fragen an ein gut ausgewähltes öffentliches Forum nützliche Antworten erhalten als entsprechende Fragen an ein privates Forum. Hierfür gibt es mehrere Gründe. Einer davon ist einfach die Größe des Pools an potenziellen Befragten. Ein anderer ist die Größe des Publikums. Hacker beantworten lieber Fragen, die viele Menschen aufklären, als Fragen, die nur einigen wenigen dienen.

Es ist verständlich, dass erfahrene Hacker und Autoren beliebter Software bereits mehr als ihren gerechten Anteil an fehlgeleiteten Nachrichten erhalten. Wenn Sie zu dieser Flut beitragen, könnten Sie in extremen Fällen sogar der Tropfen sein, der das Fass zum Überlaufen bringt – es ist schon öfter vorgekommen, dass Mitwirkende an beliebten Projekten ihre Unterstützung zurückgezogen haben, weil der Kollateralschaden in Form von nutzlosem E-Mail-Verkehr auf ihren persönlichen Konten unerträglich wurde.

Stack Overflow

Erst suchen, dann fragen auf Stack Exchange

In den letzten Jahren hat sich die Stack Exchange-Community zu einer wichtigen Quelle für die Beantwortung technischer und anderer Fragen entwickelt und ist sogar das bevorzugte Forum für viele Open-Source-Projekte.

Beginnen Sie mit einer Google-Suche, bevor Sie sich bei Stack Exchange umsehen; Google indiziert die Seiten in Echtzeit. Es ist sehr wahrscheinlich, dass bereits jemand eine ähnliche Frage gestellt hat, und die Stack Exchange-Seiten stehen oft ganz oben in den Suchergebnissen. Wenn Sie über Google nichts gefunden haben, suchen Sie erneut auf der Website, die für Ihre Frage am relevantesten ist (siehe unten). Die Suche mit Tags kann helfen, die Ergebnisse einzugrenzen.

Wenn Sie dann immer noch nichts gefunden haben, stellen Sie Ihre Frage auf der Website, auf der sie am meisten zum Thema passt. Verwenden Sie die Formatierungswerkzeuge, insbesondere für Code, und fügen Sie Tags hinzu, die mit dem Inhalt Ihrer Frage zu tun haben (insbesondere den Namen der Programmiersprache, des Betriebssystems oder der Bibliothek, mit der Sie Probleme haben). Wenn ein Kommentator Sie um weitere Informationen bittet, bearbeiten Sie Ihren Hauptbeitrag und fügen Sie diese ein. Wenn eine Antwort hilfreich ist, klicken Sie auf den Pfeil nach oben, um die Bewertung zu erhöhen. Wenn eine Antwort eine Lösung für Ihr Problem bietet, klicken Sie auf das Häkchen unter den Abstimmungspfeilen, um sie als richtig zu akzeptieren.

Stack Exchange ist auf über 100 Seiten angewachsen, aber hier sind die wahrscheinlichsten Kandidaten:

Super User ist für Fragen zur allgemeinen Datenverarbeitung gedacht. Wenn es bei Ihrer Frage nicht um Code oder Programme geht, mit denen Sie nur über eine Netzwerkverbindung kommunizieren, gehört sie wahrscheinlich hierher.

Stack Overflow ist für Fragen zur Programmierung gedacht.

Server Fault ist für Fragen zur Server- und Netzwerkverwaltung gedacht.

Mehrere Projekte haben ihre eigenen speziellen Seiten, darunter Android, Ubuntu, TeX/LaTeX und SharePoint. Auf der Stack Exchange-Website finden Sie eine aktuelle Liste.

Web- und IRC-Foren

Ihre lokale Benutzergruppe oder Ihre Linux-Distribution bietet möglicherweise ein Webforum oder einen IRC-Kanal an, in dem Neulinge Hilfe erhalten können. (In nicht-englischsprachigen Ländern sind Einsteigerforen immer noch eher Mailinglisten.) Dies sind gute erste Anlaufstellen, insbesondere wenn Sie glauben, dass Sie über ein relativ einfaches oder häufiges Problem gestolpert sind. Ein ausgeschriebener IRC-Kanal ist eine offene Einladung, dort Fragen zu stellen und oft in Echtzeit Antworten zu erhalten.

Wenn Sie das Programm, mit dem Sie Probleme haben, von einer Linux-Distribution bezogen haben (wie es heute üblich ist), ist es vielleicht besser, im Forum bzw. in der Liste der Distribution zu fragen, bevor Sie es im Projektforum bzw. in der Liste des Programms versuchen. Die Hacker des Projekts sagen vielleicht nur: „Verwenden Sie unseren Build“.

Bevor Sie einen Beitrag in einem Webforum schreiben, überprüfen Sie, ob es eine Suchfunktion gibt. Wenn dies der Fall ist, versuchen Sie es mit ein paar Schlüsselwörtern, die Ihrem Problem ähneln; das könnte helfen. Wenn Sie zuvor eine allgemeine Websuche durchgeführt haben (was Sie auch tun sollten), durchsuchen Sie das Forum trotzdem; es kann sein, dass Ihre webweite Suchmaschine dieses Forum in letzter Zeit nicht vollständig indiziert hat.

Es gibt eine zunehmende Tendenz bei Projekten, den Benutzersupport über ein Webforum oder einen IRC-Kanal abzuwickeln, während E-Mails eher für den Entwicklungsverkehr reserviert sind. Suchen Sie also zuerst nach diesen Kanälen, wenn Sie projektspezifische Hilfe benötigen.

Im IRC ist es wahrscheinlich am besten, nicht gleich zu Beginn eine lange Problembeschreibung in den Kanal zu werfen; manche Leute interpretieren das als Kanalüberflutung. Am besten ist es, eine einzeilige Problembeschreibung so zu formulieren, dass ein Gespräch im Kanal entsteht.

Als zweiten Schritt sollten Sie die Projekt-Mailinglisten nutzen

Wenn ein Projekt über eine Mailingliste für Entwickler verfügt, schreiben Sie an die Mailingliste, nicht an einzelne Entwickler, auch wenn Sie glauben, dass Sie wissen, wer Ihre Frage am besten beantworten kann. Informieren Sie sich in der Dokumentation des Projekts und auf der Projekt-Homepage über die Adresse der Projekt-Mailingliste und verwenden Sie sie. Es gibt mehrere gute Gründe für diese Politik:

Jede Frage, die gut genug ist, um sie einem Entwickler zu stellen, ist auch für die ganze Gruppe von Wert. Wenn Sie dagegen den Verdacht haben, dass Ihre Frage zu dumm für eine Mailingliste ist, ist das keine Entschuldigung dafür, einzelne Entwickler zu belästigen.

Indem Sie Fragen auf der Liste stellen, verteilen Sie die Last auf die Entwickler. Der einzelne Entwickler (insbesondere wenn er der Projektleiter ist) ist vielleicht zu beschäftigt, um Ihre Fragen zu beantworten.

Die meisten Mailinglisten werden archiviert und die Archive werden von Suchmaschinen indiziert. Wenn Sie Ihre Frage auf der Liste stellen und sie beantwortet wird, könnte ein zukünftiger Fragesteller Ihre Frage und die Antwort im Web finden, anstatt sie erneut zu stellen.

Wenn bestimmte Fragen häufig gestellt werden, können die Entwickler diese Informationen nutzen, um die Dokumentation oder die Software selbst zu verbessern, damit sie weniger verwirrend ist. Wenn diese Fragen jedoch unter vier Augen gestellt werden, hat niemand ein vollständiges Bild davon, welche Fragen am häufigsten gestellt werden.

Wenn ein Projekt sowohl eine „Benutzer“- als auch eine „Entwickler“- (oder „Hacker“-) Mailingliste oder ein Webforum hat und Sie nicht am Code hacken, fragen Sie in der „Benutzer“-Liste/im Forum. Gehen Sie nicht davon aus, dass Sie auf der Entwicklerliste willkommen sind, denn dort wird man Ihre Frage wahrscheinlich als Lärm empfinden, der den Verkehr der Entwickler stört.

Wenn Sie jedoch sicher sind, dass Ihre Frage nicht trivial ist und Sie mehrere Tage lang keine Antwort in der „Benutzer“-Liste/im Forum erhalten, versuchen Sie es in der „Entwickler“-Liste. Sie sollten sich dort ein paar Tage lang aufhalten oder zumindest die archivierten Nachrichten der letzten Tage durchsehen, um sich mit den örtlichen Gepflogenheiten vertraut zu machen, bevor Sie eine Frage stellen (eigentlich ist dies ein guter Rat für jede private oder halbprivate Liste).

Wenn Sie die Adresse der Mailingliste eines Projekts nicht finden können, sondern nur die Adresse des Projektbetreuers sehen, schreiben Sie ihm. Aber auch in diesem Fall sollten Sie nicht davon ausgehen, dass die Mailingliste nicht existiert. Erwähnen Sie in Ihrer E-Mail, dass Sie es versucht haben und die entsprechende Mailingliste nicht finden konnten. Erwähnen Sie auch, dass Sie nichts dagegen haben, dass Ihre Nachricht an andere Personen weitergeleitet wird. (Viele Menschen sind der Meinung, dass private E-Mails privat bleiben sollten, auch wenn sie keine Geheimnisse enthalten. Indem Sie der Weiterleitung Ihrer Nachricht zustimmen, lassen Sie Ihrem Korrespondenten die Wahl, wie er mit Ihrer E-Mail umgehen soll.)

Verwenden Sie aussagekräftige, spezifische Betreffzeilen

Auf Mailinglisten, in Newsgroups oder Webforen ist die Betreffzeile Ihre große Chance, die Aufmerksamkeit qualifizierter Experten in maximal 50 Zeichen zu gewinnen. Verschwenden Sie diese nicht mit Geschwätz wie „Bitte helfen Sie mir“ (ganz zu schweigen von „BITTE HELFEN SIE MIR!!!!“; Nachrichten mit solchen Betreffzeilen werden reflexartig aussortiert). Versuchen Sie nicht, uns mit der Tiefe Ihres Kummers zu beeindrucken; nutzen Sie den Platz stattdessen für eine superpräzise Problembeschreibung.

Eine gute Konvention für Betreffzeilen, die von vielen technischen Supportorganisationen verwendet wird, ist „Objekt – Abweichung“. Der Teil „Objekt“ gibt an, welche Sache oder Gruppe von Sachen ein Problem hat, und der Teil „Abweichung“ beschreibt die Abweichung vom erwarteten Verhalten.

Dumm gelaufen:
HILFE! Das Video funktioniert auf meinem Laptop nicht richtig!

Clever:
X.org 6.8.1 missgestalteter Mauszeiger, Fooware MV1005 Videochipsatz

Cleverer:
X.org 6.8.1 Mauszeiger auf Fooware MV1005 vid. Chipsatz – ist unförmig

Der Prozess des Schreibens einer „Objektabweichung“-Beschreibung wird Ihnen helfen, Ihre Überlegungen zu dem Problem detaillierter zu strukturieren. Was ist betroffen? Nur der Mauszeiger oder auch andere Grafiken? Ist das Problem spezifisch für die X.org-Version von X? Für die Version 6.8.1? Ist das Problem spezifisch für Fooware Video-Chipsätze? Für das Modell MV1005? Ein Hacker, der das Ergebnis sieht, kann sofort auf einen Blick verstehen, womit Sie ein Problem haben und welches Problem Sie haben.

Allgemeiner ausgedrückt: Stellen Sie sich vor, Sie sehen sich den Index eines Fragenarchivs an, in dem nur die Betreffzeilen angezeigt werden. Sorgen Sie dafür, dass Ihre Betreffzeile Ihre Frage gut genug wiedergibt, damit die nächste Person, die das Archiv mit einer ähnlichen Frage durchsucht, dem Thread zu einer Antwort folgen kann, anstatt die Frage erneut zu stellen.

Wenn Sie in einer Antwort eine Frage stellen, sollten Sie die Betreffzeile so ändern, dass erkennbar ist, dass Sie eine Frage stellen. Eine Betreffzeile, die wie „Re: test“ oder „Re: new bug“ aussieht, wird wahrscheinlich nicht so viel Aufmerksamkeit erregen. Beschränken Sie außerdem das Zitieren früherer Nachrichten auf ein Minimum, um neue Leser anzulocken.

Klicken Sie nicht einfach auf Antwort auf eine Listennachricht, um einen völlig neuen Thread zu beginnen. Damit schränken Sie Ihr Publikum ein. Einige E-Mail-Reader, wie z.B. mutt, erlauben es dem Benutzer, nach Themen zu sortieren und dann Nachrichten in einem Thema auszublenden, indem er das Thema zusammenfaltet. Die Leute, die das tun, werden Ihre Nachricht nie sehen.

Das Ändern des Betreffs ist nicht ausreichend. Mutt und wahrscheinlich auch andere E-Mail-Leseprogramme betrachten andere Informationen in den Kopfzeilen der E-Mail, um sie einem Thema zuzuordnen, nicht die Betreffzeile. Beginnen Sie stattdessen eine völlig neue E-Mail.

In Webforen sind die Regeln der guten Praxis etwas anders, da Nachrichten in der Regel viel enger an bestimmte Diskussionsstränge gebunden und außerhalb dieser Stränge oft nicht sichtbar sind. Es ist nicht unbedingt erforderlich, den Betreff zu ändern, wenn Sie eine Frage beantworten. Nicht alle Foren erlauben sogar separate Betreffzeilen für Antworten, und fast niemand liest sie, wenn sie es tun. Eine Frage in einer Antwort zu stellen, ist jedoch an sich schon eine fragwürdige Praxis, da sie nur von denjenigen gesehen wird, die diesen Thread verfolgen. Wenn Sie also nicht sicher sind, dass Sie nur die Personen fragen wollen, die gerade in diesem Thema aktiv sind, sollten Sie ein neues Thema eröffnen.

Machen Sie die Beantwortung einfach

Wenn Sie Ihre Anfrage mit „Bitte senden Sie Ihre Antwort an… „, ist es ziemlich unwahrscheinlich, dass Sie eine Antwort erhalten. Wenn Sie sich nicht einmal die Mühe machen können, sich ein paar Sekunden Zeit zu nehmen, um einen korrekten Reply-To-Header in Ihrem Mail-Agenten einzurichten, können wir uns nicht einmal ein paar Sekunden Zeit nehmen, um über Ihr Problem nachzudenken. Wenn Ihr Mailprogramm dies nicht zulässt, besorgen Sie sich ein besseres Mailprogramm. Wenn Ihr Betriebssystem keine E-Mail-Programme unterstützt, die dies zulassen, besorgen Sie sich ein besseres Betriebssystem.

In Webforen ist es geradezu unhöflich, um eine Antwort per E-Mail zu bitten, es sei denn, Sie sind der Meinung, dass es sich um sensible Informationen handelt (und jemand wird aus irgendeinem unbekannten Grund nur Sie, aber nicht das ganze Forum darüber informieren). Wenn Sie eine E-Mail-Kopie erhalten möchten, wenn jemand im Thema antwortet, fordern Sie das Webforum auf, diese zu senden; diese Funktion wird fast überall unter Optionen wie „diesen Thread beobachten“, „E-Mail bei Antworten senden“ usw. unterstützt.

Schreiben Sie in klarer, grammatikalisch korrekter und orthographisch korrekter Sprache
Wir haben die Erfahrung gemacht, dass Leute, die nachlässig und schlampig schreiben, in der Regel auch nachlässig und schlampig im Denken und in der Programmierung sind (jedenfalls oft genug, um darauf zu wetten). Die Beantwortung von Fragen für nachlässige und schlampige Denker ist nicht lohnend; wir verbringen unsere Zeit lieber anderswo.

Es ist also wichtig, dass Sie Ihre Frage klar und gut formulieren. Wenn Sie sich nicht die Mühe machen können, das zu tun, können wir uns auch nicht die Mühe machen, Ihnen zuzuhören. Geben Sie sich die Mühe, an Ihrer Sprache zu feilen. Sie muss nicht steif oder förmlich sein – die Hackerkultur schätzt sogar eine informelle, umgangssprachliche und humorvolle Sprache, die mit Präzision verwendet wird. Aber sie muss präzise sein; es muss einen Hinweis darauf geben, dass Sie nachdenken und aufmerksam sind.

Buchstabieren Sie richtig, setzen Sie Interpunktionen und schreiben Sie groß. Verwechseln Sie nicht „its“ mit „it’s“, „loose“ mit „lose“ oder „discrete“ mit „discreet“. Schreiben Sie nicht in GROSSBUCHSTABEN; das wird als Schreien aufgefasst und gilt als unhöflich. (Großbuchstaben sind nur wenig weniger ärgerlich, da sie schwer zu lesen sind. Alan Cox kann damit durchkommen, aber Sie nicht.)

Allgemeiner ausgedrückt: Wenn Sie wie ein halbgebildeter Trottel schreiben, werden Sie höchstwahrscheinlich ignoriert. Verwenden Sie also keine Abkürzungen für Instant Messaging. Wenn Sie „Sie“ als „u“ schreiben, sehen Sie aus wie ein halbgebildeter Trottel, der zwei ganze Tastenanschläge spart. Schlimmer noch: Wenn Sie wie ein l33t script kiddie hax0r schreiben, ist das der absolute Todeskuss und garantiert, dass Sie im Gegenzug nichts als versteinertes Schweigen (oder bestenfalls eine gehörige Portion Hohn und Sarkasmus) erhalten.

Wenn Sie Fragen in einem Forum stellen, in dem nicht Ihre Muttersprache gesprochen wird, werden Sie für Rechtschreib- und Grammatikfehler eine begrenzte Nachsicht erhalten – aber keine zusätzliche Nachsicht für Faulheit (und ja, wir können diesen Unterschied normalerweise erkennen). Schreiben Sie außerdem auf Englisch, es sei denn, Sie wissen, welche Sprachen Ihre Befragten sprechen. Fleißige Hacker neigen dazu, Fragen in Sprachen, die sie nicht verstehen, einfach wegzuwerfen, und Englisch ist die Arbeitssprache des Internets. Indem Sie auf Englisch schreiben, minimieren Sie die Wahrscheinlichkeit, dass Ihre Frage ungelesen verworfen wird.

Wenn Sie auf Englisch schreiben, es aber eine zweite Sprache für Sie ist, gehört es zum guten Ton, potenzielle Befragte auf mögliche Sprachschwierigkeiten und Möglichkeiten, diese zu umgehen, hinzuweisen. Beispiele:

Englisch ist nicht meine Muttersprache; bitte entschuldigen Sie Tippfehler.
Wenn Sie $LANGUAGE sprechen, senden Sie mir bitte eine E-Mail/PM; ich brauche möglicherweise Hilfe bei der Übersetzung meiner Frage.
Ich bin mit den Fachbegriffen vertraut, aber einige Slangausdrücke und Redewendungen sind für mich schwierig.
Ich habe meine Frage in $LANGUAGE und Englisch gestellt. Ich übersetze gerne Ihre Antworten, wenn Sie nur die eine oder die andere Sprache verwenden.
Senden Sie Fragen in zugänglichen, standardisierten Formaten
Wenn Sie Ihre Frage künstlich schwer lesbar machen, wird sie mit größerer Wahrscheinlichkeit zugunsten einer anderen übergangen. Also:
Senden Sie einfache Textnachrichten, kein HTML. (Es ist nicht schwer, HTML zu deaktivieren.)

MIME-Anhänge sind in der Regel in Ordnung, aber nur, wenn es sich dabei um echte Inhalte handelt (z. B. eine angehängte Quelldatei oder ein Patch) und nicht nur um von Ihrem E-Mail-Client generierte Textbausteine (wie eine weitere Kopie Ihrer Nachricht).

Versenden Sie keine E-Mails, in denen ganze Absätze aus einzelnen, mehrfach umbrochenen Zeilen bestehen. (Das macht es zu schwierig, nur auf einen Teil der Nachricht zu antworten.) Gehen Sie davon aus, dass Ihre Empfänger die E-Mail auf einem 80-Zeichen breiten Textdisplay lesen und stellen Sie den Zeilenumbruch entsprechend auf weniger als 80 Zeichen ein.

Bringen Sie jedoch keine Daten (wie z.B. Logfile-Dumps oder Sitzungsprotokolle) in einer festen Spaltenbreite unter. Die Daten sollten so enthalten sein, wie sie sind, damit die Befragten sicher sein können, dass sie das sehen, was Sie gesehen haben.

Senden Sie keine MIME-Quoted-Printable-Kodierung an ein englischsprachiges Forum. Diese Kodierung kann notwendig sein, wenn Sie in einer Sprache posten, die ASCII nicht abdeckt, aber viele E-Mail-Agenten unterstützen sie nicht. Wenn diese Kodierung nicht funktioniert, sind all die =20 Glyphen, die über den Text verstreut sind, hässlich und ablenkend – oder sie können die Semantik Ihres Textes aktiv sabotieren.

Erwarten Sie niemals, dass Hacker in der Lage sind, geschlossene proprietäre Dokumentformate wie Microsoft Word oder Excel zu lesen. Die meisten Hacker reagieren darauf in etwa so gut, wie Sie darauf reagieren würden, wenn man Ihnen einen Haufen dampfenden Schweinemist vor die Haustür legt. Selbst wenn sie damit zurechtkommen, ärgern sie sich, dass sie es tun müssen.

Wenn Sie E-Mails von einem Windows-Rechner aus versenden, sollten Sie die problematische Funktion „Intelligente Anführungszeichen“ von Microsoft deaktivieren (Deaktivieren Sie unter Extras > AutoKorrektur-Optionen das Kontrollkästchen Intelligente Anführungszeichen unter AutoFormat As You Type.) Auf diese Weise vermeiden Sie, dass Sie in Ihrer E-Mail unnötige Zeichen einstreuen.

Missbrauchen Sie in Webforen nicht die Funktionen „Smiley“ und „HTML“ (wenn sie vorhanden sind). Ein oder zwei Smileys sind in der Regel in Ordnung, aber farbiger, ausgefallener Text führt dazu, dass die Leute Sie für lahm halten. Wenn Sie es mit Smileys, Farben und Schriftarten übertreiben, wirken Sie wie ein kicherndes Teenager-Mädchen, was im Allgemeinen keine gute Idee ist, es sei denn, Sie sind mehr an Sex als an Antworten interessiert.

Wenn Sie einen E-Mail-Client mit grafischer Benutzeroberfläche wie Netscape Messenger, MS Outlook oder ähnliche Programme verwenden, sollten Sie sich darüber im Klaren sein, dass er mit seinen Standardeinstellungen gegen diese Regeln verstoßen kann. Die meisten dieser Clients verfügen über einen menügesteuerten Befehl „Quelle anzeigen“. Verwenden Sie diesen Befehl für etwas in Ihrem E-Mail-Ordner, um zu überprüfen, ob Sie einen reinen Text ohne unnötige Anhänge versenden.

Seien Sie präzise und informativ über Ihr Problem
Beschreiben Sie die Symptome Ihres Problems oder Fehlers sorgfältig und deutlich.

Beschreiben Sie die Umgebung, in der das Problem auftritt (Rechner, Betriebssystem, Anwendung, was auch immer). Geben Sie die Distribution Ihres Anbieters und den Versionsstand an (z.B.: „Fedora Core 7“, „Slackware 9.1“, usw.).

Beschreiben Sie die Nachforschungen, die Sie angestellt haben, um das Problem zu verstehen, bevor Sie die Frage gestellt haben.

Beschreiben Sie die Diagnoseschritte, die Sie unternommen haben, um das Problem selbst einzugrenzen, bevor Sie die Frage gestellt haben.

Beschreiben Sie alle möglicherweise relevanten Änderungen, die in letzter Zeit an Ihrem Computer oder Ihrer Softwarekonfiguration vorgenommen wurden.

Wenn möglich, geben Sie an, wie Sie das Problem in einer kontrollierten Umgebung reproduzieren können.

Versuchen Sie, die Fragen, die ein Hacker stellen wird, so gut wie möglich vorherzusehen, und beantworten Sie sie in Ihrem Hilfeersuchen im Voraus.

Den Hackern die Möglichkeit zu geben, das Problem in einer kontrollierten Umgebung zu reproduzieren, ist besonders wichtig, wenn Sie etwas melden, von dem Sie glauben, dass es ein Fehler im Code ist. Wenn Sie dies tun, verbessern sich Ihre Chancen auf eine brauchbare Antwort und die Geschwindigkeit, mit der Sie diese Antwort erhalten werden, enorm.

Simon Tatham hat einen hervorragenden Aufsatz mit dem Titel How to Report Bugs Effectively geschrieben. Ich empfehle Ihnen dringend, ihn zu lesen.

Lautstärke ist nicht Präzision
Sie müssen präzise und informativ sein. Diesem Ziel ist nicht damit gedient, dass Sie einfach riesige Mengen an Code oder Daten in eine Hilfeanfrage packen. Wenn Sie einen großen, komplizierten Testfall haben, der ein Programm zum Scheitern bringt, sollten Sie versuchen, ihn zu kürzen und so klein wie möglich zu machen.

Dies ist aus mindestens drei Gründen sinnvoll. Erstens: Wenn man sieht, dass Sie sich die Mühe machen, die Frage zu vereinfachen, ist es wahrscheinlicher, dass Sie eine Antwort erhalten. Zweitens: Wenn Sie die Frage vereinfachen, ist es wahrscheinlicher, dass Sie eine nützliche Antwort erhalten. Drittens: Während Sie Ihren Fehlerbericht verfeinern, entwickeln Sie vielleicht selbst eine Lösung oder einen Workaround.

Behaupten Sie nicht voreilig, dass Sie einen Fehler gefunden haben
Wenn Sie Probleme mit einer Software haben, sollten Sie nicht behaupten, dass Sie einen Fehler gefunden haben, es sei denn, Sie sind sich Ihrer Sache sehr, sehr sicher. Tipp: Wenn Sie keinen Quellcode-Patch vorlegen können, der das Problem behebt, oder keinen Regressionstest gegen eine frühere Version, der ein fehlerhaftes Verhalten zeigt, sind Sie wahrscheinlich nicht sicher genug. Dies gilt auch für Webseiten und die Dokumentation. Wenn Sie einen „Fehler“ in der Dokumentation gefunden haben, sollten Sie einen Ersatztext liefern und angeben, auf welchen Seiten er erscheinen soll.

Denken Sie daran, dass es viele andere Benutzer gibt, die nicht von Ihrem Problem betroffen sind. Sonst hätten Sie beim Lesen der Dokumentation und bei der Suche im Internet davon erfahren (das haben Sie doch getan, bevor Sie sich beschwert haben, oder?). Das bedeutet, dass sehr wahrscheinlich Sie etwas falsch machen, nicht die Software.

Die Leute, die die Software geschrieben haben, arbeiten sehr hart daran, dass sie so gut wie möglich funktioniert. Wenn Sie behaupten, dass Sie einen Fehler gefunden haben, stellen Sie deren Kompetenz in Frage, was einige von ihnen beleidigen könnte, selbst wenn Sie Recht haben. Es ist besonders undiplomatisch, in der Betreffzeile „Fehler“ zu schreien.

Wenn Sie Ihre Frage stellen, schreiben Sie am besten so, als ob Sie davon ausgehen, dass Sie etwas falsch machen, auch wenn Sie privat ziemlich sicher sind, dass Sie einen tatsächlichen Fehler gefunden haben. Wenn es wirklich einen Fehler gibt, werden Sie es in der Antwort erfahren. Spielen Sie es so, dass sich die Betreuer bei Ihnen entschuldigen wollen, wenn der Fehler tatsächlich existiert, und nicht so, dass Sie ihnen eine Entschuldigung schulden, wenn Sie es vermasselt haben.

Grübeln ist kein Ersatz für Ihre Hausaufgaben
Manche Menschen, die verstanden haben, dass sie sich nicht unhöflich oder arrogant verhalten und eine Antwort verlangen sollten, ziehen sich in das entgegengesetzte Extrem des Kriechens zurück. „Ich weiß, ich bin nur ein erbärmlicher Anfänger, aber…“. Das ist ablenkend und wenig hilfreich. Besonders ärgerlich ist es, wenn es mit Unklarheiten über das eigentliche Problem verbunden ist.

Verschwenden Sie weder Ihre noch unsere Zeit mit plumper Primatenpolitik. Stellen Sie stattdessen die Hintergrundfakten und Ihre Frage so klar wie möglich dar. Das ist ein besserer Weg, sich zu positionieren, als zu kriechen.

Manchmal gibt es in Webforen separate Bereiche für Fragen von Neulingen. Wenn Sie das Gefühl haben, dass Sie eine Anfängerfrage haben, gehen Sie einfach dorthin. Aber auch dort sollten Sie nicht kriechen.

Beschreiben Sie die Symptome des Problems, nicht Ihre Vermutungen
Es ist nicht sinnvoll, den Hackern mitzuteilen, was Ihrer Meinung nach die Ursache Ihres Problems ist. (Würden Sie andere um Hilfe bitten, wenn Ihre Diagnose-Theorien so toll wären?) Stellen Sie also sicher, dass Sie ihnen die reinen Symptome des Problems mitteilen und nicht Ihre Interpretationen und Theorien. Überlassen Sie ihnen die Interpretation und Diagnose. Wenn Sie es für wichtig halten, Ihre Vermutung mitzuteilen, kennzeichnen Sie sie klar als solche und beschreiben Sie, warum diese Antwort für Sie nicht funktioniert.

Dumm gelaufen:
Ich erhalte nacheinander SIG11-Fehler beim Kompilieren des Kernels und vermute einen Haarriss auf einer der Leiterbahnen des Motherboards. Wie kann ich das am besten überprüfen?

Clever:
Mein selbstgebauter K6/233 auf einem FIC-PA2007 Motherboard (VIA Apollo VP2 Chipsatz) mit 256MB Corsair PC133 SDRAM fängt etwa 20 Minuten nach dem Einschalten an, während der Kernelkompilierung häufig SIG11-Fehler zu bekommen, aber nie in den ersten 20 Minuten. Ein Neustart führt nicht zu einem Neustart der Uhr, aber ein Ausschalten über Nacht schon. Das Auswechseln des gesamten RAM hat nicht geholfen. Es folgt der relevante Teil des Protokolls einer typischen Kompilierungssitzung.

Da der vorangegangene Punkt für viele Leute schwer zu begreifen ist, hier ein Satz zur Erinnerung: „Alle Diagnostiker sind aus Missouri.“ Das offizielle Motto dieses US-Bundesstaates lautet „Zeig’s mir“ (das 1899 entstand, als der Kongressabgeordnete Willard D. Vandiver sagte: „Ich komme aus einem Land, das Mais und Baumwolle anbaut und Kakadus und Demokraten, und schaumige Beredsamkeit überzeugt und befriedigt mich nicht. Ich bin aus Missouri. Das müssen Sie mir schon zeigen.“) Im Fall der Diagnostiker geht es nicht um Skepsis, sondern um das wortwörtliche, funktionale Bedürfnis, alles zu sehen, was den rohen Beweisen, die Sie sehen, so nahe wie möglich kommt, und nicht um Ihre Vermutungen und Zusammenfassungen. Zeigen Sie es uns.

Beschreiben Sie die Symptome Ihres Problems in chronologischer Reihenfolge
Die nützlichsten Anhaltspunkte, um herauszufinden, was schief gelaufen ist, liegen oft in den Ereignissen unmittelbar davor. Ihr Bericht sollte also genau beschreiben, was Sie getan haben und was der Rechner und die Software getan haben, bevor es zu dem Problem kam. Im Falle von Befehlszeilenprozessen ist es sehr nützlich, ein Sitzungsprotokoll zu haben (z.B. mit dem Skript-Dienstprogramm) und die relevanten zwanzig oder so Zeilen zu zitieren.

Wenn das Programm, das Sie in die Luft gejagt hat, über Diagnoseoptionen verfügt (z.B. -v für verbose), versuchen Sie, Optionen auszuwählen, die dem Protokoll nützliche Debugging-Informationen hinzufügen. Denken Sie daran, dass mehr nicht unbedingt besser ist. Versuchen Sie, einen Debug-Level zu wählen, der informativ ist, anstatt den Leser in Müll zu ertränken.

Wenn Ihr Bericht zu lang wird (mehr als vier Absätze), kann es sinnvoll sein, das Problem kurz und bündig am Anfang zu beschreiben und dann chronologisch zu erzählen. Auf diese Weise wissen die Hacker, worauf sie beim Lesen Ihres Berichts achten müssen.

Beschreiben Sie das Ziel, nicht den Schritt
Wenn Sie versuchen, herauszufinden, wie Sie etwas tun können (im Gegensatz zum Melden eines Fehlers), beschreiben Sie zunächst das Ziel. Erst dann beschreiben Sie den Schritt, der Sie auf dem Weg dorthin blockiert.

Oft haben Menschen, die technische Hilfe benötigen, ein hochgestecktes Ziel vor Augen und bleiben auf einem bestimmten Weg zu diesem Ziel stecken. Sie bitten um Hilfe bei dem Schritt, erkennen aber nicht, dass der Weg falsch ist. Es kann erhebliche Anstrengungen erfordern, dies zu überwinden.

Dumm gelaufen:
Wie bringe ich den Farbwähler im FooDraw-Programm dazu, einen hexadezimalen RGB-Wert zu akzeptieren?

Klug:
Ich versuche, die Farbtabelle eines Bildes durch Werte meiner Wahl zu ersetzen. Im Moment sehe ich nur eine Möglichkeit, dies zu tun, indem ich jeden Tabellenplatz bearbeite, aber ich kann den Farbwähler von FooDraw nicht dazu bringen, einen hexadezimalen RGB-Wert zu übernehmen.

Die zweite Version der Frage ist intelligent. Sie erlaubt eine Antwort, die ein Tool vorschlägt, das für die Aufgabe besser geeignet ist.

Bitten Sie niemanden, per privater E-Mail zu antworten
Hacker sind der Meinung, dass das Lösen von Problemen ein öffentlicher, transparenter Prozess sein sollte, bei dem ein erster Versuch einer Antwort korrigiert werden kann und sollte, wenn jemand, der sich besser auskennt, bemerkt, dass sie unvollständig oder falsch ist. Außerdem erhalten Helfer einen Teil ihrer Belohnung für die Beantwortung von Problemen dadurch, dass sie von ihren Kollegen für kompetent und sachkundig gehalten werden.

Wenn Sie um eine private Antwort bitten, stören Sie sowohl den Prozess als auch die Belohnung. Tun Sie das nicht. Es ist die Entscheidung des Befragten, ob er privat antwortet – und wenn er oder sie es tut, dann meist, weil er oder sie die Frage für zu schlecht formuliert oder zu offensichtlich hält, um für andere interessant zu sein.

Es gibt eine begrenzte Ausnahme von dieser Regel. Wenn Sie der Meinung sind, dass die Frage so formuliert ist, dass Sie wahrscheinlich viele Antworten erhalten werden, die sich alle stark ähneln, dann lauten die magischen Worte „Schicken Sie mir eine E-Mail und ich werde die Antworten für die Gruppe zusammenfassen“. Es ist höflich, der Mailingliste oder Newsgroup eine Flut von im Wesentlichen identischen Postings zu ersparen – aber Sie müssen das Versprechen, die Antworten zusammenzufassen, einhalten.

Seien Sie bei Ihrer Frage explizit
Offene Fragen werden oft als Zeitfresser mit offenem Ende wahrgenommen. Die Leute, die Ihnen am ehesten eine brauchbare Antwort geben können, sind auch am meisten beschäftigt (und sei es nur, weil sie selbst die meiste Arbeit haben). Solche Menschen reagieren allergisch auf offene Fragen, weil sie keine Zeit haben.

Es ist wahrscheinlicher, dass Sie eine nützliche Antwort erhalten, wenn Sie genau angeben, was die Befragten tun sollen (Hinweise geben, Code senden, Ihren Patch prüfen, was auch immer). So können Sie sich auf die Aufgabe konzentrieren und implizit eine Obergrenze für die Zeit und Energie festlegen, die der Befragte aufwenden muss, um Ihnen zu helfen. Das ist gut.

Um die Welt der Experten zu verstehen, stellen Sie sich vor, dass Fachwissen eine reichlich vorhandene Ressource ist und die Zeit für eine Antwort eine knappe Ressource. Je weniger Zeit Sie implizit verlangen, desto wahrscheinlicher ist es, dass Sie eine Antwort von jemandem erhalten, der wirklich gut ist und wirklich viel zu tun hat.

Es ist also sinnvoll, Ihre Frage so zu formulieren, dass der Zeitaufwand, den ein Experte für die Beantwortung benötigt, möglichst gering ist. So ist zum Beispiel „Könnten Sie mir einen Hinweis auf eine gute Erklärung von X geben?“ in der Regel eine klügere Frage als „Würden Sie bitte X erklären?“. Wenn Sie einen schlecht funktionierenden Code haben, ist es in der Regel klüger, jemanden zu bitten, zu erklären, was damit nicht in Ordnung ist, als jemanden zu bitten, ihn zu reparieren.

Wenn Sie nach dem Code fragen
Bitten Sie andere nicht darum, Ihren fehlerhaften Code zu debuggen, ohne einen Hinweis darauf zu geben, nach welcher Art von Problem sie suchen sollen. Wenn Sie ein paar hundert Zeilen Code posten und sagen „es funktioniert nicht“, werden Sie ignoriert. Wenn Sie ein Dutzend Codezeilen posten und sagen: „Nach Zeile 7 habe ich erwartet, zu sehen, aber stattdessen ist aufgetreten“, ist die Wahrscheinlichkeit viel größer, dass Sie eine Antwort erhalten.

Der effektivste Weg, ein Codeproblem genau zu beschreiben, ist ein minimaler Testfall, der den Fehler demonstriert. Was ist ein minimaler Testfall? Es ist eine Illustration des Problems; gerade genug Code, um das unerwünschte Verhalten zu zeigen und nicht mehr. Wie erstellen Sie einen minimalen Testfall? Wenn Sie wissen, welche Zeile oder welcher Abschnitt des Codes das problematische Verhalten hervorruft, erstellen Sie eine Kopie davon und fügen Sie gerade so viel unterstützenden Code hinzu, dass ein vollständiges Beispiel entsteht (d.h. so viel, dass der Quellcode für den Compiler/Interpreter/die Anwendung, die ihn verarbeitet, akzeptabel ist). Wenn Sie das Problem nicht auf einen bestimmten Abschnitt eingrenzen können, erstellen Sie eine Kopie des Quellcodes und entfernen Sie die Teile, die das problematische Verhalten nicht beeinflussen. Je kleiner Ihr minimaler Testfall ist, desto besser (siehe den Abschnitt „Umfang ist keine Präzision“).

Es wird nicht immer möglich sein, einen wirklich kleinen minimalen Testfall zu erstellen, aber es zu versuchen, ist eine gute Disziplin. Es kann Ihnen helfen, zu lernen, was Sie brauchen, um das Problem selbst zu lösen – und selbst wenn es nicht gelingt, sehen Hacker gerne, dass Sie es versucht haben. Das wird sie kooperativer machen.

Wenn Sie lediglich eine Überprüfung des Codes wünschen, sagen Sie dies im Voraus und erwähnen Sie, welche Bereiche Ihrer Meinung nach besonders überprüft werden sollten und warum.

Stellen Sie keine Fragen zu Hausaufgaben
Hacker sind gut im Erkennen von Hausaufgabenfragen; die meisten von uns haben sie selbst gemacht. Diese Fragen sollten Sie lösen, damit Sie aus der Erfahrung lernen können. Es ist in Ordnung, nach Hinweisen zu fragen, aber nicht nach vollständigen Lösungen.

Wenn Sie den Verdacht haben, dass Ihnen eine Hausaufgabe gestellt wurde, Sie sie aber trotzdem nicht lösen können, versuchen Sie, in einem Benutzergruppenforum oder (als letzten Ausweg) in einer „Benutzer“-Liste/einem Forum eines Projekts zu fragen. Die Hacker werden es zwar erkennen, aber einige der fortgeschrittenen Benutzer können Ihnen zumindest einen Hinweis geben.

Streichen Sie sinnlose Abfragen
Widerstehen Sie der Versuchung, Ihr Hilfegesuch mit sinnlosen Fragen wie „Kann mir jemand helfen?“ oder „Gibt es eine Antwort?“ abzuschließen. Erstens: Wenn Sie Ihre Problembeschreibung halbwegs kompetent verfasst haben, sind solche angehängten Fragen bestenfalls überflüssig. Zweitens: Weil sie überflüssig sind, empfinden Hacker sie als lästig – und werden wahrscheinlich logisch einwandfreie, aber abweisende Antworten wie „Ja, Ihnen kann geholfen werden“ und „Nein, es gibt keine Hilfe für Sie“ geben.

Generell sollten Sie es vermeiden, Ja-oder-Nein-Fragen zu stellen, es sei denn, Sie wollen eine Ja-oder-Nein-Antwort.

Kennzeichnen Sie Ihre Frage nicht als „Dringend“, auch wenn sie für Sie ist.
Das ist Ihr Problem, nicht unseres. Die Angabe von Dringlichkeit ist höchstwahrscheinlich kontraproduktiv: Die meisten Hacker werden solche Nachrichten einfach als unhöfliche und egoistische Versuche löschen, sofortige und besondere Aufmerksamkeit zu erregen. Darüber hinaus löst das Wort „Dringend“ (und andere ähnliche Versuche, in der Betreffzeile Aufmerksamkeit zu erregen) häufig Spam-Filter aus – Ihre beabsichtigten Empfänger werden die Nachricht möglicherweise gar nicht sehen!

Es gibt eine halbe Ausnahme. Es kann erwähnenswert sein, wenn Sie das Programm an einem hochrangigen Ort einsetzen, an dem sich die Hacker aufregen. Wenn Sie in einem solchen Fall unter Zeitdruck stehen und dies höflich sagen, sind die Leute vielleicht interessiert genug, um schneller zu antworten.

Das ist jedoch sehr riskant, denn die Hacker haben wahrscheinlich andere Maßstäbe für das, was aufregend ist, als Sie. Ein Posting von der Internationalen Raumstation wäre zum Beispiel eine gute Idee, aber ein Posting im Namen einer wohltätigen oder politischen Sache wäre es mit Sicherheit nicht. Wenn Sie „Dringend: Helfen Sie mir, die flauschigen Babyrobben zu retten!“ posten, werden Sie sogar von Hackern, die flauschige Babyrobben für wichtig halten, gemieden oder geflammt.

Wenn Ihnen das rätselhaft vorkommt, lesen Sie den Rest dieser Anleitung noch einmal, bis Sie sie verstanden haben, bevor Sie überhaupt etwas posten.

Höflichkeit schadet nie, und manchmal hilft sie sogar
Seien Sie höflich. Verwenden Sie „Bitte“ und „Danke für Ihre Aufmerksamkeit“ oder „Danke für Ihre Aufmerksamkeit“. Machen Sie deutlich, dass Sie die Zeit zu schätzen wissen, die man sich nimmt, um Ihnen kostenlos zu helfen.

Um ehrlich zu sein, ist dies nicht so wichtig wie (und kann es auch nicht ersetzen) grammatikalisch klar, präzise und beschreibend zu sein, proprietäre Formate zu vermeiden usw.; Hacker erhalten im Allgemeinen lieber etwas schroffe, aber technisch scharfe Fehlerberichte als höfliche Unklarheiten. (Wenn Sie das verwirrt, denken Sie daran, dass wir eine Frage danach bewerten, was sie uns lehrt.)

Wenn Sie sich jedoch technisch gut auskennen, erhöht Höflichkeit Ihre Chancen auf eine nützliche Antwort.

(Wir müssen anmerken, dass der einzige ernsthafte Einwand, den wir von erfahrenen Hackern zu diesem HOWTO erhalten haben, sich auf unsere frühere Empfehlung bezieht, „Danke im Voraus“ zu verwenden. Einige Hacker sind der Meinung, dass dies die Absicht andeutet, sich hinterher bei niemandem zu bedanken. Wir empfehlen, entweder zuerst „Danke im Voraus“ zu sagen und sich erst danach zu bedanken, oder die Höflichkeit auf andere Weise auszudrücken, z.B. mit „Danke für Ihre Aufmerksamkeit“ oder „Danke für Ihre Aufmerksamkeit“).

Folgen Sie mit einer kurzen Notiz über die Lösung
Schicken Sie nach der Lösung des Problems eine Notiz an alle, die Ihnen geholfen haben. Teilen Sie ihnen mit, wie das Problem gelöst wurde und bedanken Sie sich nochmals für ihre Hilfe. Wenn das Problem in einer Mailingliste oder Newsgroup auf allgemeines Interesse gestoßen ist, ist es angebracht, die Nachbereitung dort zu posten.

Im Idealfall sollte die Antwort an den Thread gehen, der von dem ursprünglichen Fragesteller eröffnet wurde, und in der Betreffzeile ‚FIXED‘, ‚RESOLVED‘ oder einen ähnlich offensichtlichen Hinweis enthalten. Auf Mailinglisten mit schnellen Antwortzeiten weiß ein potenzieller Teilnehmer, der einen Thread über „Problem X“ sieht, der mit „Problem X – BEHOBEN“ endet, dass er seine Zeit nicht mit dem Lesen des Threads verschwenden sollte (es sei denn, er findet Problem X persönlich interessant) und kann diese Zeit daher für die Lösung eines anderen Problems nutzen.

Ihr Follow-up muss nicht lang und kompliziert sein; ein einfaches „Hallo – es war ein defektes Netzwerkkabel! Vielen Dank, Leute. – Bill“ wäre besser als nichts. In der Tat ist eine kurze und knappe Zusammenfassung besser als eine lange Abhandlung, es sei denn, die Lösung hat echte technische Tiefe. Sagen Sie, welche Maßnahme das Problem gelöst hat, aber Sie müssen nicht die gesamte Fehlersuchsequenz wiederholen.

Bei Problemen mit einer gewissen Tiefe ist es angemessen, eine Zusammenfassung des Verlaufs der Fehlerbehebung zu veröffentlichen. Beschreiben Sie Ihre endgültige Problemstellung. Beschreiben Sie, was als Lösung funktioniert hat, und geben Sie danach vermeidbare Sackgassen an. Die Sackgassen sollten nach der korrekten Lösung und anderen Zusammenfassungen folgen, damit die Nachbereitung nicht zu einer Detektivgeschichte wird. Nennen Sie die Namen der Personen, die Ihnen geholfen haben; auf diese Weise werden Sie sich Freunde machen.

Diese Art der Nachbereitung ist nicht nur höflich und informativ, sondern hilft auch anderen, die das Archiv der Mailingliste/Newsgroup/des Forums durchsuchen, genau zu wissen, welche Lösung Ihnen geholfen hat, und kann somit auch ihnen helfen.

Und nicht zuletzt hilft diese Art der Nachbereitung allen, die Ihnen geholfen haben, ein befriedigendes Gefühl der Lösung des Problems zu bekommen. Wenn Sie selbst kein Techniker oder Hacker sind, können Sie uns glauben, dass dieses Gefühl für die Gurus und Experten, die Sie um Hilfe gebeten haben, sehr wichtig ist. Probleme, die in ein ungelöstes Nichts abgleiten, sind frustrierend; Hacker brennen darauf, sie gelöst zu sehen. Das Wohlwollen, das Ihnen das Kratzen an diesem Juckreiz einbringt, wird Ihnen sehr, sehr hilfreich sein, wenn Sie das nächste Mal eine Frage stellen müssen.

Überlegen Sie, wie Sie verhindern können, dass andere in Zukunft das gleiche Problem haben. Fragen Sie sich, ob ein Patch für die Dokumentation oder die FAQ helfen würde, und wenn die Antwort ja lautet, schicken Sie diesen Patch an den Maintainer.

Unter Hackern ist diese Art der guten Nachbereitung sogar wichtiger als die übliche Höflichkeit. So verschaffen Sie sich den Ruf, gut mit anderen zusammenzuarbeiten, was ein sehr wertvolles Gut sein kann.

Wie Sie Antworten interpretieren
RTFM und STFW: Woran Sie erkennen, dass Sie es ernsthaft vermasselt haben
Es gibt eine uralte und geheiligte Tradition: Wenn Sie eine Antwort erhalten, auf der „RTFM“ steht, denkt der Absender, dass Sie das verdammte Handbuch hätten lesen sollen. Er oder sie hat mit ziemlicher Sicherheit Recht. Lesen Sie es.

RTFM hat einen jüngeren Verwandten. Wenn Sie eine Antwort erhalten, die „STFW“ lautet, ist der Absender der Meinung, dass Sie das verdammte Internet hätten durchsuchen sollen. Er oder sie hat mit ziemlicher Sicherheit recht. Durchsuchen Sie es. (Die mildere Version davon ist, wenn Ihnen gesagt wird: „Google ist Ihr Freund!“)

In Webforen kann man Ihnen auch sagen, Sie sollen die Forenarchive durchsuchen. Es kann sogar sein, dass jemand so freundlich ist, Ihnen einen Hinweis auf den früheren Thread zu geben, in dem dieses Problem gelöst wurde. Verlassen Sie sich jedoch nicht darauf, sondern suchen Sie zuerst in den Archiven, bevor Sie fragen.

Oft hat die Person, die Ihnen sagt, dass Sie eine Suche durchführen sollen, das Handbuch oder die Webseite mit den von Ihnen benötigten Informationen geöffnet und sieht sie sich an, während sie tippt. Diese Antworten bedeuten, dass der Antwortende der Meinung ist, (a) dass die von Ihnen benötigten Informationen leicht zu finden sind und (b) dass Sie mehr lernen, wenn Sie die Informationen suchen, als wenn Sie sie mit dem Löffel serviert bekommen.

Sie sollten sich davon nicht beleidigt fühlen. Nach Hacker-Maßstäben erweist Ihnen Ihr Antwortender eine grobe Art von Respekt, indem er Sie einfach nicht ignoriert. Sie sollten stattdessen dankbar für diese großmütterliche Freundlichkeit sein.

Wenn Sie die Frage nicht verstehen…
Wenn Sie die Antwort nicht verstehen, sollten Sie nicht sofort mit einer Aufforderung zur Klärung zurückkommen. Nutzen Sie die gleichen Hilfsmittel, die Sie zur Beantwortung Ihrer ursprünglichen Frage verwendet haben (Handbücher, FAQs, das Internet, erfahrene Freunde), um die Antwort zu verstehen. Wenn Sie dann immer noch um eine Klarstellung bitten müssen, zeigen Sie, was Sie gelernt haben.

Ein Beispiel: Nehmen wir an, ich sage Ihnen: „Es hört sich so an, als ob Sie einen verklemmten Zentry haben, den Sie entfernen müssen“. Dann: Hier ist eine schlechte Folgefrage: „Was ist ein Zentry?“ Hier ist eine gute Folgefrage: „OK, ich habe die Manpage gelesen und zentries werden nur unter den Schaltern -z und -p erwähnt. Keiner von beiden sagt etwas über das Löschen von Zentries aus. Liegt es an einem dieser Schalter oder habe ich etwas übersehen?“

Umgang mit Unhöflichkeit
Vieles, was in Hackerkreisen wie Unhöflichkeit aussieht, ist nicht als Beleidigung gedacht. Vielmehr ist es das Ergebnis des direkten, schnörkellosen Kommunikationsstils, der Menschen eigen ist, die mehr daran interessiert sind, Probleme zu lösen, als anderen ein gutes Gefühl zu geben.

Wenn Sie Unhöflichkeit wahrnehmen, versuchen Sie, ruhig zu reagieren. Wenn sich jemand wirklich daneben benimmt, ist es sehr wahrscheinlich, dass eine ältere Person auf der Liste oder in der Newsgroup oder im Forum ihn oder sie darauf anspricht. Wenn das nicht geschieht und Sie die Beherrschung verlieren, ist es wahrscheinlich, dass die Person, die Sie verärgert haben, sich innerhalb der Normen der Hacker-Community verhalten hat, und Sie werden als Schuldiger angesehen. Dies wird Ihre Chancen, die gewünschten Informationen oder Hilfe zu erhalten, beeinträchtigen.

Auf der anderen Seite werden Sie gelegentlich auf Unhöflichkeiten und Angeberei stoßen, die völlig grundlos sind. Die Kehrseite der Medaille ist, dass es durchaus akzeptabel ist, echte Übeltäter hart anzufassen und ihr Fehlverhalten mit einem scharfen verbalen Skalpell zu zerlegen. Seien Sie sich Ihrer Sache jedoch sehr, sehr sicher, bevor Sie dies versuchen. Die Grenze zwischen der Korrektur einer Unhöflichkeit und dem Anzetteln eines sinnlosen Flamewars ist so schmal, dass Hacker selbst nicht selten darüber stolpern; wenn Sie ein Neuling oder ein Außenstehender sind, sind Ihre Chancen, einen solchen Fehler zu vermeiden, gering. Wenn Sie eher an Informationen als an Unterhaltung interessiert sind, sollten Sie lieber die Finger von der Tastatur lassen, als dies zu riskieren.

(Manche Leute behaupten, dass viele Hacker an einer leichten Form von Autismus oder dem Asperger-Syndrom leiden und dass ihnen ein Teil der Gehirnschaltungen fehlt, die die „normale“ menschliche soziale Interaktion ermöglichen. Das mag wahr sein oder auch nicht. Wenn Sie selbst kein Hacker sind, hilft es Ihnen vielleicht, mit unseren Exzentrizitäten zurechtzukommen, wenn Sie uns als hirngeschädigt betrachten. Machen Sie nur weiter. Es wird uns nichts ausmachen; wir sind gerne so, wie wir sind, und haben im Allgemeinen eine gesunde Skepsis gegenüber klinischen Bezeichnungen).

Jeff Biglers Beobachtungen über Taktfilter sind ebenfalls relevant und lesenswert.

Im nächsten Abschnitt werden wir über ein anderes Thema sprechen: die Art von „Unhöflichkeit“, die Sie erleben, wenn Sie sich daneben benehmen.

Wie man nicht wie ein Verlierer reagiert
Die Chancen stehen gut, dass Sie in den Foren der Hacker-Community ein paar Mal Mist bauen werden – auf die Art und Weise, die in diesem oder einem ähnlichen Artikel beschrieben wird. Und man wird Ihnen genau sagen, wie Sie es vermasselt haben, möglicherweise mit bunten Sprüchen. In der Öffentlichkeit.

Wenn das passiert, ist das Schlimmste, was Sie tun können, über das Erlebnis zu jammern, zu behaupten, Sie seien verbal angegriffen worden, Entschuldigungen zu verlangen, zu schreien, die Luft anzuhalten, mit Klagen zu drohen, sich bei den Arbeitgebern der Leute zu beschweren, den Toilettensitz oben zu lassen usw. Stattdessen sollten Sie Folgendes tun:

Kommen Sie darüber hinweg. Das ist normal. In der Tat ist es gesund und angemessen.

Die Normen der Gemeinschaft erhalten sich nicht von selbst: Sie werden von Menschen aufrechterhalten, die sie aktiv und sichtbar in der Öffentlichkeit anwenden. Jammern Sie nicht, dass alle Kritik per privater E-Mail hätte übermittelt werden müssen: So funktioniert das nicht. Es ist auch nicht sinnvoll, darauf zu bestehen, dass Sie persönlich beleidigt wurden, wenn jemand sagt, dass eine Ihrer Behauptungen falsch war oder dass er anderer Meinung ist. Das sind Verlierer-Attitüden.

Es gibt Hackerforen, in denen den Teilnehmern aus falsch verstandener übertriebener Höflichkeit untersagt wird, die Beiträge anderer zu kritisieren, und ihnen gesagt wird: „Sagen Sie nichts, wenn Sie dem Benutzer nicht helfen wollen.“ Die daraus resultierende Abwanderung ahnungsloser Teilnehmer führt dazu, dass diese Foren zu sinnlosem Geschwafel verkommen und als technische Foren unbrauchbar werden.

Übertrieben „freundlich“ (auf diese Art und Weise) oder nützlich: Suchen Sie sich eins aus.

Denken Sie daran: Wenn der Hacker Ihnen sagt, dass Sie es vermasselt haben, und Ihnen (egal wie unwirsch) sagt, dass Sie es nicht noch einmal tun sollen, handelt er aus Sorge um (1) Sie und (2) seine Gemeinschaft. Es wäre viel einfacher für ihn, Sie zu ignorieren und Sie aus seinem Leben zu verbannen. Wenn Sie es nicht schaffen, dankbar zu sein, dann zeigen Sie wenigstens ein wenig Würde, jammern Sie nicht und erwarten Sie nicht, wie eine zerbrechliche Puppe behandelt zu werden, nur weil Sie ein Neuling mit einer theatralisch überempfindlichen Seele und Anspruchsdenken sind.

Manchmal greifen die Leute Sie persönlich an, flamen ohne ersichtlichen Grund usw., selbst wenn Sie keinen Mist gebaut haben (oder nur in ihrer Vorstellung). In diesem Fall ist das Beschweren der Weg, um wirklich Mist zu bauen.

Diese Flamer sind entweder Lahmärsche, die keine Ahnung haben, sich aber für Experten halten, oder Möchtegern-Psychologen, die testen, ob Sie es vermasseln werden. Die anderen Leser ignorieren sie entweder oder finden selbst einen Weg, mit ihnen umzugehen. Das Verhalten der Flamer schafft für sie selbst Probleme, die Sie nicht betreffen müssen.

Lassen Sie sich auch nicht in einen Flamewar hineinziehen. Die meisten Flames ignorieren Sie am besten – nachdem Sie überprüft haben, ob es sich wirklich um Flames handelt und nicht um Hinweise darauf, wie Sie es vermasselt haben, und nicht um geschickt verschlüsselte Antworten auf Ihre eigentliche Frage (auch das kommt vor).

Fragen, die Sie nicht stellen sollten
Hier sind einige klassische dumme Fragen und was Hacker denken, wenn sie sie nicht beantworten.

F: Wo kann ich Programm oder Ressource X finden?
F: Wie kann ich X verwenden, um Y zu tun?
F: Wie kann ich meine Shell-Eingabeaufforderung konfigurieren?
F: Kann ich ein AcmeCorp-Dokument mit dem Bass-o-matic-Dateikonverter in eine TeX-Datei konvertieren?
Q: Mein {Programm, Konfiguration, SQL-Anweisung} funktioniert nicht
Q: Ich habe Probleme mit meinem Windows-Rechner. Können Sie mir helfen?
Q: Mein Programm funktioniert nicht. Ich glaube, Systemeinrichtung X ist defekt.
Q: Ich habe Probleme bei der Installation von Linux oder X. Können Sie mir helfen?
F: Wie kann ich Root knacken/ Channel-Ops-Privilegien stehlen/ die E-Mails von jemandem lesen?
Q:

Wo kann ich das Programm oder die Ressource X finden?

Dort, wo ich es auch finden würde, Dummkopf – am anderen Ende einer Websuche. Mein Gott, weiß denn noch nicht jeder, wie man Google benutzt?

Wie kann ich X verwenden, um Y zu tun?

Wenn Sie Y machen wollen, sollten Sie diese Frage stellen, ohne die Verwendung einer Methode vorauszusetzen, die möglicherweise nicht geeignet ist. Fragen dieser Art deuten oft auf eine Person hin, die nicht nur unwissend über X ist, sondern auch verwirrt über das Problem Y, das sie lösen will, und zu sehr auf die Details ihrer speziellen Situation fixiert. Im Allgemeinen ist es am besten, solche Leute zu ignorieren, bis sie ihr Problem besser definieren.

Wie kann ich meine Shell-Eingabeaufforderung konfigurieren?

Wenn Sie klug genug sind, diese Frage zu stellen, dann sind Sie auch klug genug, um RTFM zu betreiben und es selbst herauszufinden.

Kann ich ein AcmeCorp-Dokument mit dem Bass-o-matic-Dateikonverter in eine TeX-Datei konvertieren?

Probieren Sie es aus. Wenn Sie das tun, werden Sie (a) die Antwort erfahren und (b) aufhören, meine Zeit zu verschwenden.

Mein {Programm, meine Konfiguration, meine SQL-Anweisung} funktioniert nicht

Dies ist keine Frage, und ich habe kein Interesse daran, Zwanzig Fragen zu spielen, um Ihnen Ihre eigentliche Frage zu entlocken – ich habe Besseres zu tun. Wenn ich so etwas sehe, ist meine Reaktion normalerweise eine der folgenden:

Haben Sie dem noch etwas hinzuzufügen?

Oh, das ist aber schade, ich hoffe, Sie bekommen das Problem in den Griff.

und was genau hat das mit mir zu tun?

Ich habe Probleme mit meinem Windows-Rechner. Können Sie mir helfen?

Ja. Schmeißen Sie den Microsoft-Müll weg und installieren Sie ein Open-Source-Betriebssystem wie Linux oder BSD.

Hinweis: Sie können Fragen zu Windows-Rechnern stellen, wenn es sich um ein Programm handelt, für das es eine offizielle Windows-Version gibt oder das mit Windows-Rechnern interagiert (z.B. Samba). Seien Sie nur nicht überrascht, wenn Sie die Antwort erhalten, dass das Problem mit Windows und nicht mit dem Programm zusammenhängt, denn Windows ist im Allgemeinen so kaputt, dass dies sehr oft der Fall ist.

Mein Programm funktioniert nicht. Ich glaube, Systemeinrichtung X ist defekt.

Es ist zwar möglich, dass Sie die erste Person sind, die einen offensichtlichen Mangel in Systemaufrufen und Bibliotheken bemerkt, die von Hunderten oder Tausenden von Menschen genutzt werden, aber es ist wahrscheinlicher, dass Sie völlig ahnungslos sind. Außergewöhnliche Behauptungen erfordern außergewöhnliche Beweise. Wenn Sie eine Behauptung wie diese aufstellen, müssen Sie sie mit einer klaren und ausführlichen Dokumentation des Fehlers belegen.

Ich habe Probleme bei der Installation von Linux oder X. Können Sie mir helfen?

Nein. Ich müsste selbst Zugang zu Ihrem Rechner haben, um dieses Problem zu lösen. Fragen Sie Ihre lokale Linux-Benutzergruppe nach praktischer Hilfe. (Eine Liste der Benutzergruppen finden Sie hier.)

Hinweis: Fragen zur Installation von Linux können angebracht sein, wenn Sie sich in einem Forum oder einer Mailingliste zu einer bestimmten Distribution befinden und das Problem mit dieser Distribution zu tun hat; oder in den Foren lokaler Benutzergruppen. In diesem Fall sollten Sie die genauen Einzelheiten des Fehlers beschreiben. Suchen Sie aber zunächst sorgfältig nach „linux“ und allen verdächtigen Hardwarekomponenten.

Wie kann ich Root knacken/ Channel-Ops-Privilegien stehlen/ die E-Mails von jemandem lesen?

Sie sind ein Abschaum, wenn Sie so etwas tun wollen, und ein Schwachkopf, wenn Sie einen Hacker um Hilfe bitten.

Gute und schlechte Fragen
Abschließend möchte ich Ihnen anhand eines Beispiels zeigen, wie Sie Fragen auf intelligente Weise stellen können. Es handelt sich um zwei Fragen zum selben Problem, von denen eine dumm und die andere intelligent gestellt wurde.

Dumm: Wo kann ich etwas über den Foonly Flurbamatic herausfinden?
Diese Frage schreit geradezu nach „STFW“ als Antwort.

Clever: Ich habe mit Google versucht, „Foonly Flurbamatic 2600“ im Internet zu finden, aber ich habe keine nützlichen Treffer erhalten. Können Sie mir einen Hinweis auf Programmierinformationen zu diesem Gerät geben?
Dieser hat bereits STFWed, und es klingt, als ob es ein echtes Problem geben könnte.

Dumm gelaufen: Ich kann den Code von Projekt foo nicht kompilieren. Warum ist er kaputt?
Der Fragesteller nimmt an, dass jemand anderes es vermasselt hat. Arrogantes Git…

Clever: Der Code aus Projekt foo lässt sich unter Nulix Version 6.2 nicht kompilieren. Ich habe die FAQ gelesen, aber dort steht nichts über Nulix-bezogene Probleme. Hier ist eine Abschrift meines Kompilierungsversuchs; ist es etwas, das ich gemacht habe?
Der Fragesteller hat die Umgebung angegeben, die FAQ gelesen, zeigt den Fehler an und geht nicht davon aus, dass jemand anders für seine Probleme verantwortlich ist. Dieser Fall ist vielleicht etwas Aufmerksamkeit wert.

Dumm gelaufen: Ich habe Probleme mit meinem Motherboard. Kann mir jemand helfen?
J. Die Antwort des Zufalls-Hackers lautet wahrscheinlich „Richtig. Müssen Sie auch rülpsen und wickeln?“, gefolgt von einem Schlag auf die Löschtaste.

Clever: Ich habe X, Y und Z auf dem S2464-Motherboard ausprobiert. Als das nicht funktionierte, habe ich es mit A, B und C versucht. Beachten Sie das merkwürdige Symptom bei C. Offensichtlich ist der Florbish grommicking, aber die Ergebnisse sind nicht das, was man erwarten könnte. Was sind die üblichen Ursachen für Grommicking auf Athlon MP-Motherboards? Hat jemand Ideen für weitere Tests, die ich durchführen kann, um das Problem einzugrenzen?
Diese Person hingegen scheint einer Antwort würdig zu sein. Er/sie hat Problemlösungsintelligenz bewiesen, anstatt passiv darauf zu warten, dass eine Antwort von oben herab fällt.

Beachten Sie bei der letzten Frage den feinen, aber wichtigen Unterschied zwischen der Forderung „Geben Sie mir eine Antwort“ und „Bitte helfen Sie mir herauszufinden, welche zusätzlichen Diagnosen ich durchführen kann, um Erleuchtung zu erlangen.“

Tatsächlich basiert die Form dieser letzten Frage auf einem realen Vorfall, der sich im August 2001 auf der linux-kernel Mailingliste (lkml) ereignete. Damals war ich (Eric) derjenige, der die Frage stellte. Auf einem Tyan S2462 Motherboard traten mysteriöse Lockups auf. Die Mitglieder der Liste lieferten die entscheidenden Informationen, die ich brauchte, um sie zu lösen.

Indem ich die Frage so stellte, wie ich es tat, gab ich den Leuten etwas zum Nachdenken; ich machte es ihnen leicht und attraktiv, sich zu beteiligen. Ich zeigte Respekt für die Fähigkeiten meiner Kollegen und lud sie ein, sich mit mir als Kollegen zu beraten. Ich zeigte auch Respekt vor dem Wert ihrer Zeit, indem ich ihnen die Sackgassen nannte, die ich bereits durchlaufen hatte.

Als ich mich anschließend bei allen bedankte und bemerkte, wie gut das Verfahren funktioniert hatte, bemerkte ein Mitglied von lkml, dass es seiner Meinung nach nicht deshalb funktioniert hatte, weil ich ein „Name“ auf dieser Liste bin, sondern weil ich die Frage in der richtigen Form gestellt hatte.

Hacker sind in gewisser Weise eine sehr rücksichtslose Leistungsgesellschaft; ich bin sicher, dass er Recht hatte und dass ich, wenn ich mich wie ein Schwamm verhalten hätte, geflamed oder ignoriert worden wäre, egal wer ich war. Sein Vorschlag, ich solle den ganzen Vorfall als Anleitung für andere aufschreiben, führte direkt zur Erstellung dieses Leitfadens.

Wenn Sie keine Antwort bekommen können
Wenn Sie keine Antwort erhalten, nehmen Sie es bitte nicht persönlich, dass wir das Gefühl haben, Ihnen nicht helfen zu können. Manchmal wissen die Mitglieder der befragten Gruppe die Antwort einfach nicht. Keine Antwort ist nicht dasselbe wie ignoriert werden, auch wenn es zugegebenermaßen von außen schwer ist, den Unterschied zu erkennen.

Im Allgemeinen ist es keine gute Idee, Ihre Frage einfach erneut zu stellen. Dies wird als unnötig lästig empfunden. Haben Sie Geduld: die Person mit Ihrer Antwort befindet sich vielleicht in einer anderen Zeitzone und schläft. Oder es kann sein, dass Ihre Frage von Anfang an nicht gut formuliert war.

Sie können sich auch an andere Hilfsquellen wenden, die oft besser auf die Bedürfnisse von Anfängern zugeschnitten sind.

Es gibt viele Online- und lokale Benutzergruppen, die sich für die Software begeistern, auch wenn sie vielleicht nie selbst eine Software geschrieben haben. Diese Gruppen werden oft gegründet, damit sich die Leute gegenseitig helfen und neue Benutzer unterstützen können.

Es gibt auch viele kommerzielle Unternehmen, die Sie um Hilfe bitten können, sowohl große als auch kleine. Seien Sie nicht bestürzt über die Vorstellung, für ein wenig Hilfe zu bezahlen! Wenn Ihr Automotor eine kaputte Dichtung hat, würden Sie ihn ja auch in eine Werkstatt bringen und für die Reparatur bezahlen. Selbst wenn die Software Sie nichts kosten würde, können Sie nicht erwarten, dass der Support immer kostenlos ist.

Für beliebte Software wie Linux gibt es mindestens 10.000 Benutzer pro Entwickler. Es ist einfach nicht möglich, dass eine Person die Supportanfragen von mehr als 10.000 Benutzern bearbeitet. Denken Sie daran, dass Sie, selbst wenn Sie für den Support bezahlen müssen, immer noch viel weniger bezahlen, als wenn Sie die Software auch noch kaufen müssten (und der Support für Closed-Source-Software ist in der Regel teurer und weniger kompetent als der Support für Open-Source-Software).

So beantworten Sie Fragen auf hilfreiche Weise
Seien Sie sanft. Problembezogener Stress kann Menschen unhöflich oder dumm erscheinen lassen, auch wenn sie es nicht sind.

Antworten Sie einem Ersttäter offline. Es gibt keinen Grund, jemanden öffentlich zu demütigen, der vielleicht einen ehrlichen Fehler gemacht hat. Ein echter Neuling weiß vielleicht nicht, wie man in Archiven sucht oder wo die FAQ gespeichert oder eingestellt ist.

Wenn Sie es nicht genau wissen, sagen Sie es! Eine falsche, aber verbindlich klingende Antwort ist schlimmer als gar keine. Verweisen Sie niemanden auf einen falschen Weg, nur weil es Spaß macht, wie ein Experte zu klingen. Seien Sie bescheiden und ehrlich; gehen Sie mit gutem Beispiel voran, sowohl für den Fragesteller als auch für Ihre Gesprächspartner.

Wenn Sie nicht helfen können, behindern Sie nicht. Machen Sie keine Witze über Verfahren, die die Einrichtung des Benutzers zerstören könnten – der arme Trottel könnte diese als Anweisungen interpretieren.

Stellen Sie bohrende Fragen, um mehr Details herauszufinden. Wenn Sie das gut machen, wird der Fragesteller etwas lernen – und Sie vielleicht auch. Versuchen Sie, die schlechte Frage in eine gute zu verwandeln; denken Sie daran, dass wir alle einmal Neulinge waren.

Auch wenn es manchmal gerechtfertigt ist, RTFM zu murmeln, wenn Sie jemandem antworten, der einfach nur ein fauler Sack ist, ist ein Verweis auf die Dokumentation (und sei es nur ein Vorschlag, nach einem Schlüsselbegriff zu googeln) besser.

Wenn Sie die Frage überhaupt beantworten wollen, sollten Sie einen guten Wert bieten. Schlagen Sie keine plumpen Umgehungslösungen vor, wenn jemand das falsche Tool oder den falschen Ansatz verwendet. Schlagen Sie gute Tools vor. Formulieren Sie die Frage neu.

Beantworten Sie die eigentliche Frage! Wenn der Fragesteller so gründlich recherchiert hat, dass X, Y, Z, A, B und C bereits erfolglos ausprobiert wurden, ist es wenig hilfreich, mit „Versuchen Sie A oder B“ oder mit einem Link zu etwas zu antworten, in dem nur steht: „Versuchen Sie X, Y, Z, A, B oder C.“.

Helfen Sie Ihrer Community, aus der Frage zu lernen. Wenn Sie eine gute Frage erhalten, fragen Sie sich: „Wie müsste die entsprechende Dokumentation oder FAQ geändert werden, damit niemand mehr diese Frage beantworten muss?“ Schicken Sie dann einen Patch an den Betreuer des Dokuments.

Wenn Sie für die Beantwortung der Frage recherchiert haben, sollten Sie Ihre Fähigkeiten unter Beweis stellen und nicht so schreiben, als hätten Sie die Antwort aus dem Ärmel geschüttelt. Die Beantwortung einer einzigen guten Frage ist so, als würden Sie einen hungrigen Menschen mit einer Mahlzeit füttern, aber wenn Sie ihm mit gutem Beispiel vorangehen und ihm Recherchefähigkeiten beibringen, können Sie ihm zeigen, wie man Nahrung für ein ganzes Leben anbaut.

Verwandte Ressourcen
Wenn Sie eine Einweisung in die Grundlagen der Funktionsweise von PCs, Unix und dem Internet benötigen, lesen Sie das HOWTO Grundlagen von Unix und Internet.

Wenn Sie Software veröffentlichen oder Patches für Software schreiben, versuchen Sie, die Richtlinien in der Software Release Practice HOWTO zu befolgen.

Danksagung
Evelyn Mitchell hat einige Beispiele für dumme Fragen beigesteuert und den Abschnitt „Wie man eine gute Antwort gibt“ inspiriert. Mikhail Ramendik hat einige besonders wertvolle Verbesserungsvorschläge beigesteuert.