Originaldokument: http://www.catb.org/~esr/faqs/smart-questions.html
Übersetzung als Projekt der Linux User Group Bolzano/Bozen/Bulsan, basierend auf Revision 2.8 vom 8. August 2003.
Kommentare zur Übersetzung bitte an Thomas Pircher, <tehpeh@gmx.net>
Andere deutsche Übersetzungen findest Du auf der Homepage von Richard Voss (www.fruiture.de) und auf der Homepage von Dirk Detering (http://www.dets-home.de).
Vielen Dank an Michael Schröpl, Martha Pircher, Andreas Waschbuesch, Karsten Desler und Christian Peer für die Korrekturen und Verbesserungsvorschläge zu dieser Übersetzung.Copyright © 2001 Eric S. Raymond
Inhaltsverzeichnis
Übersetzungen:
Englisch (Originaldokument),
Dänisch,
Estnisch,
Französisch,
Hebräisch,
Polnisch,
Russisch,
Spanisch,
Ungarisch.
Wenn Du dieses Dokument oder Teile davon kopieren, mirroren, übersetzen willst, siehe Eric Raymonds copying policy.
Die Webseiten vieler Projekte enthalten in dem Abschnitt, in dem aufgelistet wird, wo man Hilfe erhält, einen Link auf dieses Dokument. Das ist gut so, dafür wurde es geschrieben – aber wenn Du ein Webmaster bist, der einen solchen Link erstellt, füge bitte gut sichtbar in der Nähe des Links eine Randnotiz ein, dass wir kein Helpdesk für Euer Projekt sind!
Wir haben schmerzhaft lernen müssen, dass wir ohne eine solche Erklärung andauernd von Volltrotteln belästigt werden, die glauben, dass die Tatsache, dieses Dokument veröffentlicht zu haben, uns dazu verpflichtet, alle technischen Probleme dieser Welt lösen zu müssen.
Wenn Du diesen Text liest, weil Du Hilfe brauchst, und Du den Eindruck hast, Du kannst sie direkt von den Autoren bekommen, dann bist Du einer der genannten Volltrottel. Stelle uns keine Fragen. Wir werden Dich einfach ignorieren. Wir zeigen Dir, wie Du Hilfe von Leuten bekommst, welche sich mit Deiner Hardware oder Software auskennen, aber zu 99% werden nicht wir diese Leute sein. Sofern Du nicht genau weisst, dass einer der Autoren ein Experte im fraglichen Gebiet ist, lass uns in Ruhe, und alle werden glücklicher sein.
In der Welt der Hacker hängen die Antworten, die Du auf Deine technische Frage erhältst, sowohl von der Art ab, wie Du die Frage gestellt hast, als auch von der Schwierigkeit, eine Antwort zu finden. Dieser Text zeigt Dir, wie man Fragen so stellt, dass es wahrscheinlich ist, darauf eine zufrieden stellende Antwort zu bekommen.
Zu allererst ist es wichtig, zu verstehen, dass Hacker schwierige Probleme und gute, zum Denken anregende Fragen darüber mögen. Wenn wir das nicht täten, wären wir nicht hier. Wenn Du uns eine interessante Frage zum Durchkauen gibst, sind wir Dir dankbar; gute Fragen sind stimulierend und ein Geschenk. Gute Fragen helfen, unser Verständnis zu entwickeln und oft enthalten sie Probleme, die wir sonst nicht bemerkt und worüber wir sonst auch nicht nachgedacht hätten. Unter Hackern ist der Ausruf "Gute Frage!" ein großes und ehrliches Kompliment.
Trotzdem haben Hacker den Ruf, auf einfache Fragen mit Feindseligkeit und Arroganz zu reagieren. Scheinbar sind wir grob zu Neulingen und nicht Eingeweihten. Das ist aber nicht wirklich der Fall.
Wir verhalten uns allerdings (und das soll keine Entschuldigung sein) feindselig Leuten gegenüber, die nicht willens zu sein scheinen, selbst zu denken und ihre Hausaufgaben zu machen, bevor sie ihre Fragen stellen. Solche Menschen sind ein Fass ohne Boden, sie nehmen, ohne etwas zurück zu geben und verbrauchen Zeit, die mit interessanteren Fragen und Personen, die eher eine Antwort verdient hätten, besser verwendet wäre. Wir nennen solche Menschen "Loser" (manchmal als "luser" geschrieben, oder im deutschsprachigen Raum DAUs, Dümmste Anzunehmende User).
Uns ist bewusst, dass viele Leute nur unsere Software verwenden wollen und kein Interesse für technische Details aufbringen. Für die meisten Leute ist der Computer einfach ein Werkzeug, ein Mittel zum Zweck. Sie haben wichtigere Dinge zu tun. Wir akzeptieren das und erwarten nicht, dass jeder sich für die technischen Belange erwärmen kann, die uns faszinieren. Trotzdem sind unsere Antworten auf Leute abgestimmt, die dieses Interesse haben und aktiv bei der Problemlösung teilnehmen wollen. Dieser Umstand wird sich nicht ändern, und er sollte es auch nicht tun. Denn wenn das geschehen würde, wären wir weniger effektiv in dem, was wir bisher sehr gut machen.
Wir sind (überwiegend) Freiwillige. Wir verwenden Zeit unseres beschäftigten Lebens dafür, Fragen zu beantworten, und manchmal werden diese einfach zu viel. Deshalb wird rücksichtslos gefiltert. Genauer gesagt, wir eliminieren Fragen von Leuten, die sich wie Loser ausnehmen und verwenden die gewonnene Zeit effizienter mit anderen.
Wenn Du dieses Verhalten für widerlich, herablassend oder arrogant hältst, denk noch einmal darüber nach. Wir wollen nicht, dass Du vor uns nieder kniest – im Gegenteil, den meisten von uns wäre nichts lieber, Dich als Gleichen unter Gleichen zu behandeln und Dich in unserer Kultur willkommen zu heißen, wenn Du Dir die Mühe machst, das zu ermöglichen. Aber es ist für uns einfach nicht tragbar, Leuten zu helfen, die nicht gewillt sind, sich selber zu helfen. Es ist OK, nicht alles zu wissen; es ist nicht OK, sich dumm zu stellen.
Während es nicht notwendig ist, bereits technisch kompetent zu sein, um unsere Aufmerksamkeit zu erlangen, ist es nötig, die Art von Verhalten zu zeigen, mit der man sich Wissen aneignet – Geistesgegenwart, Bedachtheit, Aufmerksamkeit, den Willen, ein aktiver Partner bei der Entwicklung einer Lösung zu sein. Wenn Du mit dieser Art Diskriminierung (im Sinne von Unterscheidung) nicht zurecht kommst, raten wir Dir, für einen kommerziellen Supportvertrag zu bezahlen, anstatt von Hackern geschenkte Hilfestellung zu erwarten.
Wenn Du Dich für uns entscheidest und Hilfe brauchst, willst Du kein Loser sein. Du willst auch nicht wie einer wirken. Die beste Art, schnelle und brauchbare Antworten zu bekommen, ist die, wie sie jemand mit Grips, Selbstvertrauen und Wissen an den Tag legt, welcher die Hilfe nur bei einem bestimmten Problem braucht.
(Verbesserungen zu diesem Text sind willkommen. Du kannst eine Mail an den Autor des Originaldokuments <esr@thyrsus.com> schicken (oder wegen Übersetzungsfehler zu <tehpeh@gmx.net>, Anm.d.Übers.). Dieses Dokument ist keine allgemeine Netiquette, und ich werde keine Vorschläge aufnehmen, die nicht speziell für technische Foren ausgelegt sind.)
Bevor Du eine technische Frage per eMail verschickst, in eine Newsgroup oder ein Web-Forum postest, befolge bitte folgende Schritte:
Anleitung 1.
Versuche, eine Antwort durch Suchen im Web zu finden.
Versuche, eine Antwort durch Lesen des Handbuches (Manuals) zu finden.
Versuche, eine Antwort durch Lesen der FAQ zu finden.
Versuche, eine Antwort durch eigene Untersuchungen und Tests zu finden.
Versuche, eine Antwort zu bekommen, indem Du einen erfahrenen Freund fragst.
Wenn Du ein Programmierer bist, dann versuche, eine Antwort durch Lesen des Source-Codes zu finden.
Wenn Du Deine Frage stellst, lass durchblicken, dass Du diese Dinge bereits getan hast; das stellt sicher, dass Du nicht als Schmarotzer und Zeitverschwender angesehen wirst. Besser, Du gibst zu verstehen, dass Du dabei gelernt hast. Wir mögen es, Leuten zu antworten, die gezeigt haben, dass sie durch Antworten lernen können und wollen.
Verwende die Methode, mit Google nach der exakten Fehlermeldung, die Du erhältst, zu suchen (suche sowohl in den Google-Groups als auch nach Webseiten). Das wird Dich wahrscheinlich zu Dokumentationen oder zu einer Mailing Liste führen, die Deine Frage beantworten. Wenn Du etwas gefunden hast, ist es hilfreich, den Satz "ich habe nach folgenden Stichworten gegoogelt, aber nichts wirklich Hilfreiches gefunden" in einer Mail oder einem Posting anzuführen.
Bereite Deine Frage vor. Denke sie gut durch. Hastig geschriebene Fragen erhalten hastige Antworten, wenn überhaupt welche. Je mehr Du zeigst, dass Du schon Energie in Lösungsversuche investiert hast, desto wahrscheinlicher erhältst Du Hilfe.
Vermeide es, die falsche Frage zu stellen. Wenn Du eine Frage auf Grund falscher Annahmen stellst, wird J. Random Hacker wahrscheinlich mit einer nutzlosen Antwort parieren, während er sich "Dumme Frage..." denkt. Er erhofft sich damit, dass Du die Erfahrung, das bekommen zu haben, wonach Du gefragt hast, und nicht das, was Du brauchtest, Dir eine Lehre sein lassen und Du in Zukunft bessere Fragen stellen wirst.
Nimm niemals an, Du hättest ein Recht auf eine Antwort. Das hast Du nicht; schließlich hast Du für diese Dienstleistung nicht bezahlt. Du wirst eine Antwort bekommen, indem Du eine sinnvolle, interessante und zum Denken anregende Frage stellst, die indirekt zum Wissen der Gemeinschaft etwas beiträgt, und nicht nur passiv das Wissen anderer anzapft.
Auf der anderen Seite ist das Signalisieren der Bereitschaft zu lernen und in der Lösungsfindung zu helfen, ein sehr guter Anfang. Die Fragen "Kann mir jemand einen Tipp geben?", "Was fehlt in meinem Beispiel?" und "Gibt es eine Web-Seite, die ich gesehen haben sollte?" sind wesentlich erfolgversprechender als "Bitte gebt mir die exakte Anleitung, die ich befolgen soll", weil Du damit zeigst, dass Du den Prozess wirklich zu Ende führen willst, wenn Dich jemand in die richtige Richtung weist.
Suche Dir den Ort, wo Du fragst, gut aus. Du wirst wahrscheinlich ignoriert oder als Loser abgestempelt werden, wenn Du:
Deine Frage in ein Forum postest, in dem es off topic ist.
eine sehr einfache Frage in ein Forum postest, in dem fortgeschrittene Fragen erwartet werden (und umgekehrt).
in viele verschiedene Newsgroups Cross-Postings verschickst.
eine persönliche Mail an jemanden schickst, der weder Dein Bekannter noch persönlich für die Lösung Deines Problems zuständig ist.
Hacker schmettern unpassende Fragen ab, um ihren Kommunikationskanal vor der Überflutung durch Irrelevantes zu schützen. Du willst nicht, dass Dir das passiert.
Der erste Schritt ist deshalb, das richtige Forum zu finden. Einmal mehr sind Google und andere Web-Suchmethoden Deine Freunde. Verwende sie, um die passendste Projekt-Webseite zu Deiner Hardware oder Software, die Probleme macht, zu finden. Normalerweise enthält sie Links zu FAQs (Frequently Asked Questions) und zu Projekt-Mailinglisten und deren Archiven. Das sind dann die Orte, in denen Du um Hilfe suchen kannst, wenn Deine eigenen Bemühungen der Problemlösung (einschließlich dem Lesen der FAQs) nichts gebracht haben.
eMails an Personen oder an Foren zu verschicken, die Du nicht kennst, ist im besten Fall riskant. Erwarte zum Beispiel nicht, dass der Autor einer informativen Webseite Dein Gratis-Berater ist. Mache keine optimistischen Einschätzungen, ob Deine Mail willkommen ist – wenn Du unsicher bist, sende sie anderswo hin oder lass es ganz bleiben.
Bei der Auswahl einer Newsgroup oder einer Mailingliste vertraue nicht blind auf deren Namen; schaue in ihre FAQ oder Charta und vergewissere Dich, dass Dein Posting dort on-topic ist. Lies einige Beiträge mit, um zu verstehen, wie die Dinge in der Gruppe gehandhabt werden. Es ist eine gute Idee, eine Stichwortsuche mit Worten, die mit Deinem Problem zu tun haben, im Archiv der Mailingliste oder Newsgroup durchzuführen, bevor Du postest. Du könntest dort eine Antwort finden, und wenn nicht, wird es Dir helfen, die Frage besser zu formulieren.
Sei Dir bewusst, was Dein Thema ist! Klassische Fehler sind Fragen über Unix- oder Windows-Programmierschnittstellen in einem Forum zu stellen, das sich einer Sprache oder Bibliothek widmet, die auf beide Plattformen portabel ist. Wenn Du nicht verstehst, warum das ein Schnitzer ist, wäre es für Dich am besten, keine Frage zu stellen, bis Du es verstanden hast.
Im Allgemeinen werden Fragen in einem gut ausgewählten, öffentlichen Forum eher sinnvoll beantwortet, als dies in einem privaten der Fall ist. Dafür gibt es verschiedene Gründe. Einer ist einfach der größere Umfang an potentiellen Helfern. Ein anderer ist die größere Zahl an Lesern; Hacker antworten lieber auf Fragen, aus denen viele Leute etwas lernen können, als auf Fragen, die nur wenigen nützen.
Verständlicherweise bekommen bekannte Hacker und Autoren von populärer Software schon mehr fehlgeleitete Mails, als ihnen lieb ist. Wenn Du diese Flut noch vergrößerst, kannst du im Extremfall der Tropfen sein, der das Fass zum Überlaufen bringt – schon oft genug haben Mitarbeiter von populären Projekten ihre Hilfe wegen zu großer Belastung ihrer eMail-Konten durch sinnlose Mails zurückgezogen.
Wenn ein Projekt eine Entwickler-Mailing-Liste unterhält, schreibe an die Liste, nicht an einzelne Personen, auch wenn Du zu wissen glaubst, wer Deine Frage möglicherweise am besten beantworten könnte. Suche in der Dokumentation und der Projekt-Seite nach der Adresse der Mailing-Liste und verwende sie. Es gibt mehrere gute Gründe dafür:
Jede Frage, die gut genug ist, an einen Entwickler gestellt zu werden, ist auch für die gesamte Gruppe wertvoll. Wenn Du dagegen vermutest, Deine Frage sei für die Liste zu dumm, dann ist das keine Entschuldigung, einen Entwickler damit zu belästigen.
Fragen in der Liste verteilen die Last auf mehrere Entwickler. Der einzelne Programmierer (besonders wenn er der Projektleiter ist) könnte zu beschäftigt sein, Deine Frage zu beantworten.
Die meisten Mailinglisten werden archiviert und die Archive werden von Suchmaschinen indiziert; jemand mit dem gleichen Problem kann dort die Frage und eine eventuelle Antwort darauf finden, anstatt sie noch einmal in der Liste zu stellen.
Wenn gewisse Fragen oft auftauchen, können sie als Anlass genommen werden, um die Dokumentation oder das Programm selbst zu verbessern. Aber wenn die Fragen privat gestellt werden, hat niemand den Überblick, was häufig gefragt wurde.
Wenn Du keine Projekt-Mailingliste finden kannst, und nur die Adresse des Projektleiters findest, kannst Du ihm schreiben. Aber auch in diesem Fall solltest Du nicht davon ausgehen, dass keine Liste existiere. Erkläre in der Mail, dass Du keine Mailingliste finden konntest. Erwähne auch, dass Du nichts dagegen hast, wenn die Mail weitergeleitet wird. (Manche Menschen sind der Auffassung, dass private Mails privat bleiben sollten, auch wenn darin nichts Geheimes enthalten ist. Durch die Einwilligung gibst Du dem Maintainer die Möglichkeit, die Mail seinem Ermessen nach zu behandeln.)
In Mailing Listen und Newsgroups ist die Betreffzeile eine nicht zu unterschätzende Möglichkeit, in 50 oder weniger Zeichen die Aufmerksamkeit von Experten auf Dich zu ziehen. Verschwende sie nicht für Geplapper wie "Bitte helft mir!" (oder gar "BITTE HELFT MIR !!1!"; solches Zeugs wird reflexartig entsorgt). Versuche nicht, uns mit der Größe Deiner Pein zu beeindrucken; verwende den Platz besser für eine kurze Beschreibung des Problems.
Eine sinnvolle Konvention für Betreffzeilen, die von vielen Support-Organisationen verwendet wird, ist "Objekt - Abweichung". Das "Objekt" beschreibt, welches Ding oder Gruppe von Dingen ein Problem aufweist, und die "Abweichung" beschreibt eben die Abweichung vom erwarteten Verhalten.
Hilfe! Video geht nicht richtig auf meinem Laptop!
XFree86 4.1 verzerrter Mouse Cursor, Fooware MV1005 vid. Chipsatz
XFree86 4.1 Mouse Cursor auf Fooware MV1005 vid. Chipsatz - ist verzerrt
Der Denkprozess, eine Beschreibung vom Typ "Objekt-Abweichung" zu verfassen, hilft Dir dabei, Deine Gedanken über das Problem zu ordnen. Was ist betroffen? Nur der Mauszeiger oder auch andere grafische Elemente? Ist es spezifisch für XFree86? Oder Version 4.1? Ist das ein Problem des Fooware Video Chipsatzes? Von Modell MV1500? Ein Hacker, der das sieht, kann auf den ersten Blick verstehen, womit Du Probleme hast und in welcher Art sie auftreten.
Wenn Du eine Frage in einem Antwort-Beitrag stellst, versichere Dich, die Betreffs-Zeile dementsprechend zu ändern. Eine Betreffzeile wie "Re: test" oder "Re: neuer Bug" zieht womöglich nicht die erhoffte Aufmerksamkeit auf sich. Reduziere auch das Zitieren vorangegangener Nachrichten auf ein notwendiges Minimum, damit neue Leser verstehen, worum es geht.
Drücke nicht einfach auf "antworten", um einen komplett neuen Thread anzufangen. Das würde Deine Leserschaft verkleinern. Einige Mailreader wie Mutt erlauben es, Beiträge nach Threads zu sortieren und dann den gesamten Diskussionsfaden zu verstecken, indem sie ihn zusammenfalten. Leute, die das tun, werden Deinen Beitrag niemals sehen.
Die Betreffzeile zu verändern reicht nicht aus. Mutt und wahrscheinlich auch andere Mailprogramme verwenden zusätzliche Informationen im Header der Mail, um sie einem Thread zuzuordnen, nicht nur die Betreffzeile. Beginne stattdessen eine komplett neue Nachricht.
Wenn Du die Frage mit einem "Bitte schickt eure Antworten an..." versiehst, verringerst Du die Aussichten auf eine Antwort. Wenn Du Dir nicht die paar Sekunden leisten kannst, einen korrekten Reply-To Header zu setzen, können wir es uns nicht leisten, über Dein Problem nachzudenken. Falls Dein Mail-Programm Dir das nicht erlaubt, nimm ein besseres Mail-Programm. Falls es für Dein Betriebssystem kein Programm gibt, welches dazu in der Lage wäre, nimm ein besseres Betriebssystem.
Wir wissen aus Erfahrung, dass Leute mit oberflächlichem und schlampigem Schreibstil auch oberflächliche und schlampige Denker und Coder sind (jedenfalls oft genug, um darauf wetten zu können). Solchen Leuten Fragen zu beantworten, lohnt sich nicht; mit dieser Zeit können wir etwas Besseres anfangen.
Es ist also wichtig, Deine Fragen klar und deutlich zu formulieren. Wenn Dir das zu mühsam ist, ist es für uns zu mühsam, auf Deine Frage einzugehen. Verwende ein wenig Zeit darauf, an Deiner Sprache zu feilen. Sie muss nicht steif und formal sein – in der Hackerkultur schätzt man zwanglose, humorvolle und präzise Sprache. Aber sie muss präzise sein; das ist ein Anzeichen, dass Du mitdenkst und aufmerksam bist.
Verwende korrekte Rechtschreibung, Interpunktion und Großschreibung. Schreibe NICHT ALLES GROSS, das wird als Schreien empfunden und gilt als unhöflich. (Vollständige Kleinschreibung ist einen Deut weniger nervtötend, ist aber auch schwer zu lesen. Einem Alan Cox wird man so etwas vielleicht durchgehen lassen – Dir nicht.)
Im Allgemeinen, wenn Du wie ein halb-alphabetisierter Dussel schreibst, wirst Du wahrscheinlich ignoriert werden. Der Schreibstil eines l33t script kiddie hax0r ist der absolute Tod und garantiert Dir eisiges Schweigen (oder bestenfalls eine Portion Hohn und Sarkasmus) als Rückantwort.
Wenn Du in ein Forum postest, das nicht Deine Muttersprache verwendet, darfst Du mit einer gewissen Nachsicht für Rechtschreib- und Grammatikfehler rechnen – nicht aber mit Gnade für Faulheit (und ja, wir erkennen in der Regel den Unterschied). Schreibe in Englisch, wenn Du die Sprache des betreffenden Forums nicht kennst. Beschäftigte Hacker neigen dazu, unverständliche Fragen zu löschen, und Englisch ist nun einmal die Lingua Franca im Internet. Wenn Du in Englisch schreibst, minimierst Du die Wahrscheinlichkeit, dass Deine Frage ungelesen bleibt.
Wenn Du das Lesen Deiner Frage künstlich erschwerst, wird sie möglicherweise zugunsten einer zugänglicheren Nachricht übergangen. Also:
Sende einfachen Text (plain text), kein HTML. (Es ist nicht schwer, HTML abzustellen.)
MIME Attachments sind normalerweise in Ordnung, aber nur, wenn sie wirklichen Inhalt liefern, und nicht vom Mailprogramm generierter Datenmüll (wie eine weitere Kopie der Mail) sind.
Versende keine Nachrichten, in denen ganze Absätze als mehrfach umgebrochene Zeilen dargestellt werden. (Das erschwert das Antworten auf einen Teil Deines Textes.) Bedenke, dass Deine Mitteilung auch in einem 80 Zeichen breiten Bildschirm gelesen wird. Setze deshalb die Zeilenlänge auf eine Zahl kleiner als 80.
Vermeide auf jeden Fall Zeilenumbrüche von Daten (wie z.B. Log-Einträgen oder Session-Transskripten). Daten sollten genau so gepostet werden, wie sie produziert wurden, damit die Leser sich darauf verlassen können, das zu sehen, was Du als Meldung erhalten hast.
Sende keine MIME Quoted-Printable Kodierungen in englischsprachige Foren. Diese Kodierungen sind nützlich, wenn Du Zeichen verwenden musst, die nicht im ASCII-Zeichensatz enthalten sind, aber viele Mailprogramme unterstützen sie nicht. In dem Fall ist der Text mit störenden und hässlichen =20 Zeichen übersät.
Nimm niemals an, Hacker könnten proprietäre und undokumentierte Formate wie Microsoft Word lesen. Die meisten Hacker reagieren darauf so, wie Du es tun würdest, wenn Dir jemand eine Ladung dampfenden Schweinekots vor die Haustür kippen würde.
Wenn Du von einer Windows-Maschine aus schreibst, schalte bitte die schwachsinnigen "Smart Quotes" ab. Damit vermeidest Du es, unsinnige und nutzlose Zeichen über die ganzen Mail zu verteilen.
Wenn Du einen grafischen Mail-Client verwendest (wie Netscape Messenger, MS Outlook, oder dergleichen), sei gewarnt, dass viele in ihren Standardeinstellungen diese Regeln missachten. Die meisten dieser Programme ermöglichen es, den tatsächlich gesendeten Text anzusehen (View Source). Verwende diese Option an einer gesendeten Nachricht, um Dich zu vergewissern, dass Du reinen Text ohne unnützen Dreck versendest.
Beschreibe die Symptome Deines Fehlers oder Problems sorgfältig und klar.
Beschreibe die Umgebung, in der es auftaucht (Maschine, Betriebssystem, Applikation, was auch immer). Nenne auch die verwendete Distribution mit Versionsnummer (z.B. "Red Hat 8.0", "Slackware 5.1", etc.).
Beschreibe, welche Versuche Du unternommen hast, um das Problem zu verstehen, bevor Du gefragt hast.
Beschreibe, welche Versuche Du unternommen hast, das Problem zu lösen, bevor Du gefragt hast.
Beschreibe die letzten Änderungen an Deinem Computer oder Deinen Softwareeinstellungen, die Dir relevant erscheinen.
Versuche, den Fragen eines Hackers zuvorzukommen und beantworte sie schon in Deiner Mail, zusammen mit der Bitte um Hilfe.
Simon Tatham hat ein ausgezeichnetes Essay mit dem Titel How to Report Bugs Effectively geschrieben. (Eine deutsche Übersetzung gibt es auf http://www.chiark.greenend.org.uk/~sgtatham/bugs-de.html, Anm.d.Ü.) Ich empfehle Dir wärmstens, es zu lesen.
Du musst präzise und informativ sein. Uns ist nicht mit großen Mengen an Code oder Daten gedient. Wenn Du einen großen, komplizierten Testfall hast, der einem Programm Probleme bereitet, versuche ihn zu optimieren und so klein wie möglich zu machen.
Das ist aus mindestens drei Gründen nützlich. Erstens: Wenn Du zeigst, dass Du Dir Mühe und Gedanken machst, das Problem zu vereinfachen, erhöhst Du die Chance auf eine Antwort. Zweitens: Die Frage zu vereinfachen macht es wahrscheinlicher, eine hilfreiche Antwort zu bekommen. Drittens: Beim Prozess der Umformung des Problems könntest Du selbst einen Fix oder ein Workaround schreiben.
Triffst Du bei einem Software-Teil auf Probleme, dann behaupte nicht sofort, Du hättest einen Fehler gefunden, bevor Du Deiner Sache nicht sehr, sehr sicher bist. Hinweis: Du bist Dir wahrscheinlich dann nicht hinreichend sicher, wenn Du keinen Patch, der das Problem behebt, oder alternativ dazu einen Regressionstest, der das inkorrekte Verhalten belegt, vorweisen kannst.
Denke daran, dass es eine Menge anderer Benutzer gibt, bei denen das Problem nicht auftritt. Andernfalls hättest Du etwas darüber in der Dokumentation gelesen, oder etwas darüber im Web gefunden. (Du hast natürlich die entsprechenden Dokumentation gelesen und im Web gesucht, bevor du gefragt hast, oder?) Das bedeutet wahrscheinlich, dass Du die Software falsch verwendest, und nicht, dass das Programm defekt ist.
Die Leute, welche die Software schreiben, arbeiten sehr hart dran, sie so gut wie nur möglich zu machen. Wenn Du behauptest, Du hättest einen Fehler gefunden, implizierts Du damit, sie hätten einen Bug produziert, und Du wirst sie damit fast immer beleidigen -- auch wenn Du mit Deiner Vermutung richtig liegst. Es ist sehr undiplomatisch, in der Betreffszeile von "Fehlern" zu brüllen.
Wenn Du Deine Frage stellst, ist es am besten, Du formulierst sie in der Annahme, Du hättest einen Fehler gemacht, auch wenn Du absolut sicher bist, einen Bug gefunden zu haben. Wenn ein Softwarefehler vorliegt, wirst Du in der Antwortmail darüber hören. Betrachte es so, dass die Entwickler sich bei Dir entschuldigen, wenn Du wirklich auf einen Fehler gestoßen bist, anstatt dass Du Dich beim Programmierer für eine unwahre Behauptung entschuldigen musst.
Einige Leute, die verstanden haben, dass sie sich nicht unfreundlich oder arrogant benehmen sollen, wenn sie um Hilfe bitten, wählen das Gegenteil, nämlich extreme Selbsterniedrigung. "Ich weiss, ich bin nur ein lächerlicher kleiner Newbie Loser, aber...". Das wirkt ablenkend und ist nicht hilfreich. Es ist besonders lästig, wenn es zusammen mit Ungenauigkeit über das eigentliche Problem auftritt.
Verschwende unsere und Deine Zeit nicht mit plumper Höflichkeit. Beschreibe dagegen die Tatsachen und Begleitumstände deines Problems, und formuliere Deine Frage so klar wie Du nur kannst. Das ist eine bessere Art, Dich zu präsentieren, als es Erniedrigung je sein kann.
Es ist nicht hilfreich, Hackern zu sagen, was Du als Ursache Deines Problems vermutest. (Wenn Deine diagnostischen Theorien so toll wären, würdest Du dann andere zu Rate ziehen?) Also erzähle ihnen lieber die reinen Symptome, und nicht Deine Interpretationen und Theorien. Lass die Helfenden die Diagnose stellen.
Ich bekomme ständig einen SIG11 Fehler beim Compilieren des Kernels, und vermute einen Haar-Riss bei einer Leiterbahn auf dem Motherboard. Wie kann ich die am besten finden?
Mein selbst zusammengebauter K6/233 auf einem FIC-PA2007 Motherboard (VIA Apollo VP2 Chipsatz) mit 256MB Corsair PC133 SDRAM bekommt wiederholte SIG11 Fehlermeldungen nach ca. 20 minütiger Einschaltzeit während des Kernelcompilierens, aber niemals während der ersten 20 Minuten. Ein Reboot verschafft mir diese zwanzigminütige Fehlerfreiheit nicht, lediglich das Ausschalten über Nacht hilft. Ein Austauschen des RAMs hat nichts gebracht. Der relevante Teil eines typischen Compilier-logs sieht so aus:
Manchmal liegen die hilfreichen Indizien in den Ereignissen unmittelbar vor dem Auftreten des Problems. Also sollte Deine Beschreibung genau alles das beinhalten, was Du tatest, und was die Maschine tat, als es zum Fehler kam. Bei Kommandozeilenprogrammen ist es hilfreich, ein Log der Sitzung (mit dem Utility script erstellt) zu haben, das in etwa die letzten 20 Zeilen vor dem Fehler beinhaltet.
Wenn das Programm Diagnose-Optionen (wie -v für verbose, geschwätzig) hat, denke darüber nach, welche zusätzlichen Debug-Informationen hilfreich für eine Fehlersuche sind.
Ist Deine Beschreibung lang (mehr als 4 Absätze), kann es hilfreich sein, kurz das Problem am Beginn der Mail zu umschreiben, und danach die ganze Geschichte in zeitlicher Abfolge zu erzählen. Dadurch weiss der Hacker schon im Voraus, worauf er in der Beschreibung achten muss.
Wenn Du herausfinden willst, wie Du etwas bewerkstelligen kannst (und nicht etwa einen Bug melden willst), beginne damit, Dein Ziel zu beschreiben. Erst danach solltest Du den Schritt, der Dich aufhält, beschreiben.
Oft passiert es, dass Leute, die ein bestimmtes Ziel vor Augen haben, einen bestimmten Weg einschlagen, von dem sie glauben, er führe zum Ziel, um dann mitten darin stecken zu bleiben. Sie fragen um Hilfe für einen bestimmten Schritt, ohne zu bemerken, dass der gewählte Pfad falsch ist. Es kann viel Mühe kosten, dann doch noch zum Ziel zu gelangen.
Wie bringe ich den Farb-Wähler des FooDraw Zeichenprogramms dazu, einen hexadezimalen RGB-Wert anzunehmen?
Ich versuche, die Farbpalette eines Bildes mit anderen Werten zu besetzen. Bis jetzt habe ich dazu jeden Tabelleneintrag verändert, aber ich kann FooDraws Farb-Wähler nicht dazu bringen, einen hexadezimalen RGB-Wert anzunehmen.
Die zweite Version der Frage ist schlauer, denn sie ermöglicht es, ein besseres Werkzeug für diese Arbeit vorzuschlagen.
Hacker glauben, dass das Lösen von Problemen ein öffentlicher, transparenter Prozess sein sollte, während dessen ein erster Versuch einer Antwort korrigiert werden kann und sollte, wenn jemand mit genaueren Kenntnissen bemerkt, dass er unvollständig oder fehlerhaft ist. Zudem ziehen sie einen Teil ihrer Belohnung für die Tätigkeit als Antworter aus der Tatsache, sich vor ihren Kollegen als kompetent und kenntnisreich zeigen zu können.
Wenn Du um eine private Antwort bittest, zerstörst Du sowohl den Prozess als auch die Belohnung. Tu das nicht. Es ist die Entscheidung des Antwortenden, ob er privat antwortet – und wenn er das tut, dann üblicherweise, weil er die Frage als zu schlecht gestellt oder zu offensichtlich einschätzt, um für andere interessant zu sein.
Es gibt eine bestimmte Ausnahme dieser Regel: Wenn Du denkst, auf die Frage wahrscheinlich eine große Anzahl gleich lautender Antworten zu erhalten, dann sind die magischen Worte: "Mailt mir und ich werde die Antwort für die Gruppe zusammenfassen". Es ist gutes Benehmen, die Mailingliste oder Newsgroup vor einer Flut inhaltlich identischer Beiträge zu bewahren – Du musst Dein Versprechen der Zusammenfassung aber auch halten.
Nicht klar abgegrenzte Fragen werden als (zeitlich) nicht abgegrenzte Zeitverschwendung aufgefasst. Die Personen, die Dir am ehesten eine hilfreiche Antwort geben könnten, sind meistens auch sehr beschäftigt (und sei es nur, weil sie sich die meiste Arbeit aufhalsen lassen). Solche Leute reagieren allergisch auf nicht abgegrenzte Zeitverschwendung und deshalb auch auf nicht abgegrenzte Fragen.
Du wirst eher eine hilfreiche Antwort bekommen, wenn Du genau sagst, was Du als Antwort erwartest (gebt mir Starthilfen, schickt Code, kontrolliert euren Patch, was auch immer). Das wird ihre Aufmerksamkeit bündeln und implizit eine Obergrenze der Zeit setzen, in der man damit beschäftigt ist, Dir zu helfen. Das ist gut.
Um die Welt, in der Experten leben, zu verstehen, stelle Dir Expertenmeinung als eine üppig vorhandene Ressource und Zeit zum Antworten als knappe Ressource vor. Je weniger Zeitaufwand Du implizit verlangst, desto wahrscheinlicher wird Dir von einem wirklich guten und beschäftigten Experten geholfen.
Es ist also sinnvoll, die Frage einzugrenzen, um den Zeitaufwand für die Antwort eines Experten möglichst gering zu halten – das ist oft nicht gleichbedeutend mit Vereinfachung der Frage. So ist die Frage "Kann mir jemand einen Verweis auf gute Dokumentation zu X geben?" geschickter als "Kann mir bitte jemand X erklären?". Hast Du fehlerhaften Code, ist es üblicherweise klüger zu fragen, ob Dir jemand den Fehler erklären kann als um eine fehlerbereinigte Version zu bitten.
Hacker kennen Hausaufgaben sehr gut; die meisten von uns haben selber welche gemacht. Diese Aufgaben sind aber für Dich gedacht, damit Du damit arbeitest und daraus lernst. Es geht in Ordnung, nach kleinen Hilfen zu fragen, aber nicht nach ganzen Lösungen.
Widerstehe der Versuchung, mit inhaltslosen Fragen wie "Kann mir jemand helfen?" oder "Gibt es eine Antwort darauf?" zu schließen. Erstens: Wenn Du Deine Frage halbwegs kompetent gestellt hast, sind solche angehängte Floskeln allerhöchstens überflüssig. Zweitens: Weil sie überflüssig sind, werden sie als störend empfunden, und Hacker neigen dazu, logisch unantastbare, aber wenig hilfreiche Antworten zu schicken wie "Ja, jemand kann Dir helfen" oder "Nein, Dir ist nicht mehr zu helfen".
Allgemein sind Ja-oder-nein-Fragen zu vermeiden, außer Du willst eine Ja-oder-nein-Antwort.
Das ist Dein Problem, nicht unseres. Dringlichkeit anzumelden ist eher kontraproduktiv: Viele Hacker werden die Mitteilung als frechen und selbstsüchtigen Versuch, sofortige und besondere Aufmerksamkeit zu erheischen, löschen.
Es gibt eine halbe Ausnahme zu dieser Regel: Es kann hilfreich sein, es anzumerken, wenn Du das Programm in einem hoch-technischen oder wichtigen Bereich verwendest, welcher aufregend für Hacker ist. Wenn das der Fall ist, und Du unter Zeitdruck stehst, und es freundlich sagst, könnten Leute interessiert genug sein, um Dir schneller zu antworten.
Das ist aber ein riskanter Schachzug, weil Dein Maßstab, was aufregend ist und was nicht, möglicherweise von dem eines Hackers verschieden ist. Die Tatsache, dass Du von der internationalen Raumstation aus schreibst, könnte zum Beispiel genügen, aber ein Posting für eine caritative oder politsche Einrichtung wird wahrscheinlich nicht als so wichtig empfunden. Ein Posting wie "Wichtig! Helft mir, die kleinen flauschigen Seehunde-Babies zu retten" wird wahrscheinlich ignoriert oder geflamed werden, sogar von Hackern, denen kleine flauschige Seehunde-Babies wichtig sind.
Wenn Du das unverständlich findest, lies den Rest dieses Textes noch einmal duch, solange, bis Du es verstanden hast, bevor Du irgend etwas postest.
Sei höflich. Verwende "Bitte" und "Danke für Eure Aufmerksamkeit" oder "Danke für die Mühe". Zeige, dass Du die Zeit schätzt, die andere damit verbringen, Dir unentgeltlich zu helfen.
Um ehrlich zu sein, ist Höflichkeit nicht so wichtig wie (und auf keinen Fall Ersatz für) grammatikalische Korrektheit, Klarheit, Genauigkeit und inhaltliche Vollständigkeit, Fehlen von proprietären Formaten usw.; Hacker honorieren im Allgemeinen eher kurz angebundene, aber technisch korrekte Bug Reports als höfliche Verschwommenheit. (Wenn Dich das wundert, denke daran, dass wir eine Frage nach ihrem Lerneffekt beurteilen.)
In jedem Fall, wenn Du Deine Hausaufgaben in technischer Hinsicht gemacht hast, erhöht Höflichkeit die Wahrscheinlichkeit einer Antwort.
(Es sei angemerkt, dass sich der einzige ernsthafte Einwand von Hackerveteranen zu dieser HOWTO auf die Empfehlung bezieht, "Danke im Voraus" zu verwenden. Manche Hacker empfinden dies als Ankündigung, dass kein Dank nach der Antwort zu erwarten ist. Die Empfehlung ist, Dich davor und danach zu bedanken, oder eine andere Höflichkeitsformel zu verwenden, wie etwa "Vielen Dank für Eure Bemühungen".)
Sende eine kleine Anmerkung an alle, die Dir geholfen haben; lass sie wissen, wie Du die Lösung gefunden hast und bedanke Dich nochmals für ihre Hilfe. Wenn ein Problem öffentliches Interesse z.B. in einer Mailing-Liste oder einer Newsgroup erregt hat, poste dort.
Am besten sollte sie im Diskussionsfaden erfolgen, den die Frage angestoßen hat, und sollte 'FIXED' oder 'GELÖST' oder ein ähnlich aussagekräftiges Wort in der Betreffzeile enthalten. In hoch frequentierten Mailing-Listen kann ein potentieller Antworter einen Thread, der mit "GELÖST" endet, auslassen, ohne Zeit zu verlieren (es sei denn, er/sie findet das Problem X interessant) und kann stattdessen die Zeit verwenden, ein anderes Problem zu lösen.
Deine Mitteilung muss nicht lang und ausführlich sein; ein einfaches "Hallo - es war ein kaputtes Netzkabel! Danke an alle - Bill" ist besser als nichts. Tatsächlich ist eine kurze und nette Zusammenfassung besser als eine lange Dissertation, es sei denn, sie hat ausreichend technischen Gehalt. Sage, welche Aktion geholfen hat, ohne die gesamte Fehlersuche zu wiederholen.
Für Probleme mit einiger Tiefe ist es angebracht, eine Zusammenfassung des Lösungsvorganges zu posten. Beschreibe die Fehlerursache und deren Symptome. Gib eine Lösung an und zeige eventuelle Sackgassen auf. Nenne die Namen derer, die Dir halfen; Du machst Dir auf diese Art Freunde.
Neben Höflichkeit und Information hilft dieses Antwortschreiben anderen, die das Archiv der Mailing-Liste/Newsgroup oder des Forums durchsuchen, die Lösung zu finden. Du kannst ihnen viel Mühe ersparen.
Des weiteren gibt diese Art von Antwortschreiben den Helfern ein befriedigendes Gefühl, dass das Problem abgeschlossen ist. Wenn Du selber kein Technikfreak oder Hacker bist, glaub uns, dass das ein sehr wichtiges Gefühl für die Experten und Gurus ist, die Du um Hilfe gebeten hast. Probleme, die in ein ungelöstes Nichts aufgehen, sind frustrierend; Hacker juckt es in den Fingern, sie gelöst zu wissen. Das gute Karma, das Du dadurch erhältst, wird Dir sehr sehr hilfreich sein, wenn Du das nächste mal um Hilfe bittest.
Überlege, wie Du das Problem in Zukunft anderen ersparen kannst. Frage nach, ob eine Dokumentation oder eine Änderung der FAQ hilfreich wäre, und wenn Du eine positive Antwort bekommst, schicke diese Änderung an die zuständige Stelle.
Unter Hackern ist solches Benehmen viel wichtiger als konventionelle Freundlichkeit. Die Reputation, gut mit anderen zusammen zu spielen, kann sich als sehr wichtige Eigenschaft erweisen.
Es gibt eine alte und ehrwürdige Tradition: Wenn Du eine Antwort bekommst, die sich wie "RTFM" liest, glaubt der Antwortende, Du solltest das verdammte Handbuch lesen (Read The Fucking Manual). Er hat allerhöchstwahrscheinlich recht. Lies es.
RTFM hat einen jüngeren Verwandten. Wenn Du eine Antwort bekommst, die sich wie "STFW" liest, meint er, Du solltest das verdammte Web danach absuchen (Search The Fucking Web). Er hat allerhöchstwahrscheinlich recht. Such danach.
Oft hat die Person, die eine dieser Antworten gibt, das Handbuch oder eine Webseite mit den gesuchten Informationen während des Tippens vor sich liegen. Eine solche Antwort bedeutet, dass (a) die gesuchte Information einfach zu finden ist, und (b) Du mehr lernen wirst, wenn Du sie Dir selber suchst, anstatt sie Dir bequem einlöffeln zu lassen.
Du solltest Dich dadurch nicht angegriffen fühlen; auf Hackerart wird Dir in ungeschliffener Weise einfach schon dadurch Respekt gezeigt, dass Du nicht völlig ignoriert wirst. Du solltest stattdessen für solche großmütterliche Güte dankbar sein.
Wenn Du eine Antwort nicht verstehst, schick nicht sofort eine Rückantwort, mit einer Bitte um Klärung. Verwende die gleichen Quellen, die Du zur Lösung Deines Problems herangezogen hast (Handbücher, FAQs, das Web, erfahrene Freunde) um die Antwort zu verstehen. Danach, solltest Du immer noch Hilfe brauchen, zeige in Deiner Frage, was Du gelernt hast.
Nimm an, es wird dir gesagt: "Es schaut nach einem festgefahrenen Zentry (das Beispiel verwendet absichtlich ein Wort, das gar keine Bedeutung hat, um das 'Nachhaken' zu provozieren, Anm.d.Übers.) aus. Den musst Du wieder lösen." Dann:
Hier ist eine schlechte Frage: "Was ist ein Zentry?"
Hier ist eine gute Frage: "Ich habe die manpage gelesen und Zentries werden nur bei den Optionen -z und -p erwähnt. Aber keine erklärt, wie man Zentries löst. Ist eine der beiden Optionen das, was ich brauche oder habe ich etwas übersehen?"
Vieles, das wie Grobheit aussieht, ist in Hacker-Kreisen nicht als Beleidigung gedacht. Es ist im Gegenteil das Produkt einer direkten Art der Kommunikation ohne Umschweife, die Personen zu eigen ist, die mehr daran interessiert sind, Probleme zu lösen, als andere sich liebgehabt und geborgen fühlen zu lassen.
Wenn Dir rohes Verhalten entgegengebracht wird, reagiere gelassen. Wenn jemand wirklich übertreibt, wird ihn sehr wahrscheinlich ein alter Hase in der Gruppe zurechtweisen. Wenn das nicht passiert und Du deine Beherrschung verlierst, hat die betreffende Person sich wahrscheinlich an die in der Gruppe herrschenden Regeln gehalten, und Du Dich falsch benommen. Das wird Deine Chance auf kompetente Hilfe verringern.
Auf der anderen Seite wirst Du gelegentlich auf sinnlose oder ungerechtfertigte Rüpelhaftigkeit stoßen. Die andere Seite des oben Gesagten ist, dass es akzeptiertes Verhalten ist, wirklich ausfallende Personen hart zurecht zu weisen und deren falsches Benehmen mit scharfem Messer verbal zu sezieren. Sei Dir Deines Grundes deshalb sehr sehr sicher, bevor Du so etwas tust. Der Grat zwischen dem Korrigieren eines Missgriffs und dem Lostreten eines endlosen Flamewars ist schmal genug, dass selbst Hacker ihn gelegentlich übertreten; wenn Du ein Neuling oder eine Außenseiter bist, stehen die Chancen schlecht, eine solche Übertretung zu vermeiden. Wenn Du mehr auf Unterhaltung als auf Informationen aus bist, ist es besser, Du lässt die Finger von der Tastatur, als das zu riskieren.
(Manche Leute behaupten, dass viele Hacker an einer schwachen Form von Autismus oder des Aspergerschen Syndroms leiden, und einige der Hirnwindungen vermissen, welche die 'normalen' zwischenmenschlichen Beziehungen steuern. Das mag stimmen oder auch nicht. Wenn Du selber kein Hacker bist, kann es Dir helfen, unsere Exzentrizitäten als die von geistig Gestörten anzusehen. Sieh darüber hinweg. Uns macht das nichts aus; uns gefällt die Art, wie wir sind, und normalerweise haben wir ein gesundes Misstrauen klinischen Bezeichnungen gegenüber.)
Im nächsten Abschnitt werden wir über ein anderes Thema sprechen; die verschiedenen Arten von 'Grobheit', die Dir entgegengebracht werden, wenn Du dich falsch verhältst.
Gelegentlich wirst Du Dich in einem Forum einer Hackergemeinschaft falsch benehmen – in einer hier beschriebenen oder ähnlichen Art. Und Dir wird genauestens gesagt werden, wo Du Dich falsch benommen hast, möglicherweise gespickt mit derben Bemerkungen. Öffentlich.
Wenn das passiert, ist das Schlimmste, was Du tun kannst, über diese Erfahrung zu heulen, behaupten, verbal angegriffen worden zu sein, Entschuldigungen zu fordern, schreien, Deinen Atem anhalten, Strafanzeigen androhen, bei Arbeitgebern anschwärzen, die Klobrille nicht herunter klappen usw. Du wirst Dich hingegen besser folgendermaßen benehmen:
Sieh darüber hinweg. Es ist normal. Ausserdem ist es gesund und angemessen.
Gemeinschaftliche Regeln erhalten sich nicht von alleine: Sie werden von Leuten am Leben gehalten, die sie aktiv anwenden, öffentlich. Weine nicht darüber, dass jede Kritik über private Mail verschickt werden sollte: So wird das nicht gehandhabt. Auch ist es wenig hilfreich zu behaupten, Du seist persönlich beleidigt worden, wenn jemand Deine Behauptungen als falsch darstellt oder auf anderen Standpunkten steht. Das sind Loserattitüden.
Es hat Hackerforen gegeben, in denen aus übertriebener Freundlichkeit Beiträge, die auf Fehler anderer Teilnehmer aufmerksam gemacht haben, unerwünscht waren und mit einem "Sag nichts, wenn Du nicht helfen willst!" beantwortet wurden. Durch das darauf folgende Abwandern erfahrener Teilnehmer sind diese Foren in inhaltsloses Geplapper abgerutscht und als technische Gruppen nutzlos geworden.
Übertrieben "freundlich" (in diesem Sinn) oder nützlich: Wähle eines davon.
Nota Bene: Wenn ein Hacker Dir sagt, Du hättest Dich falsch benommen, und Dir (ganz egal wie grob) sagt, es nicht wieder zu tun, tut er es erstens Dir und zweitens seiner Gemeinschaft zu liebe. Es wäre für ihn viel leichter, Dich zu ignorieren und aus seinem Leben herauszufiltern. Wenn Du es nicht schaffst, dankbar zu sein, behalte wenigstens ein wenig Würde; heul nicht 'rum und erwarte auch nicht, wie eine zerbrechliche kleine Puppe behandelt zu werden, nur weil Du ein Neuling mit einer theatralisch überempfindlichen Seele und zu hohen Ansprüchen bist.
Hier sind einige klassische und dumme Fragen aufgeführt, und was sich Hacker denken, wenn sie sie nicht beantworten.
| F: | Wo kann ich Programm oder Ressource X finden? |
| A: | Am gleichen Ort, wo ich es gefunden habe, Dummkopf – auf der anderen Seite einer Web-Suche. Mein Gott, gibt es immer noch jemanden, der nicht weiß, wie man googelt? |
| F: | Wie kann ich X verwenden, um Y zu tun? |
| A: | Was Du willst, ist Y tun, also solltest Du diese Frage stellen, ohne verfrühte Annahmen über eine bestimmte Methode zu treffen. Fragen dieser Art kennzeichnen oft Menschen, die zwar nicht vollständig unwissend über X sind, aber sich nicht im Klaren darüber sind, was für ein Problem Y sie lösen sollen und zu sehr auf Details fixiert sind. Es ist im Allgemeinen am besten, solche Personen solange zu ignorieren, bis sie ihr Problem besser definieren. |
| F: | Wie kann ich meinen Shell Prompt ändern? |
| A: | Wenn Du schlau genug bist, diese Frage zu stellen, dann bist Du auch schlau genug, RTFM zu betreiben und es selber herauszufinden. |
| F: | Kann ich ein AcmeCorp Dokument mit dem Bass-o-matic File Converter im TeX-Format abspeichern? |
| A: | Probiere es und Du wirst es wissen. Wenn Du das getan hättest, hättest Du (a) die Antwort gefunden und (b) nicht meine Zeit verschwendet. |
| F: | Mein {Programm, Konfiguration, SQL Statement} geht nicht. |
| A: | Das ist keine Frage und ich bin nicht bereit, zwanzig Minuten damit zu verbringen, die Frage aus Dir heraus zu kitzeln – ich habe Besseres zu tun. Wenn ich so etwas sehe, ist meine Reaktion eine der folgenden:
|
| F: | Ich habe Probleme mit meiner Windows-Maschine. Kann mir jemand helfen? |
| A: | Ja. Wirf diesen Microsoft-Müll aus dem Fenster und installiere ein Open Source-Betriebssystem wie beispielsweise Linux oder BSD. |
| F: | Mein Programm geht nicht. Ich denke, die Systemeinheit X ist kaputt. |
| A: | Obwohl es möglich ist, dass Du der einzige bist, der einen augenfälligen Fehler in Systemroutinen gefunden hat, die von hunderten oder tausenden von Leuten verwendet werden, ist es wahrscheinlicher, dass Du daran etwas nicht verstanden hast. Besondere Aussagen brauchen besondere Beweise; wenn Du eine solche Aussage tätigst, musst Du sie mit einer ausführlichen Dokumentation des Fehlerfalls belegen. |
| F: | Ich habe Probleme bei der Installation von Linux oder X. Kann jemand helfen? |
| A: | Nein. Es braucht physikalischen Zugriff auf die Maschine, um das zu bewerkstelligen. Frag Deine Lokale Linux User Group. (Du kannst eine Liste der User Groups hier finden.) |
| F: | Wie kann ich Channel Operatoren-Rechte stehlen/cracken, jemandes eMail lesen? |
| A: | Du hast wenig Ehrgefühl, so etwas tun zu wollen, und bist schwachsinnig, einen Hacker zu bitten, Dir dabei auch noch zu helfen. |
Zum Schluss werde ich einige Beispiele anführen, wie man Fragen auf eine intelligente Weise stellt; paarweise werden Fragen zu einem gleichen Problem gestellt, einmal auf eine dumme, einmal auf eine schlaue Art.
Diese Frage schreit förmlich nach einem "STFW" als Antwort.
Hier wurde schon ge'STFW't, und es schaut so aus, als ob ein wirkliches Problem existieren würde.
Er nimmt an, dass jemand anderes Mist gebaut hat. Arrogant von ihm.
Er hat die Umgebung angegeben, die FAQ gelesen, er zeigt den Fehler und er nimmt nicht an, dass andere den Fehler verschuldet hätten. Dieser Typ kann ein wenig Aufmerksamkeit verdienen.
J. Random Hackers Antwort darauf kann sein: "Sicher. Musst Du auch ein Bäuerchen machen oder sollen die Windeln gewechselt werden?", gefolgt von einem beherzten Druck auf die Delete-Taste.
Diese Person scheint dagegen einer Antwort wert zu sein. Sie zeigte Intelligenz zur Problemlösung, anstatt passiv auf Hilfe von oben zu warten.
Beachte in der letzten Frage den subtilen Unterschied zwischen den Fragen "Gib mir eine Antwort" und "Bitte helft mir, zusätzliche Tests auszudenken, um Erleuchtung zu finden".
Tatsächlich ist die Form der letzten Frage einem wirklichen Fall entnommen, der sich im August 2001 in der Linux Kernel-Mailingliste (lkml) ereignete. Ich (Eric) war derjenige, der damals um Hilfe bat. Ich erlebte mysteriöse Hänger mit meinem Tyan S2462 Motherboard. Die Listenteilnehmer gaben mir die notwendigen Informationen, die ich brauchte.
In der Art, wie ich die Frage stellte, gab ich anderen die Möglichkeit, daran zu kauen; ich machte es ihnen leicht und attraktiv, sich damit zu beschäftigen. Ich zollte meinen Gegenübern Respekt und lud sie ein, mich als Gleichen zu behandeln. Ich zeigte auch, dass ich ihre Zeit respektiere, indem ich fruchtlose Versuche angab, die ich schon ausprobiert hatte.
Nachher, als ich allen dankte und anmerkte, wie gut die Lösung funktionierte, bemerkte ein lkml-Mitglied, mein Posting sei deshalb gut angekommen, nicht weil ich einen "Namen" auf der Liste hatte, sondern weil ich die Frage in der richtigen Form gestellt hatte.
Hacker bilden in einer bestimmten Hinsicht eine sehr leistungsorientierte Gemeinschaft; ich bin sicher, er hatte recht und ich wäre, wenn ich mich wie ein Depp verhalten hätte, ignoriert und geflamed worden, ganz gleich, welche Stellung ich einnahm. Seine Anregung, den gesamten Vorfall als Beispiel für andere aufzuschreiben, hat direkt zu der Veröffentlichung dieses Textes geführt.
Wenn Du keine Antwort bekommen kannst, nimm es bitte nicht persönlich, dass wir uns nicht in der Lage fühlen, Dir zu helfen. Manchmal wissen die Teilnehmer einer Gruppe ganz einfach die Antwort nicht. Keine Antwort ist nicht das gleiche wie ignoriert zu werden, auch wenn es von außen schwierig ist, das zu unterscheiden.
Im Allgemeinen ist ein einfaches Wiederposten eine schlechte Idee. Das wird als zwecklose Belästigung angesehen.
Es gibt andere Quellen, deren Du Dich bedienen kannst; oft sind sie den Anforderungen von Neulingen besser angepasst.
Es gibt viele lokale User Groups oder welche im Web, die die Programme, die wir schreiben, gut finden, auch wenn sie nie im Leben Software geschrieben haben. Diese Gruppen sind oft gebildet worden, um sich untereinander und Einsteigern zu helfen.
Es gibt auch massenweise große und kleine kommerzielle Firmen, die Du um Hilfestellung kontaktieren kannst (Red Hat und Linuxcare sind die zwei bekanntesten; es gibt viele andere). Lass Dich nicht von der Idee abschrecken, ein wenig für die erhaltene Hilfe zu zahlen! Wenn Dein Automotor den Geist aufgibt, wirst Du auch zu einem Mechaniker gehen und ihn für die Reparatur bezahlen. Auch wenn die Software an sich nichts kostet, darfst Du nicht erwarten, dass auch die Kundenbetreuung dafür immer kostenlos sei.
Für populäre Software wie Linux kommen etwa 10.000 Benutzer auf einen Entwickler. Es ist für eine Person einfach nicht möglich, den Rufen von 10.000 Benutzern nachzukommen. Bedenke, dass Du selbst bei zahlungspflichtiger Hilfe viel weniger bezahlen musst, als wenn Du die Software kaufen müsstest (und Kundenbetreuung für kommerzielle Produkte ist in der Regel teurer und weniger kompetent als die für Open Source-Projekte).
Sei freundlich. Problembezogener Stress kann Leute grob oder dumm aussehen lassen, auch wenn sie es nicht sind.
Wenn Du die Antwort nicht sicher weißt, sag das! Eine falsche aber kompetent klingende Antwort ist schlechter als gar keine. Weise niemandem einen falschen Weg, nur weil es lustig ist, sich wie ein Experte anzuhören. Sei bescheiden und ehrlich; sei ein gutes Beispiel für Fragende und für Deine Kollegen.
Wenn Du nicht helfen kannst, behindere niemanden. Erlaube Dir keine Späße, die die Einstellungen des Fragenden durcheinander bringen könnten – der arme Tropf könnte sie als Anleitung verstehen.
Stelle Fragen, um mehr Details herauszufinden. Wenn Du gut darin bist, kann der Fragende etwas lernen, und Du nebenbei auch. Versuche, die schlechte Frage in eine gute zu verwandeln. Denke daran, das wir alle einmal Anfänger waren.
Einfach RTFM zu brummeln ist manchmal bei einem faulen Taugenichts gerechtfertigt, ein Fingerzeig auf die richtige Dokumentation (sei es auch nur der Vorschlag guter Stichworte für Google) ist besser.
Beantwortest Du eine Frage vollständig, dann beantworte sie gut. Schlage keine wackligen Workarounds vor, wenn jemand eine falsche Methode oder ein unangemessenes Tool vorgeschlagen hat. Schlage gute Programme vor. Formuliere die Frage neu.
Hilf der Gemeinschaft, aus der Frage zu lernen. Wenn Du auf eine gute Frage triffst, frage dich "Wie müsste die betreffende FAQ oder Dokumentation geändert werden, damit niemand mehr diese Frage beantworten muss?" Dann schicke einen Verbesserungsvorschlag an den Zuständigen.
Wenn Du für eine Antwort nachforschen musstest, zeige Deine Fähigkeit zur Suche, anstatt so zu tun, als ob Du Dir die Antwort aus dem Ärmel geschüttelt hättest. Eine Frage zu beantworten ist wie einer hungrigen Person ein Essen zu geben; an Beispielen zu zeigen, wie man Informationen findet, heißt zu lehren, wie man ein Leben lang Essen produziert.
Wenn Du Informationen zu den Grundlagen suchst, wie Computer, Unix und das Internet funktionieren, siehe The Unix and Internet Fundamentals HOWTO.
Wenn Du Software freigibst oder Patches für Software schreibst, versuche den Richtlinien in Software Release Practice HOWTO zu folgen.
Viele Webseiten, Newsgroups und andere Online-Foren verlinken diesen Text als Hilfe für Newbies. Die Autoren freuen sich darüber. Aber: Bitte füge neben dem Link einen fett gedruckten Hinweis, dass wir kein Help-Desk für Dein Projekt sind. Wir bekommen zu viele Anfragen von Leuten, die das Gegenteil annehmen.
Evelyn Mitchell ergänzte einige dumme Fragen und inspirierte den Teil "Wie man gute Antworten gibt".