Copyright © 2001 by Eric S. Raymond
Deutsche Übersetzung: 2001 von Dirk Detering
Basierend auf Revision: 1.11
URL des Originals: http://www.tuxedo.org/~esr/faqs/smart-questions.html
In der Welt der Hacker hängt die Art der Antworten, die du auf deine technischen Fragen bekommst, in gleichem Maße davon ab, wie du die Fragen stellst, wie auch von der Schwierigkeit, die Antwort zu entwickeln. Diese Anleitung will dir zeigen, wie man Fragen auf eine Weise stellt, dass es sehr wahrscheinlich ist, eine befriedigende Antwort zu bekommen.
Das Erste, was man verstehen muss ist, dass Hacker schwierige Probleme mögen, und gute, zum Nachdenken reizende Fragen dazu. Wenn wir das nicht täten, wären wir nicht hier. Wenn du uns eine interessante Frage gibst, bei der wir was zum Kauen haben, sind wir dir dankbar. Gute Fragen sind ein Anreiz und ein Geschenk. Gute Fragen helfen uns, unser Verständnis weiterzuentwickeln, und enthüllen oftmals Probleme, die wir sonst nicht wahrgenommen oder worüber wir nicht nachgedacht hätten. Unter Hackern ist "Gute Frage!" ein großes und ernstgemeintes Kompliment.
Trotzalledem haben Hacker den Ruf, einfachen Fragen mit einer Art zu begegnen, die wie Feindseligkeit oder Arroganz erscheint. Manchmal sieht es aus, als wären wir unverschämt zu Neulingen und Unwissenden. Aber das ist nicht wirklich wahr.
Wir sind, verständlicherweise, ablehnend Leuten gegenüber, welche den Eindruck erwecken, dass sie nicht nachdenken wollen oder ihre Hausaufgaben machen, bevor sie Fragen stellen. Leute wie diese sind Zeitfresser — sie nehmen, ohne etwas zurückzugeben. Sie verschwenden Zeit, die wir mit einer anderen, weitaus interessanteren Frage und einer Person verbracht haben könnten, die einer Antwort eher Wert gewesen wäre. Wir nennen Leute wie diese "Versager" [engl. "loser"] (und aus historischen Gründen buchstabieren wir das manchmal "luser").
Wir stellen fest, dass es viele Leute gibt, die nur die Software, die wir schreiben, nutzen wollen, und nicht daran interessiert sind, die technischen Details zu erlernen. Für die meisten Leute ist ein Computer lediglich ein Werkzeug, ein Mittel zum Zweck. Sie haben wichtigere Dinge zu tun in ihrem Leben. Wir respektieren das und erwarten nicht, dass jedermann Anteil an den technischen Sachverhalten nimmt, die uns faszinieren. Nichtsdestotrotz ist unser Stil Fagen zu beantworten abgestimmt auf die Leute, die ein solches Interesse haben und gewillt sind, aktive Teilnehmer an Problemlösungen zu sein. Das wird sich auch nicht ändern. Sollte es auch nicht. Wenn es das täte, wären wir weniger effektiv in den Dingen, die wir am Besten können.
Wir sind (größtenteils) Freiwillige. Wir nehmen uns Zeit aus unserem vielbeschäftigten Leben um Fragen zu beantworten, und manchmal werden wir von ihnen überhäuft. Darum filtern wir rücksichtslos. Teilweise schmeißen wir Fragen von Leuten weg, die Versager zu sein scheinen, um unsere Antwortzeiten effektiverweise den Gewinnern zu widmen.
Wenn du diese Einstellung unmöglich, herablassend oder arrogant findest, überprüfe deine Annahmen. Wir bitten dich nicht, vor uns zu knien — tatsächlich würden die meisten von uns nichts lieber tun, als mit dir als Gleichgesinnten umzugehen und dich in unserer Kultur willkommen zu heissen, wenn du die Anstrengung unternimmst, das möglich zu machen. Aber es ist einfach nicht effizient für uns, zu versuchen Leuten zu helfen, die nicht gewillt sind sich selbst zu helfen. Wenn du mit dieser Art Diskriminierung nicht leben kannst, raten wir dir, jemanden für kommerziellen Support zu bezahlen, anstatt Hacker zu bitten, dir ihre Hilfeleistung zu spenden.
Wenn du dich entscheidest bei uns nach Rat zu fragen, willst du kein Versager sein. Du willst auch nicht wie einer erscheinen. Der beste Weg, um eine schnelle und relevante Antwort zu bekommen ist, zu fragen wie ein Gewinner — wie eine Person mit Geschick, Zuversicht und Ahnung, die lediglich etwas Hilfe in einem bestimmten Problem braucht.
(Verbesserungsvorschläge zu diesem Führer sind willkommen. Du kannst Vorschläge mailen: esr@thyrsus.com. Beachte jedoch, dass dieses Dokument nicht als generelle Anleitung zur netiquette gedacht ist, und ich werde generell Anregungen abweisen, die sich nicht gezielt um das Bekommen von nützlichen Antworten in einem technischen Forum drehen.) [Anm.d.Ü.: Bitte keinerlei solcher Hinweise and den Übersetzter. Hinweise an o.g. Mailadresse bitte nur in englisch]
Bevor du eine technische Frage in einer eMail, in einer Newsgroup oder in einem Webforum stellst, mache folgendes:
Versuche die Antwort zu finden, indem du die Anleitung liest.
Versuche die Antwort zu finden, indem du eine FAQ liest [FAQ = frequently asked questions, häufig gestellte Fragen].
Versuche eine Antwort durch Suche im Web zu finden.
Versuche eine Antwort zu finden, indem du einen fähigen Freund fragst.
Wenn du deine Frage stellst lege dar, dass du das alles bereits getan hast. Das hilft herauszustellen, dass du kein fauler Schwamm bist, der die Zeit der Leute verschwendet. Besser noch, zeige was du von diesen Dingen gelernt hast. Wir mögen es, Fragen von Leuten zu beantworten, die gezeigt haben, dass sie aus Antworten lernen können.
Bereite deine Frage vor. Denke sie durch. Nach Hast klingende Fragen bekommen hastige Antworten, oder gar keine. Je mehr du demonstrierst, dass du Gehirnschmalz und Anstrengung in eine Problemlösung gesteckt hast bevor du um Hilfe fragst, umso wahrscheinlicher wirst du Hilfe bekommen.
Hüte dich, die falsche Frage zu stellen. Wenn du eine Frage stellst, die auf falschen Annahmen beruht, wird J.Random Hacker wahrscheinlich mit einer unnütz wörtlichen Antwort entgegnen, während er "Blöde Frage ..." denkt und hofft, dass die Erfahrung, das zu bekommen wonach du gefragt hast anstatt das, was du eigentlich bräuchtest, dir eine Lehre sein wird.
Nimm niemals an, du habest Anspruch auf eine Antwort. Hast du nicht. Letztlich zahlst du auch nicht für den Dienst. Du wirst eine Antwort erwerben, wenn du sie dir verdienst, indem du eine Frage stellst, die substanziell, interessant und zum Nachdenken reizend ist — eine, die implizit zum Erfahrungsreichtum der Gemeinschaft beiträgt statt lediglich passiv Wissen von anderen abzurufen.
Auf der anderen Seite klarzustellen, dass du fähig und gewillt bist, zur Entwicklung der Lösung beizutragen, ist ein sehr guter Start. "Kann jemand einen Hinweis geben ?", "Was stimmt an meinem Beispiel nicht ?" und "Gibt es eine Stelle, wo ich nachsehen sollte ?" haben mehr Aussicht auf eine Antwort als "Bitte sende die genaue Prozedur, die ich durchführen müsste", denn du stellst klar, dass du wirklich die Sache durchziehen willst, wenn dich nur jemand in die richtige Richtung stupsen kann.
Sei vorsichtig bei der Wahl, wo du deine Fragen stellst. du wirst höchstwahrscheinlich ignoriert, oder als Versager ausgeschrieben, wenn du:
deine Frage an ein Forum sendest, wo sie nicht zum Thema passt [engl.: off topic]
eine sehr elementare Frage in ein Forum stellst, wo fortgeschrittene technische Fragen erwartet werden, oder umgekehrt.
zwischen zu vielen verschiedenen Newsgroups quer-versendest [engl.: cross-post]
Hacker blasen Fragen weg, die an unpassende Stellen gerichtet wurden, um ihre Kommunikationskanäle davor zu schützen, in Unsachlichkeiten zu ertrinken. Du wirst nicht wollen, dass dir das passiert.
Allgemein haben Fragen an ein sorgfältig ausgewähltes öffentliches Forum größere Chancen nützliche Antworten zu bekommen, als gleichartige Fragen in einem privaten Forum. Es gibt viele Gründe dafür. Einer ist einfach die größere Menge potenzieller Beantworter. Ein anderer ist die Menge der Zuhörer. Hacker beantworten eher Fragen, die eine große Menge von Leuten lehren, als Fragen, die nur wenigen dienen.
Wenn ein Projekt eine Entwicklungs-Mailingliste hat, schreibe an diese, nicht an einzelne Entwickler, auch wenn du zu wissen glaubst, wer die Frage am besten beantworten kann. durchsuche die Dokumentation und die Homepage des Projekts nach der Adresse einer Projekt-Mailingliste, und benutze sie. Es gibt viele Gründe dafür:
Jede Frage, die gut genug ist einem Entwickler gestellt zu werden, wird auch für die gesamte Gruppe von Wert sein. Umgekehrt, wenn du denkst, dass deine Frage zu blöd für eine Mailingliste ist, ist das keine Entschuldigung um einen einzelnen Entwickler damit zu belästigen.
Fragen auf der Liste zu stellen, verteilt die Last zwischen Entwicklern. Der einzelne Entwickler (speziell der Projektleiter) mag zu beschäftigt sein, um deine Fragen zu beantworten.
Die meisten Mailinglisten sind archiviert und die Archive sind von Suchmaschinen indiziert. Jemand könnte deine Frage und deren Antwort im Web finden, anstatt sie erneut in der Liste zu stellen.
Falls manche Fragen sehr häufig gestellt werden, können die Entwickler diese Information nutzen, um ihre Dokumentation oder die Software selbst zu verbessern, so dass sie weniger verwirrend sind. Aber wenn diese Fragen nur privat gestellt werden, hat niemand das komplette Bild davon, welche Fragen am meisten gestellt werden.
Wenn du die Adresse der Projekt-Mailingliste nicht finden kannst, sondern siehst nur die Adresse des Projektverantwortlichen, dann schreib ihm. Aber auch in diesem Fall gehe nicht davon aus, dass die Mailingliste nicht existiert. Merke in deiner Mail an, dass du versucht hast die Mailingliste zu finden, es aber nicht konntest. Weise auch darauf hin, dass du nichts dagegen hast, dass deine Mail an andere weitergeleitet wird. (Manche Leute glauben, dass private Mail privat bleiben sollte, auch wenn nichts Geheimes darin steht. Mit der Erlaubnis, die Nachricht weiterzuleiten, gibst du deinem Gegenüber die Wahl, wie er deine Mail behandelt.)
Wir haben die Erfahrung gemacht, dass Leute, die sorglose und schlampige Schreiber sind, gewöhnlich auch sorglos und schlampig in ihrem Denken und Kodieren sind (oft genug, um sogar drauf zu wetten). Fragen für unsorgfältige und schlampige Denker zu beantworten ist nicht sehr lohnend. Wir verbringen unsere Zeit besser mit was Anderem.
Darum ist es wichtig, deine Frage klar und gut auszudrücken. Wenn du dir nicht die Mühe machst, das zu tun, machen wir uns keine Mühe, dich zu beachten. Investiere den zusätzlichen Aufwand, deine Sprache zu verfeinern. Es muss nicht steif oder formell sein — tatsächlich schätzt die Hacker-Kultur unformelle, saloppe und humorvolle Sprache, fein benutzt. Aber es muss fein sein ; es muss Anzeichen dafür geben, dass du nachdenkst und aufmerksam bist.
Buchstabiere, punktiere und benutze Groß-/Kleinschreibung korrekt. Verwechsle nicht "seid" mit "seit" oder "wieder legen" mit "widerlegen". Schreibe NICHT ALLES IN GROSSBUCHSTABEN, dass wird als Schreien gelesen und als unverschämt angesehen. (Alles in Kleinbuchstaben ist nicht viel weniger lästig, da es schwer zu lesen ist. Alan Cox kommt damit durch, aber du nicht).
Allgemeiner, wenn du wie ein halbgebildeter Tölpel schreibst, wirst du höchstwahrscheinlich ignoriert. Wie ein kewles Scr1pt KiddY zu schreiben, ist der absolute Todeskuss und garantiert, dass du im Gegenzug nichts als eisernes Schweigen erhältst (oder einen Haufen Hohn und Sarkasmus)
Wenn du eine Frage in einem Forum stellst, dass nicht deine Muttersprache spricht, wirst du eine gewisse Menge an Nachsicht für Rechtschreib- und Grammatikfehler bekommen — aber keine extra Nachsicht für Nachlässigkeit (und, ja, wir können das gewöhnlich genau unterscheiden). Schreibe auch in Englisch, falls du nicht genau weisst, welche Sprachen dein Empfänger spricht. Vielbeschäftigte Hacker tendieren dazu, Fragen in Sprachen, die sie nicht verstehen, einfach zu überlesen, und Englisch ist die Arbeitssprache des Netzes. Indem du Englisch schreibst, verringerst du die Möglichkeit, dass deine Frage ungelesen gelöscht wird.
Wenn du die Lesbarkeit deiner Frage künstlich erschwerst, ist es wahrscheinlicher, dass sie zugunsten einer anderen übergangen wird, die einfacher zu lesen ist. Daher:
Sende pure Text Mail, kein HTML (Es ist nicht schwer, HTML auszuschalten.)
MIME Anhänge sind normalerweise OK, aber nur, wenn sie wirklich sinnvollen Inhalt haben (so wie eine angehängte Quelldatei oder ein Patch) und nicht nur generierte Textbausteine deines Mailprogramms sind (wie z.B. eine weitere Kopie deiner Mail).
Sende keine Mail in welcher komplette Abschnitte eine einzelne, vielfach umgebrochene Zeile sind (Das macht es zu schwer, nur auf einen Teil der Nachricht zu antworten). Bedenke, dass deine Empfänger Mail auch auf 80-Zeichen-breiten Text Displays lesen und setzte deinen Zeilenumbruch entsprechend auf weniger als 80.
Sende kein MIME Quoted-Printable encoding an ein englischsprachiges Forum. Dieses Encoding kann notwendig sein, wenn du in einer Sprache schreibst, die ASCII nicht abdeckt, aber eine grosse Menge Mail Agents unterstützen das nicht. Wenn sie versagen, sind all diese quer über den Text verstreuten =20 Hieroglyphen hässlich und ablenkend.
Erwarte niemals, dass Hacker in der Lage sind, eingeschlossene proprietäre Dokumentenformate, wie Microsoft Word zu entziffern. Die meisten Hacker reagieren darauf genauso, als hätte man dir einen dampfenden Haufen Schweinedung vor die Haustür gekippt.
Wenn du Mail von einer Windows Maschine sendest, schalte dieses dumme "Smart Quotes" Feature aus. Das, damit du das Einstreuen von Müllzeichen in deine Mail verhinderst.
Auf Mailinglisten oder Newsgroups ist die Betreffzeile dein Königsweg, um die Aufmerksamkeit qualifizierter Experten in ca 50 Zeichen oder weniger zu erlangen. Verschmutze sie nicht mit Geplapper, wie "Bitte helft mir". (geschweige denn "BITTE HELFT MIR!!!!". Solche Botschaften werden schon aus Reflex gelöscht). Versuche uns nicht mit der Tiefe deiner Qual zu beeindrucken. Benutze den Platz stattdessen für eine supergenaue Problembeschreibung.
HILFE! Auf meinem Laptop läuft Video nicht richtig!
XFree86 4.1 verunstaltet den Maus cursor, Fooware MV1005 vid. chipset
Wenn du eine Frage in einer Beantwortung stellst, stell sicher, dass du den Betreff geändert hast um anzuzeigen, dass du eine Frage stellst. Eine Betreffzeile wie : "Re: test" oder "Re: Neuer Fehler" wird wohl kaum eine brauchbare Menge an Aufmerksamkeit erregen. Kürze auch Zitate vorhergehender Mails auf ein Minimum, das ausreicht um neue Leser ins Bild zu setzen.
Beschreibe die Symptome deines Problems oder Fehlers sorgfältig und klar.
Beschreibe die Umgebung in welchem es auftritt (Maschine, Betriebssystem, Anwendung, wasauchimmer).
Beschreibe die Nachforschungen, die du bereits unternommen hast um das Problem zu verstehen und zu lösen, bevor du die Frage gestellt hast.
Beschreibe die Diagnoseschritte, die du selbst unternommen hast um das Problem einzugrenzen, bevor du die Frage gestellt hast.
Beschreibe alle vorangegangenen änderungen an deinem Computer oder der Software-Konfiguration, die eventuell von Bedeutung sein könnten.
Versuche die Fragen, die ein Hacker stellen wird, bestmöglich vorauszusehen und im voraus in deiner Anfrage zu beantworten.
Simon Tatham hat einen exzellenten Essay mit dem Titel How to Report Bugs Effectively geschrieben. Ich empfehle dringend, dass du ihn liest.
Du sollst präzise und informativ sein. Das wird nicht einfach durch das Abladen grosser Mengen Code oder Daten in eine Anfrage erreicht. Wenn du einen großen, komplizierten Testfall hast, der das Programm zum Absturz bringt, versuche ihn zurechtzustutzen und so klein wie möglich zu halten.
Das ist aus mindestens drei Gründen nützlich. Erstens: Wenn man sieht, dass Anstrengung in die Vereinfachung der Fragestellung investiert wurde, ist es wahrscheinlicher, dass du eine Antwort bekommst. Zweitens: Die Vereinfachung der Frage macht es wahrscheinlicher, dass du eine hilfreiche Antwort bekommst. Drittens: Während der Verfeinerung des Fehlerberichts kann es sein, dass du selber eine Lösung oder einen Umgehungsweg entdeckst.
Es ist unnütz Hackern zu erzählen, was deiner Meinung nach das Problem verursacht. (Wenn deine diagnostischen Theorien so ausgereift wären, würdest du andere um Hilfe bitten ?) Daher stelle sicher, dass du ihnen die puren Symptome des Fehlverhaltens schilderst anstatt deiner Interpretationen und Theorien. Lass sie die Interpretation und Diagnose machen.
Ich bekomme aufeinander folgende SIG11 Fehler beim Kernel-Compilieren, und vermute einen Haarriss auf einer der Hauptplatinen-Leiterbahnen. Was ist der beste Weg, diese zu überprüfen ?
Mein selbstgebauter K6/233 mit FIC-PA2007 Hauptplatine (VIA Apollo VP2 Chipset) und 256 MB Corsair PC133 SDRAM bekommt häufig SIG11 Fehler, ca. 20 Minuten nach dem Einschalten während der Kernel-Compilation, aber niemals in den ersten 20 Minuten. Rebooten startet diesen Zeitraum nicht neu, aber Ausschalten über Nacht macht das. Austausch des gesamten RAMs half nicht. Der relevante Teil eines typischen Compilerlaufs-Loggings folgt.
Die hilfreichsten Hinweise in der Erläuterung eines Fehlverhaltens liegen oft in den Ereignissen kurz vorher. Daher sollte deine Mitteilung genau beschreiben, was du getan hast und was die Maschine tat, bis zum Abschmieren. Im Falle eines Kommandozeilen-Prozesses ist es hilfreich, ein Session-Protokoll (z.B. durch Benutzung des Script Utility's) zu haben und die relevanten 20 oder so Zeilen zu zitieren.
Wenn das Programm, das abgeschmiert ist, Diagnoseoptionen (wie z.B. -v für verbose) hat, versuche sorgfältig über die Auswahl der Optionen nachzudenken, die nützliche Debugging-Hinweise zum Transskript zufügen könnten.
Wenn dein Bericht ziemlich lang wird (mehr als um die vier Absätze), mag es sinnvoll sein, dein Problem zu Anfang knapp darzulegen, danach mit der chronologischen Erzählung zu folgen. Auf diese Weise wissen Hacker, worauf sie beim Lesen deines Berichtes achten müssen.
Hacker glauben, Probleme zu lösen sollte ein öffentlicher, transparenter Prozess sein, während dessen ein erster Versuch einer Antwort korrigiert werden kann und sollte, wenn jemand mit grösserem Hintergrundwissen feststellt, dass sie falsch oder unvollständig ist. Auch bekommen sie ein wenig Belohnung für ihre Antworten, wenn Gleichgesinnte sie als kompetent und wissend erkennen.
Wenn du um private Antwort bittest, störst du beides, den Prozess und die Belohnung. Mach es nicht. Es ist die Entscheidung des Antwortenden ob er privat antwortet — und wenn er es tut, dann ist es gewöhnlich weil er denkt, die Frage sei zu schlecht formuliert oder offensichtlich um für Andere von Interesse zu sein.
Es gibt eine begrenzte Ausnahme dieser Regel. Wenn die Frage solcher Art ist, dass du wahrscheinlich eine Menge ziemlich gleichartiger Antworten bekommst, dann sind die magischen Worte: "Mailt mir, und ich werde die Antworten für die Gruppe zusammenfassen". Es ist höflich das zu versuchen und die Mailingliste oder Newsgroup vor einer Flut inhaltlich gleicher Beiträge zu schützen — aber du musst das Versprechen der Zusammenfassung einlösen.
Nie-endende Fragen tendieren dazu als unendliche Zeitsauger wahrgenommen zu werden. Die Leute, die am ehesten fähig sind eine hilfreiche Antwort zu geben, sind auch die meistbeschäftigsten Leute (wenn auch nur, weil sie die meiste Arbeit selber machen). Leute wie diese sind allergisch auf endlose Zeitfresser, daher tendieren sie dazu, allergisch auf endlose Fragen zu sein.
Du wirst eher eine hilfreiche Antwort bekommen, wenn du eindeutig mitteilst, was du von den Antwortenden erwartest (einen Hinweis zu liefern, einen Code zu senden, deinen Patch zu prüfen, was auch immer). Das wird ihre Anstrengungen bündeln und indirekt eine Obergrenze für die Zeit und Energie setzen, die ein Beantworter einbringen muss, um dir zu helfen. Das ist gut.
Um die Welt, in der die Experten leben, zu verstehen, betrachte Fachkenntnis als eine reichlich vorhandene Ressource und Zeit als eine knappe. Je weniger Zeiteinsatz du indirekt erbittest, je wahrscheinlicher wirst du eine Antwort von jemand wirklich Gutem und wirklich Beschäftigtem bekommen.
Daher ist es sinnvoll, deine Frage einzugrenzen um den Zeiteinsatz eines Experten zur Beantwortung zu minimieren. — aber das ist oft nicht dasselbe, wie die Frage zu vereinfachen. Daher ist zum Beispiel "Kannst du mir bitte eine Stelle für eine gute Erläuterung von X nennen ?" gewöhnlich eine geschicktere Frage als "Kannst du mir X erklären, bitte ?". Wenn du Code hast, der nicht funktioniert, ist es normalerweise geschickter jemand nach einer Erklärung für den Fehler zu fragen als jemanden zu bitten, ihn zu beseitigen.
Hacker sind gut darin, Hausaufgaben-Fragen zu erkennen; die meisten von uns haben selber welche gestellt. Diese Fragen sollst du erarbeiten, damit du aus der Erfahrung lernst. Es ist Ok, nach Hinweisen zu fragen, aber nicht nach der vollständigen Lösung.
Widerstehe der Versuchung, deine Anfrage mit inhaltslosen Fragen zu beenden, wie "Kann mir jemand helfen ?" oder "Gibt es dafür eine Antwort ?" Erstens: Wenn du dein Problem halbwegs kompetent beschrieben hast, sind solcherlei zugefügte Fragen mindestens überflüssig. Zweitens: Weil sie überflüssig sind, finden sie Hacker störend — und entgegnen wahrscheinlich mit logisch makellosen aber geringschätzigen Antworten wie: "Ja, dir kann geholfen werden" und "Nein, es gibt keine Hilfe für dich".
Sei höflich. Benutze "Bitte" und "Vielen Dank im Voraus". Mach es klar, dass du die kostenlose Zeit, die Leute einsetzen um dir zu helfen, wertschätzt.
Um ehrlich zu sein: Das ist nicht so wichtig wie (und kein Ersatz für) grammatisch richtig zu sein, präzise und beschreibend, und proprietäre Formate zu vermeiden usw. Hacker würden im Allgemeinen eher leicht schroffe, aber technisch scharfsinnige Fehlerberichte annehmen, als höfliches Gewäsch. (Wenn dich das irritiert, erinnere dich, dass wir eine Frage danach beurteilen, was sie uns lehrt.)
Wie auch immer, wenn du das Technische auf die Reihe bekommst, verbessert Höflichkeit deine Chancen auf eine hilfreiche Antwort.
(Wir müssen anmerken, dass der einzige ernsthafte Widerspruch, die wir auf dieses How-To von altgedienten Hackern bekommen haben, die Empfehlung "Danke im Voraus" betraf. Einige Hacker empfinden, das dies bedeute, niemandem nachträglich zu danken. Wir empfehlen, beides zu tun.)
Sende nach der Lösung des Problems eine Notiz an alle, die dir geholfen haben. Lass sie wissen, dass es behoben ist und danke ihnen nochmal für ihre Hilfe. Wenn das Problem allgemeines Interesse in einer Mailingliste oder Newsgroup hervorgerufen hat, ist es angemessen, diesen Nachtrag dorthin zu senden.
Dein Nachtrag muss nicht lang und verwickelt sein. Ein einfaches "Hallo - es war ein kaputtes Netzwerkkabel! Danke an alle - Bill" ist besser als nichts. Tatsächlich ist eine kurze und geschmackvolle Zusammenfassung besser als eine lange Dissertation, solange die Lösung nicht wirklich technischen Tiefgang hat. Sage, welche Aktion das Problem gelöst hat, aber du brauchst nicht die gesamte Problemlösungsstrategie zu wiederholen.
Neben der Höflichkeit und Information wird diese Art von Nachtrag anderen, die das Archiv der Mailingliste/Newsgroup/Forum durchsuchen, mitteilen, welche Lösung dir half und darum möglicherweise auch ihnen helfen wird.
Nicht zuletzt hilft diese Art Nachtrag jedem der unterstützt hat, das Problem als abgeschlossen zu empfinden. Wenn du selbst kein Techie oder Hacker bist, glaube uns, dass dieses Gefühl sehr wichtig für Gurus und Experten ist, bei denen du um Hilfe angeklopft hast. Problemdarstellungen die in ein unaufgelöstes Nichts münden, sind frustrierend. Es juckt Hacker, die Auflösung zu sehen. Das gute Karma, dass du mit dem Kratzen dieses Juckens erwirbst, wird das nächste Mal sehr hifreich sein, wenn du eine Frage stellen musst.
Es gibt eine alte und heilige Tradition: Wenn du eine Antwort bekommst, in der "RTFM" steht, denkt der Absender, dass du 'Das Verdammte Handbuch Lesen' solltest [engl.: Read The Fucking Manual]. Er hat damit meist recht. Geh und lies es.
RTFM hat einen jüngeren Verwandten. Wenn du eine Antwort bekommst, in der "STFW" steht, meint der Absender, du solltest 'Das Verdammte Web Durchsuchen' solltest [engl.: Search The Fucking Web]. Er hat damit meist recht. Geh und durchsuche es.
Oft hat die Person, die dir eine dieser Antworten schickt, das Handbuch oder die Webseite mit der Information die du brauchst offen vor sich, und schaut hinein, während sie das schreibt. Diese Antworten meinen, dass sie denkt: (a) die Information die du brauchst sei leicht zu finden, und (b) dass du mehr lernst, wenn du die Informationen selber heraussuchst, als wenn du sie mundgerecht serviert bekommst.
Du solltest dadurch nicht beleidigt sein. Im Hacker-Standard zeigt er dir eine grobe Form von Respekt, einfach dadurch, dass er dich nicht ignoriert. Du solltest ihm stattdessen für seine großmütterliche Güte danken.
Falls du die Antwort nicht verstehst, sende nicht sofort eine Bitte um Klärung zurück. Benutze dieselben Werkzeuge, die du ausprobiert hast um deine ursprüngliche Frage zu beantworten (Handbücher, FAQs, das Web, erfahrene Freunde), um die Antwort zu verstehen. Wenn du um Klärung nachfragen musst, stelle heraus, was du bereits gelernt hast.
Stell dir zum Beispiel vor, ich hätte dir gesagt:" Es klingt, als hättest du einen hängenden zentry, du solltest das klären". Dann:
Ist hier eine schlechte Rückfrage: "Was ist ein zentry ?"
Hier ist eine gute Rückfrage: "OK, Ich habe die man page gelesen, und zentries werden nur unter den -z und -p Schaltern erwähnt. Keiner von ihnen sagt etwas darüber, wie man zentries freigibt. Ist es einer davon, oder übersehe ich hier etwas ?
Manches, was wie Grobheit in Hackerkreisen aussieht, ist nicht als Angriff gemeint. Vielmehr ist es das Produkt des direkten, zum Kern vordringenden Kommunikationsstils, der natürlich ist für Leute, die mehr damit beschäftigt sind, Probleme zu lösen als anderen ein warmes und kuscheliges Gefühl zu vermitteln.
Wenn du Grobheit wahrnimmst, versuche gelassen zu reagieren. Wenn sich wirklich jemand danebenbenimmt ist es sehr wahrscheinlich, dass einer der älteren Personen auf der Liste Newsgroup oder des Forums ihn darauf ansprechen wird. Wenn das or her on it. If that nicht passiert und du die Geduld verlierst, ist es wahrscheinlich, dass die Person, über die du dich ärgerst, sich gemäß der Normen der Hacker-Gemeinschaft verhält und dass man meint, dass du einen Fehler machst. Das beeiträchtigt deine Chance, die Information oder Hilfe zu bekommen, die du möchtest.
Auf der anderen Seite wirst du gelegentlich auf Grobheit stoßen, die ziemlich überflüssig ist. Die Kehrseite des oben genannten ist, dass es eine akzeptable Form ist, wirkliche Missetäter recht hart zu schlagen, indem man ihr Fehlverhalten mit einem scharfen verbalen Skalpell seziert. Sei dir deiner Basis auf jeden Fall sehr sicher, bevor du das versuchst. Die Grenze zwischen Zurechtweisung einer Grobheit und dem Auslösen eines sinnlosen Beleidigungskrieges ist dünn genug, dass selbst Hacker nicht selten darüber stolpern. Wenn du ein Neuling oder Außenseiter bist, sind deine Chancen, so ein Versehen zu vermeiden, gering. Wenn du hinter Information her bist anstatt Unterhaltung, ist es besser deine Hände von der Tastatur zu halten, anstatt das zu riskieren.
(Manche Leute nehmen an, dass viele Hacker eine milde Form von Autismus oder Asperger-Syndrom haben und einige Schaltkreise vermissen lassen, die "normale" soziale Interaktion ermöglichen. Das mag stimmen, oder auch nicht. Wenn du selbst kein Hacker bist, mag es dir helfen mit unserer Exzentrizität fertig zu werden, wenn du uns für gehirngeschädigt hältst. Mach ruhig so weiter. Wir stören uns nicht daran. Wir mögen es zu sein was wir sind, was immer es ist. Und wir haben eine gesunde Skepsis gegen klinische Etiketten.)
Im nächsten Abschnitt sprechen wir über eine andere Sache, die Art von 'Grobheit', die du erleben wirst, wenn du dich danebenbenimmst.
Merkwürdigerweise wirst du es ab und zu in Foren der Hacker Gemeinschaft vermasseln — auf Weisen, die in diesem Artikel beschrieben sind, oder ähnlich. Und du wirst genau gesagt bekommen, wie du's vermasselt hast, möglicherweise mit bunten Nebenbemerkungen. öffentlich.
Wenn das passiert, ist das Schlechteste, was du tun kannst, über diese Erfahrung zu jammern, zu behaupten, das du verbal überfallen worden bist, Entschuldigungen zu fordern, heulen, den Atem anzuhalten, einen Rechtsstreit anzudrohen, sich bei den Arbeitgebern der Leute zu beschweren, den Klodeckel obenzulassen usw. Stattdessen, mach das hier:
Steh drüber. Das ist normal. In Wahrheit ist es gesund und angemessen.
Gemeinschaftsnormen erhalten sich nicht selbst. Sie werden von Leuten erhalten, die sie aktiv anwenden, öffentlich sichtbar. Jammere nicht, dass die ganze Kritik hätte in Privatmail mitgeteilt werden sollen: So läuft das nicht. Es ist auch nicht nützlich darauf zu beharren, dass du persönlich beleidigt worden bist, wenn jemand anmerkt, dass eine deiner Behauptungen falsch war, oder dass er anderer Ansicht ist. Das sind Versager-Standpunkte.
Es gab Hackerforen, wo aufgrund einer fehlgeleiteten Überbetonung von Höflichkeit Teilnehmer generell wegen Versands von Bemängelungen der Beiträge eines anderen ausgeschlossen wurden, und sie "Sag besser nichts, wenn du dem Benutzer nicht helfen willst" zu hören bekamen. Die daraus resultierende Abwanderung von Teilnehmern mit Ahnung führte dazu, dass Gespräche zu sinnlosem Gebrabbel verkamen und das Forum als technisches Forum unbrauchbar wurde.
Übertrieben "freundlich" (in diesem Sinne) oder nützlich: Such dir was aus.
Erinnere dich: Wenn dieser Hacker dir sagt, dass du es vermasselt hast, und dir (ungeachtet wie grantig) sagt, du sollst das nicht mehr machen, macht er das aus Sorge um (1) dich und (2) die Gemeinschaft. Es wäre weitaus einfacher für ihn, dich zu ignorieren und aus seinem Leben auszufiltern. Wenn du es nicht einrichten kannst, dankbar zu sein, habe wenigstens ein bisschen Würde. Jammer nicht und erwarte nicht, wie ein zerbrechliches Püppchen behandelt zu werden, nur weil du ein Neuling mit einer theatralisch überempfindlichen Seele bist und ihm Wahn, du hättest einen Anspruch darauf.
Hier sind einige klassische dumme Fragen, und was Hacker denken, wenn sie sie nicht beantworten.
A: An der selben Stelle, wo ich es gefunden habe, Idiot — am anderen Ende einer Websuche. Himmel, weiss nicht inzwischen jeder, wie man Google bedient ?
A: Das ist keine Frage, und ich habe keine Lust 'Zwanzig Fragen' zu spielen, oder dir die eigentliche Frage aus der Nase zu ziehen — Ich hab besseres zu tun. Wenn ich sowas sehe, ist meine Reaktion normalerweise eine von diesen:
Hast du dem noch etwas hinzuzufügen ?
Oh, das ist aber schlecht, ich hoffe, du kriegst das wieder hin.
Und was hat das genau mit mir zu tun ?
A: Ja. Schmeiss den Microsoft Müll weg und installiere Linux.
A: Nö. Ich bräuchte direkten Zugang zu deiner Maschine um das zu beheben. Geh und frag deine örtliche Linux User Gruppe für Vor-Ort-Hilfe. (Du kannst eine Liste von User Gruppen hier finden.)
Zuletzt möchte ich beispielhaft darstellen, wie man Fragen auf geschickte Art stellt. Fragepaare über dasselbe Problem, eine in einer dummen Art und eine auf geschickte Weise gestellt.
Diese Frage schreit förmlich nach"STFW" als Antwort.
Dieser hat bereits Das Verdammte Web durchsucht und klingt, als hätte er wirklich ein Problem.
Er nimmt an, dass jemand anderes es verpatzt hat. Arrogant von ihm.
Er hat seine Umgebung angegeben, er hat die FAQ gelesen, er beschreibt den Fehler, und er nimmt nicht an, dass seine Probleme der Fehler eines anderen sind. Dieser Kerl scheint einige Aufmerksamkeit zu verdienen.
J.Random Hacker's Antwort wird wahrscheinlich sein: "Sicher. Musst du auch Bäuerchen machen und die Windeln gewechselt bekommen ?", gefolgt von einem Druck auf die Löschtaste.
Diese Person auf der anderen Seite, scheint einer Antwort würdig. Er hat Problemlöse-Intelligenz gezeigt anstatt nur passiv darauf zu warten, dass eine Antwort vom Himmel fällt.
Bemerke den feinen aber wichtigen Unterschied in der letzten Antwort zwischen "Gib mir eine Antwort" und "hilf mir herauszufinden, welche weiteren Diagnosen ich durchführen kann, um Erleuchtung zu bekommen"
In Wahrheit ist die Form der letzten Frage eng auf einen tatsächlichen Vorfall gegründet, der sich im August 2001 auf der Linux-Kernel Mailingliste begab. Ich (Eric) war derjenige, der diesmal die Frage stellte. Ich bemerkte misteriöse lockups auf einem Tyan S2464 Motherboard. Die Listenteilnehmer liefernten die kritischen Informationen, die ich brauchte um sie zu beheben.
Da ich die Frage auf diese Weise stellte, gab ich Leuten etwas zu kauen. Ich machte es leicht und attraktiv für sie, dort einzusteigen. Ich zeigte Respekt für die Fähigkeiten meiner Gleichgesinnten und lud sie ein, sich mit mir als einem Gleichgesinnten zu beraten. Ich zeigte auch Respekt für den Wert ihrer Zeit, indem ich ihnen die Sackgassen erzählte, in die ich bereits gegangen war.
Nachher, als ich allen dankte und anmerkte, wie gut der Prozess funktioniert hat, bemerkte ein ###lkml### Mitglied, dass er seiner Ansicht nach nicht so gut funktionierte, weil ich ein "Name" auf dieser Liste bin, sondern weil ich die Frage in richtiger Art und Weise gestellt habe.
Hacker sind auf manche Art eine recht gnadenlose Leistungsgesellschaft. Ich bin sicher, dass er recht hat, und dass ich, wenn ich mich wie ein Schwamm verhaltenhätte, ich beleidigt oder ignoriert worden wäre, ungeachtet wer ich bin. Seine Anregung, dass ich diesen ganzen Vorfall als Anleitung für andere aufschreiben sollte, führte direkt zur Zusammenstellung dieses Führers.
Wenn du keinen Antwort bekommst, nimm es bitte nicht persönlich, dass wir nicht glauben, dir helfen zu können. Manchmal mögen die Mitglieder der gefragten Gruppe einfach die Antwort nicht wissen. Keine Antwort ist nicht dasselbe, wie ignoriert zu werden, obwohl es zugegebenermaßen schwer ist, den Unterschied von außen festzustellen.
Allgemein, einfach deine Frage erneut zu senden ist eine schlechte Idee. Das wird als sinnlos belästigend angesehen.
Es gibt andere Hilfsquellen, an die du dich wenden kannst, oft Quellen, die besser auf die Bedürfnisse eines Neulings passen.
Es gibt viele Online- und örtliche Benutzergruppen die von Software schwärmen, obwohl sie vielleicht niemals selber Software geschrieben haben. Diese Gruppen sind oft so gestaltet, dass Leute sich gegenseitig helfen können, ebenso wie neuen Benutzern.
Es gibt auch eine Menge kommerzieller Unternehmen, mit denen du einen Vertrag für Hilfe machen kannst, sowohl gross als auch klein (Red Hat und LinuxCare sind zwei der bekanntesten; es gibt noch viele weitere). Sei nicht bestürzt über den Gedanken für ein bisschen Hilfe zu zahlen! Letztendlich, wenn dein Automotor eine zerstörte Zylinderkopfdichtung hat, ist es wahrscheinlich, dass du ihn in eine Werkstatt bringst und für die Behebung zahlst. Auch wenn dich die Software nichts kostet, du kannst nicht erwarten das Unterstützung immer für umsonst kommt.
Für populäre Software wie Linux gibt es mindestens 10.000 Benutzer pro Entwickler. Es ist schlicht nicht möglich für eine Person, die Support-Anfragen von über 10.000 Benutzern zu verwalten. Erinnere dich, dass auch wenn du für Support zahlen musst, du immer noch weniger bezahlst als wenn du die Software ebenfalls kaufen müsstest (und Support für closed-source Software ist gewöhnlich weitaus teurer und weniger kompetent als Suppport für open-source Software).
[ Anm.d.Ü.: Eric spricht hier immer von "time sinks" und verwendet damit das ausdruckstarke Bild von Senken, Gullys oder Ausgüssen, in die die investierte Zeit abfliesst.]