Jak mądrze zadawać pytania

Jak mądrze zadawać pytania

Treść tego dokumentu pochodzi ze strony http://rtfm.killfile.pl . Trzymam tutaj jej kopię, skonwertowaną na UTF8 oraz dopasowaną kolorystycznie do strony. Nie zmieniałem treści, całość pochodzi z roku 2004. Oryginalny dokument miał już sporo poprawek i znajduje się tutaj: http://www.catb.org/~esr/faqs/smart-questions.html Piotr Arłukowicz

Copyright 2001 by Eric S. Raymond
Copyright 2002, 2003, 2004 by Tomasz Dudzisz & Kaja Mikoszewska & Maciej Wierzbicki (polskie tłumaczenie)
Copyleft 🄯 Piotr Arłukowicz - konwersja na UTF8 i odświeżenie, poprawki literówek

Spis treści

Tłumaczenia

Oryginalny dokument angielskojęzyczny można znaleźć tutaj.

Dokument ten dostępny jest również w językach: duńskim, estońskim, francuskim, niemieckim, hebrajskim, węgierskim, rosyjskim oraz hiszpańskim. Jeżeli chcesz kopiować, rozpowszechniać, tłumaczyć bądź cytować ten dokument, przeczytaj moje zastrzeżenia.

Zastrzeżenie

Wiele stron WWW różnych projektów zawiera odnośnik do tego dokumentu. W porządku, właśnie po to powstał. Jednak jeżeli jesteś webmasterem, który zamieszcza taki odnośnik na stronie swojego projektu - umieść obok informację, że nie jesteśmy wsparciem technicznym Twojego projektu!

Okazuje się, że gdy zabraknie takiego zastrzeżenia, wielu idiotów sądzi, że publikując ten dokument, zobowiązaliśmy się do rozwiązywania wszystkich technicznych problemów świata.

Jeżeli czytasz ten dokument, ponieważ potrzebujesz pomocy i sądzisz, że możesz ją uzyskać bezpośrednio od jego autorów, jesteś właśnie jednym z tych idiotów. Nie zadawaj nam pytań - po prostu Cię zignorujemy. Chcieliśmy pokazać, w jaki sposób uzyskać pomoc od osób zajmujących się oprogramowaniem i sprzętem, z którym masz problem. Jednak w 99% przypadków to nie my będziemy tymi osobami. Dopóki nie będziesz absolutnie pewien, że jeden z autorów tego dokumentu jest ekspertem w tym, czego potrzebujesz, zostaw nas w spokoju. Wtedy wszyscy będą szczęśliwi.

Wstęp

W naszym świecie rodzaj odpowiedzi, którą otrzymasz na nurtujące Cię pytanie, zależy od sposobu, w jaki je postawisz. Ten dokument nauczy Cię, jak formułować pytania, aby otrzymać w pełni satysfakcjonującą odpowiedź.

Oprogramowanie open source jest już powszechnie dostępne. Możesz uzyskać pomoc z nim związaną od doświadczonych użytkowników, nie tylko od autorów. To dobra sprawa; użytkownicy są dużo łagodniejsi wobec początkujących. Poniższe rady przydadzą Ci się zarówno w porozumiewaniu się z autorami, jak i doświadczonymi użytkownikami.

Pierwszą rzeczą, jaką należy sobie uzmysłowić, jest to, że lubimy zawiłe problemy oraz dobre, zmuszające do zastanowienia pytania. Gdybyśmy nie mieli takiego podejścia, nie byłoby nas tutaj. Gdy dostarczysz nam interesujące zagadnienie do rozgryzienia, możesz liczyć na naszą wdzięczność; dobre pytania są bodźcem do działania, są jak miłe prezenty. Takie zadania pomagają nam rozwijać umiejętności i często odkrywać rzeczy, na które nie zwracaliśmy wcześniej uwagi lub myśleliśmy o nich inaczej. "Dobre pytanie!" - jest dla nas prawdziwym komplementem.

Często mówi się, że reagujemy niechętnie lub opryskliwie na proste pytania. Czasem może to wyglądać, jakbyśmy odruchowo oschle traktowali i ignorowali tych 'nowych'. W rzeczywistości tak nie jest.

Nie zamierzamy poświęcać naszego czasu na odpowiedzi ludziom niechętnym do samodzielnego myślenia - odróbcie więc swoją pracę domową, zanim zadacie jakiekolwiek pytanie. Tacy ludzie są pożeraczami naszego czasu - zabierają go nam bez opamiętania, marnują każdą chwilę, którą moglibyśmy poświęcić innemu, bardziej interesującemu zagadnieniu lub osobie, która bardziej zasługuje na naszą odpowiedź. Tych pierwszych nazywamy 'łajzami' ('losers', z historycznych względów wymawiane często jako 'lusers').

Zdajemy sobie sprawę, że wiele osób chce korzystać z naszego oprogramowania i nie wszystkich interesują techniczne detale. Dla większości ludzi komputer jest jedynie narzędziem - w dosłownym tego słowa znaczeniu; interesują się innymi rzeczami i żyją po swojemu. Rozumiemy to i akceptujemy - nie spodziewamy się, że każdego zafascynuje to samo, co nas. Jednakże nasz styl odpowiedzi przeznaczony jest dla tych, którzy nieco interesują się tematem i gotowi są aktywnie uczestniczyć w rozwiązywaniu problemu. To się nie zmieni. Nie powinno się zmienić - jeśli tak się stanie, staniemy się mniej efektywni w tym, co robimy najlepiej.

Jesteśmy (w większości) w pewnym sensie wolontariuszami. Poświęcamy nasz wolny czas, by odpowiadać na pytania, których liczba momentami wręcz nas przygniata. Więc musimy je ostro filtrować. W szczególności ignorujemy pytania ludzi, którzy wydają się być łajzami. Dzięki temu możemy efektywniej wykorzystać cenny czas na odpowiadanie ludziom, którzy na to zasługują.

Jeśli uważasz, że taka postawa jest wstrętna, poniżająca dla Ciebie bądź arogancka, zastanów się jeszcze raz. Nie błagamy każdego, żeby do nas dołączył - jednak większość z nas chętnie powita Cię w naszym gronie jako równego, jeśli tylko włożysz w to odpowiedni wysiłek. Próba pomocy ludziom, którzy nie są skorzy pomóc sami sobie, jest bezcelowa. Niewiedza jest zrozumiała i dopuszczalna, udawanie głupka - absolutnie nie.

Jak widać, o ile niekoniecznie trzeba być technicznie kompetentnym, aby przyciągnąć naszą uwagę, o tyle koniecznie trzeba prezentować podejście do kompetencji prowadzące - myślenie, skupienie, czujność oraz aktywne uczestnictwo w rozwiązywaniu problemów. Jeśli nie możesz pogodzić się z takim rodzajem "dyskryminacji", zatrudnij kogoś i płać mu za techniczne wsparcie, zamiast prosić nas o bezinteresowną pomoc.

Jeśli zdecydujesz się jednak zwrócić do nas po pomoc, na pewno nie chciałbyś wyjść na łajzę. Najlepszym sposobem, by otrzymać szybką odpowiedź, jest pytać jak człowiek inteligentny, pewny siebie, posiadający wiedzę, któremu po prostu zdarzyło się szukać pomocy z tym jednym, konkretnym problemem.

(Poprawki do tego przewodnika są mile widziane. Możesz przesłać swoje sugestie na adres esr@thyrsus.com. Pamiętaj jednak, że ten dokument nie miał być ogólnym przewodnikiem po netykiecie, a ja raczej odrzucam sugestie niezwiązane bezpośrednio z uzyskiwaniem użytecznych odpowiedzi na forum technicznym.)

Zanim zapytasz

Zanim wyślesz email z zapytaniem, zadasz pytanie na grupach dyskusyjnych czy też na innym forum, postaraj się znaleźć odpowiedź:

  1. przeszukując sieć,
  2. czytając dokumentację,
  3. studiując FAQ,
  4. eksperymentując,
  5. zadając pytanie doświadczonemu koledze,
  6. czytając kod źródłowy, jeżeli jesteś programistą.

Gdy będziesz zadawać pytanie, zaznacz, że zrobiłeś już wymienione powyżej rzeczy. Dzieki temu będziemy wiedzieć, że nie jesteś leniwy i nie marnujesz cudzego czasu. Jeszcze lepiej będzie, gdy przedstawisz, czego się dowiedziałeś dzięki "zaliczeniu" powyższych punktów. Lubimy pomagać ludziom, którzy pokazują, że potrafią się uczyć na pytaniach.

Próbuj znaleźć odpowiedź, używając wyszukiwarki Google do znalezienia fraz odpowiadających komunikatom o błędach, jakie dostałeś (i przeszukuj zarówno archiwa grup dyskusyjnych, jak i strony WWW). To może naprowadzić Cię na poprawki w dokumentacji bądź wątki na grupach dyskusyjnych, które przyniosą odpowiedź na Twoje pytanie. A nawet jeśli nie, to dodanie "przeszukałem sieć pod kątem wystąpienia tego komunikatu" do maila lub posta z prośbą o pomoc jest dobrym pomysłem.

Przygotuj pytanie. Przemyśl je. Im lepiej pokażesz, że włożyłeś wysiłek w próbę rozwiązania problemu zanim zapytałeś nas, tym większe będzie prawdopodobieństwo, że rzeczywiście uzyskasz pomoc.

Nie zadawaj złych pytań. Jeśli pytanie, które zadasz, będzie oparte na błędnym założeniu, ktoś z nas (prawdopodobnie myśląc: "Głupie pytanie...") odpowie Ci krótko i dosadnie, mając nadzieję, że nauczysz się czegoś, jeśli dostaniesz to, o co prosiłeś, a nie to, co było Ci naprawdę potrzebne.

Nigdy nie zakładaj, że należy Ci się odpowiedź. Nie należy się - w końcu nie płacisz za to. Otrzymasz odpowiedź, jeżeli na nią zasłużysz - gdy zadasz solidne, interesujące i zmuszające do myślenia pytanie. Takie, które może wzbogacić wiedzę ogółu, a nie takie, które jedynie wyciąga od innych informacje.

Bardzo dobrym początkiem będzie wykazanie chęci współpracy w procesie rozwiązywania problemu. Zadając pytania typu: "czy ktoś może dać mi jakąś wskazówkę", "czego tu brakuje" lub "czy jest jakaś strona, gdzie mógłbym to sprawdzić", masz większą szansę na odpowiedź, niż gdyby pytanie brzmiało: "Proszę o przesłanie dokładnej procedury". Daje to pewność, że dokończysz proces, jeśli tylko ktoś Cię odpowiednio nakieruje.

Gdy pytasz

Odpowiednio wybieraj swoje forum

Starannie wybierz miejsce swojego zapytania. Prawdopodobnie zostaniesz zignorowany lub uznany za łajzę, jeśli:

Zawsze odrzucamy pytania, które są źle sprecyzowane i niewłaściwie ukierunkowane. W ten sposób chronimy nasz kanał komunikacyjny przed rzeczami zupełnie niezwiązanymi z tematem. Raczej nie chciałbyś zostać zignorowany.

Pierwszą rzeczą, którą należy zrobić, jest znalezienie właściwego forum. I znowu - Google i inne metody przeszukiwania sieci to Twoi przyjaciele. Użyj ich do znalezienia strony WWW projektu najbliższego temu, z którym masz problemy. Zwykle na takiej stronie będą odnośniki do FAQ oraz do list dyskusyjnych projektu wraz z archiwami. Te listy dyskusyjne są właściwym miejscem do szukania pomocy, jeżeli poprzednie starania (włącznie z przeczytaniem FAQ) nie przyniosły rozwiązania.

Wysłanie maila do osoby lub na forum, z którym nie jesteś zaznajomiony, jest dość ryzykowne. Na przykład zakładanie, że autor informacyjnej strony WWW zechce być Twoim darmowym konsultantem, jest błędne. Nie zakładaj optymistycznie, że Twoje pytanie będzie mile widziane - jeżeli nie jesteś pewien, albo wyślij pytanie gdzie indziej, albo się po prostu powstrzymaj.

Podczas wybierania grupy dyskusyjnej nie sugeruj się wyłącznie jej nazwą. Zerknij do FAQ lub opisu, aby upewnić się, że Twoje pytania będą na miejscu. Przeczytaj kilka archiwalnych wątków, aby wyczuć, jaki klimat panuje na grupie, zanim poślesz swój artykuł. Bardzo dobrym pomysłem jest przeszukanie archiwów grup lub list dyskusyjnych pod kątem odpowiednich słów kluczowych, zanim wyślesz pytanie.

Musisz dokładnie wiedzieć, o co chcesz zapytać! Jedną z najczęstszych pomyłek jest zadawanie pytań dotyczących interfejsu programowania w systemach Unix bądź Windows na forach przeznaczonych do dyskutowania o języku programowania, bibliotece lub narzędziach dotyczących obu tych systemów. Jeżeli nie rozumiesz, dlaczego jest to poważny błąd, najlepiej powstrzymaj się z zadawaniem jakichkolwiek pytań do momentu, gdy stanie się to dla Ciebie jasne.

Generalnie pytania skierowane na właściwie obrane publiczne forum mają większą szansę na użyteczną odpowiedź. Istnieje wiele powodów takiego stanu rzeczy. Jednym z nich jest po prostu większa liczba potencjalnych odpowiedzi. Innym jest liczność tzw. publiczności; wolimy udzielać odpowiedzi, które przydadzą się wielu ludziom, a nie nielicznym.

Naturalnym jest, że my, a także autorzy popularnego oprogramowania, cały czas otrzymujemy więcej wiadomości - źle ukierunkowanych wiadomości - niż jesteśmy w stanie przetrawić. Dołączając do tego szumu informacyjnego, w ekstremalnych sytuacjach Twoja wiadomość może zostać tą, która przepełni czarę goryczy - niejednokrotnie zdarzyło się, że niektórzy z nas wycofywali swój wkład w popularne projekty z powodu zalewu bezużytecznych maili, doprowadzającego do sytuacji, w której korzystanie z własnej skrzynki pocztowej staje się nieznośne.

Najszybciej uzyskasz odpowiedź na kanałach IRC i forach WWW dla początkujących

Użytkownicy interesującego Cię systemu lub oprogramowania mogą polecać forum WWW lub kanał ircowy, na którym początkujący mogą szukać pomocy. (W krajach nieanglojęzycznych częściej są to listy e-mailowe.) Jeśli uważasz, że Twój problem jest względnie prosty lub dość powszechny, najlepiej zacząć od szukania właśnie tam. Na otwartym kanale na IRC możesz często otrzymać pomoc w czasie rzeczywistym.

Jeśli program, z którym masz kłopoty, pochodzi z jakiejś konkretnej dystrybucji, dobrze zapytać najpierw na forum/liście dystrybucyjnej, a dopiero potem na forum/liście projektu. [...]

Zanim zapytasz na jakimkolwiek forum, sprawdź, czy można je przeszukiwać. Jeśli tak, sprawdź słowa kluczowe dotyczące Twojego problemu; a nuż wystarczy. Zrób to, nawet jeśli wcześniej przeszukałeś sieć - niektóre strony forum mogły jeszcze nie zostać zaindeksowane.

Coraz częściej projekty organizują forum lub zakładają kanał na IRC poświęcone wsparciu dla użytkowników, rezerwując komunikację e-mailową dla developerów. [...]

W drugiej kolejności korzystaj z list dyskusyjnych projektów

Jeśli interesujący Cię projekt ma własną listę dyskusyjną developerów, pisz na tę listę, a nie do poszczególnych osób - nawet jeśli wiesz, kto może najlepiej odpowiedzieć na Twoje pytanie. Adres listy dyskusyjnej znajdziesz w dokumentacji bądź na stronie domowej projektu. Takie posunięcie ma kilka zalet:

Jeśli projekt ma zarówno listę dla użytkowników, jak i developerów (albo "koderów"), a Ty nie grzebiesz w kodzie, pytaj na liście/forum użytkowników. Nie spodziewaj się, że otrzymasz pomoc na liście developerów - tam Twoje pytanie będzie tylko przeszkadzać w wymianie innego rodzaju informacji.

Jeśli jednak jesteś pewien, że Twój problem jest niezwykły, a z listy/forum dla użytkowników przez parę dni nie uzyskałeś pomocy, możesz spróbować pytać na liście dla developerów. Przedtem koniecznie obserwuj ją przez kilka dni, żeby wyczuć klimat (ta rada dotyczy każdej prywatnej czy półprywatnej listy).

Jeśli nie możesz znaleźć adresu listy, a widzisz jedynie adres maintainera, napisz do niego. Nie musi to oznaczać, że lista dyskusyjna nie istnieje. Zaznacz w mailu, że pomimo prób nie udało Ci się znaleźć odpowiedniej listy, a także, że nie masz nic przeciwko przesłaniu Twojego listu do innych osób. Wielu ludzi uważa, że prywatny list musi pozostać prywatny, nawet jeśli nie zawiera żadnych tajnych danych. Takie pozwolenie daje odbiorcy wybór, co zrobić z listem od Ciebie.

Używaj treściwych, precyzyjnych tematów w nagłówkach

Na listach pocztowych lub grupach dyskusyjnych najlepszym sposobem na przyciągnęcie uwagi ekspertów jest temat w nagłówku Twojej wiadomości zawarty w około 50 znakach (lub mniej). Nie trać szansy na ich odpowiedź, pisząc bełkot w stylu "Proszę, pomóżcie mi" (nie mówiąc już o "PROSZĘ, POMUSZCIE!"; wiadomości z takim tematem omijamy odruchowo). Nie próbuj wywrzeć na nas wrażenia, ukazując ogrom swojego cierpienia.

Dobrym zwyczajem stosowanym przez organizacje wsparcia technicznego jest trzymanie się w tematach konwencji "obiekt - nieprawidłowość". Część "obiekt" określa, z jaką rzeczą lub grupą rzeczy wystąpił problem, w części "nieprawidłowość" jest opis niespodziewanego zachowania.

Głupio:
POMOCY! Nie działa mi grafika w laptopie!
Mądrze:
W XFree86 4.1 znika kursor, grafika Fooware z chipsetem MV1004
Najrozsądniej:
XFree86 4.1 na grafice Fooware z chipsetem MV1004 - znikający kursor.

Konwencja opisywania "obiekt - nieprawidłowość" pomoże Ci sformułować problem w szczegółowy sposób. Co jest nie tak? To tylko kursor, czy może także karta graficzna? Czy to jest normalne dla XFree86? Dla wersji 4.1? Czy to jest charakterystyczne dla chipsetów grafiki Fooware? Dla modelu MV1004? Jeśli widzimy rezultaty tych obserwacji, możemy od razu zrozumieć, co jest przyczyną Twoich problemów i stwierdzić na pierwszy rzut oka, jakiego rodzaju to jest problem.

Przeglądanie archiwum najczęściej odbywa się po tematach. Wybierz swój temat tak, by jak najlepiej odpowiadał treści pytania - dzięki temu następny przeszukujący archiwa w związku z problemem podobnym do Twojego znajdzie odpowiedni wątek i nie będzie musiał pytać jeszcze raz.

Jeśli zadajesz pytanie w odpowiedzi na inną wiadomość (Reply), pamiętaj, aby tak zmienić temat listu, żeby było widać, że zadajesz pytanie. Temat, który wygląda tak: "Re: test" lub "Re: nowy bug" prawdopodobnie nie przyciągnie wystarczającej uwagi. Wycinaj również cytaty poprzedniej wiadomości do minimum, zgodnie z wątkiem.

Jeżeli chcesz utworzyć nowy wątek, nie zrobisz tego poprzez odpowiedź na inną wiadomość. Niektóre klienty poczty (jak np. mutt) zezwalają na sortowanie wiadomości w wątkach i ukrywanie ich w ten sposób. Osoby, które tak robią, nie zobaczą Twojej wiadomości.

Zmiana tematu nie wystarczy. Mutt, a także prawdopodobnie inne klienty poczty, sprawdzają pozostałe informacje w nagłówkach wiadomości w celu przyporządkowania ich do wątku. Najlepiej po prostu utworzyć nową wiadomość.

Na forach WWW panują nieco inne zasady. Wiadomości są związane tylko z konkretnymi dyskusjami i nie można ich znaleźć poza wątkami. Zmiana tematu nie jest więc konieczna (na niektórych forach jest wręcz niemożliwa). Jednak zadawanie pytania w odpowiedzi na inny artykuł jest w ogóle kiepskim pomysłem - przeczytają je tylko obserwatorzy konkretnego wątku. Jeśli więc chcesz zainteresować kogoś oprócz osób aktywnych w tym wątku, załóż nowy.

Spraw, by łatwo było odpowiedzieć

Zakończenie wiadomości sentencją "proszę słać odpowiedź na adres..." raczej spowoduje, że nie dostaniesz żadnej odpowiedzi. Jeżeli nie jesteś w stanie wygospodarować kilku sekund na ustawienie poprawnego pola Reply-To:, nikt z nas nie wygospodaruje kilku sekund na przeanalizowanie Twojego problemu. Jeżeli Twój klient poczty nie ma takich możliwości, korzystaj z lepszego klienta. Jeżeli Twój system operacyjny nie oferuje żadnego klienta poczty z takimi możliwościami, zaopatrz się w lepszy system.

Pisz poprawnie stylistycznie, gramatycznie i ortograficznie

Z doświadczenia wiemy, że ludzie, którzy niedbale i niechlujnie piszą posty, najczęściej są niedbali i niechlujni w myśleniu i programowaniu. Odpowiadanie na pytania takim ludziom mija się z celem, wolimy inaczej wykorzystać czas.

Formułowanie swoich pytań jasno i zrozumiale jest zatem bardzo ważne. Jeśli nie chce Ci się tego zrobić, nie oczekuj, że zwrócimy na Ciebie uwagę. Zadbaj o poprawność językową. Nie chodzi tu o sztywność czy oficjalność - porozumiewamy się raczej językiem swobodnym, żargonowym i z humorem, jesteśmy jednak bardzo precyzyjni. Precyzja jest konieczna - dzięki temu widać, że jesteś myślący i uważny.

Pisząc, używaj poprawnie znaków przestankowych oraz wielkich i małych liter. Nie PISZ WIELKIMI LITERAMI - jest to niegrzeczne i rozumiane jako krzyk. (Pisanie samymi małymi literami jest nieco mniej drażniące, jednak trudne do odczytania. Alanowi Coxowi to ujdzie, ale Tobie nie.)

Jeśli piszesz jak półanalfabeta, zostaniesz prawdopodobnie zignorowany. Pisanie l337 h4X0r - 'haksorskim alfabetem' - jest podłożeniem głowy pod topór i gwarantuje grobową ciszę (w najlepszym przypadku zostaniesz uraczony sarkazmem i kilkoma lekceważącymi radami).

Jeśli zadajesz pytanie na forum, na którym nie używa się Twojego rodzimego języka, możesz spodziewać się pewnej tolerancji dla błędów gramatycznych i ortograficznych - ale zerowej dla lenistwa (tak jest, zwykle potrafimy dostrzec różnicę). Ponadto jeżeli nie znasz języka rozmówców - pisz po angielsku. Raczej olewamy pytania zadane w niezrozumiałym dla nas języku; angielski uważany jest za język 'roboczy' Internetu. Pisząc po angielsku, minimalizujesz prawdopodobieństwo odrzucenia swojego pytania.

Wysyłaj pytania w łatwych do zrozumienia formatach

Jeżeli Twoje pytanie będzie trudne do odczytania, najprawdopodobniej zostanie zignorowane. Dlatego:

Jeśli używasz klientów pocztowych pracujących w środowisku graficznym (Netscape Messenger, MS Outlook itp.) i pracujesz z ustawieniami domyślnymi, możesz naruszyć powyższe zasady. Większość klientów posiada opcję "Podejrzyj źródło" - w ten sposób sprawdź, czy poza czystym tekstem nie wysyłasz jakichś śmieci.

Bądź precyzyjny i podawaj dokładne informacje dotyczące problemu

Zrób wszystko, co w Twojej mocy, by odpowiedzieć na pytania, jakie zostaną Ci przez nas zadane.

Simon Tatham napisał znakomity esej zatytułowany "Jak efektywnie raportować błędy". Gorąco polecamy.

Dużo nie znaczy dobrze

Musisz precyzyjnie i konkretnie określić problem. Nie pakuj olbrzymiej ilości kodu lub informacji w swoje pytanie. Jeśli masz wielki, skomplikowany wynik błędnego działania jakiegoś programu, spróbuj przyciąć go, uczynić jak najmniejszym.

Ma to sens z co najmniej trzech powodów. Po pierwsze, zauważalny wysiłek włożony w uproszczenie pytania sprawi, że z większym prawdopodobieństwem otrzymasz odpowiedzi. Po drugie, samo uproszczenie pytania sprawi, że szybciej ktoś odpowie. Po trzecie, w procesie oczyszczania raportu o błędzie może sam wpadniesz na rozwiązanie lub znajdziesz obejście.

Nie ogłaszaj, że znalazłeś błąd

Kiedy masz problem z kawałkiem kodu, nie twierdź, że znalazłeś błąd, dopóki nie będziesz tego absolutnie pewien. Podpowiedź: dopóki nie pokażesz kodu łatki, która naprawia błąd, bądź testów porównawczych z poprzednią wersją, które pokazują nieprawidłowe zachowanie, prawdopodobnie nie jesteś wystarczająco pewien.

Pamiętaj, że mnóstwo użytkowników nie miało takiego problemu. W przeciwnym wypadku poznałbyś rozwiązanie podczas czytania dokumentacji i przeszukiwania sieci (bo zrobiłeś to, zanim zacząłeś narzekać, prawda?). A to oznacza, że najprawdopodobniej to Ty popełniasz błąd, a oprogramowanie jest w porządku.

Osoby, które napisały oprogramowanie, włożyły dużo ciężkiej pracy, by działało ono jak najlepiej. Twierdząc, że znalazłeś błąd, sugerujesz, że ktoś coś gdzieś zrobił źle i najczęściej w ten sposób obrażasz tego kogoś - nawet jeżeli masz rację. Bardzo niedyplomatycznie jest zakrzyknąć "błąd" w polu tematu.

Zadając pytanie, najlepiej zaznaczyć, że prawdopodobnie to Ty coś robisz nie tak, nawet jeśli jesteś pewny, że znalazłeś błąd. Jeżeli rzeczywiście coś jest źle, dowiesz się w odpowiedzi. Postępując tak, jak radzimy, stawiasz się w sytuacji, w której maintainerzy będą chcieli raczej Cię przeprosić, jeżeli faktycznie był błąd, niż zdenerwują się, że oskarżasz ich o błąd, który sam popełniłeś.

Płaszczenie się nie zastąpi odrobienia pracy domowej

Niektórzy ludzie, zrozumiawszy, że nie powinni byli zachowywać się arogancko i ordynarnie, domagając się odpowiedzi, przesadzają w drugą stronę i zaczynają się płaszczyć. "Wiem, że jestem żałosnym lamerem, ale...". Takie zachowanie nie pomaga, a jest szczególnie denerwujące, kiedy łączy się z niezrozumieniem problemu.

Nie marnuj swojego i naszego czasu na niedojrzałe zagrywki. Zamiast tego zbierz fakty i przedstaw pytanie tak jasno, jak potrafisz. Zdecydowanie lepiej zaprezentować się w ten sposób, niż się płaszczyć.

Niektóre fora mają wydzielone miejsca na pytania początkujących. Jeśli czujesz, że Twój problem jest prosty, pytaj tam. I nie płaszcz się.

Opisz symptomy problemu, a nie Twoje domysły

Nie pisz co, według Ciebie powoduje problem (gdyby Twoje domysły były słuszne, nie potrzebowałbyś pomocy). Upewnij się, że podajesz konkretne objawy problemu, a nie własną interpretację czy teorię. Interpretacje i diagnozy pozostaw nam. Jeśli uważasz, że Twoje domysły mogą być ważne, zaznacz, że tylko zgadujesz, i wyjaśnij, czemu to nie wystarczyło.

Głupio:

Ciągle otrzymuję błąd SIG11 podczas kompilacji jądra i podejrzewam jakieś uszkodzenie podzespołu płyty głównej. Jak najlepiej to sprawdzić?

Mądrze:

Mój domowy K6/233 z płytą główną FIC-PA2007 (chipset VIA Apollo VP2) oraz 256MB RAM-u Corsair PC133 SDRAM zwraca błąd SIG11 po dwudziestu minutach od włączenia podczas procesu kompilacji jądra, ale nigdy w ciągu pierwszych 20 minut. Reboot nie powoduje restartu zegara, natomiast wyłączenie wszystkiego - tak. Wymiana RAM-u nie pomogła. Interesująca część logu z zapisem procesu kompilacji wygląda tak.

Opisz symptomy problemu w kolejności chronologicznej

Najbardziej użyteczna wskazówka w rozszyfrowywaniu czegoś, co poszło źle, najczęściej leży w zdarzeniach bezpośrednio to poprzedzających. Zatem Twój raport powinien opisywać dokładnie, co zrobiłeś lub co zrobiła maszyna - od początku do końca. W przypadku linii poleceń tworzenie logów sesji (np. używając programu script) i przytoczenie stosownych mniej więcej dwudziestu linii może bardzo pomóc.

Jeśli program, którego problem dotyczy, posiada wbudowane opcje diagnostyczne (jak np: -v for verbose), spróbuj pomyśleć nad takich ich dobraniem, by wydobyć możliwie jak najwięcej pożytecznych informacji.

Jeśli Twój raport zrobił się dosyć duży (większy niż 4 akapity), dobrze byłoby streścić krótko problem na początku, a następnie resztę przedstawić w kolejności chronologicznej. Dzięki temu będziemy wiedzieli, czego szukać podczas czytania Twojego raportu.

Opisz cel, a nie kroki na drodze do jego osiągnięcia

Jeżeli próbujesz dowiedzieć się, jak coś zrobić (a nie zaraportować błąd), zacznij od przedstawienia celu. Dopiero potem wypunktuj kroki prowadzące do tego, na czym utknąłeś.

Często ludzie, którzy potrzebują pomocy technicznej, mają cel dokładnie sformułowany i utykają po drodze, którą uważają za jedyną możliwą. Przychodzą po pomoc w jednym z kroków postępowania, ale nie zdają sobie sprawy, że to cały sposób jest błędny. Często przełamanie takiego toku rozumowania wymaga większego wysiłku.

Głupio:

Jak ustawić przycisk kolorów w programie FooDraw, aby otrzymać heksadecymalną wartość RGB?

Mądrze:

Próbuję zastąpić tablicę kolorów w obrazku wybranymi przez siebie wartościami. Jedyne wyjście, jakie widzę, to edycja każdej tablicy, ale nie mogę w programie FooDraw zmusić przycisku kolorów do pobrania heksadecymalnej wartości RGB.

Druga wersja pytania jest lepsza - dopuszcza możliwość odpowiedzi sugerującej użycie lepszego narzędzia do tego zadania.

Nie proś o odpowiedź na prywatny adres

Uważamy, że rozwiązywanie problemu powinno być jawne, odbywać się na forum publicznym - po to, by pierwsza odpowiedź, jeśli okaże się błędna bądź niekompletna, mogła zostać poprawiona przez kogoś o większej wiedzy. Udzielanie dobrych odpowiedzi publicznie pozwala też na zaprezentowanie swojej kompetencji i doświadczenia.

Gdy prosisz o odpowiedź na prywatny adres, zakłócasz ten proces. Nie rób tego. To udzielający odpowiedzi dokonuje wyboru, jak to zrobi. Jeśli ktoś odpowiada na adres prywatny, oznacza to zazwyczaj, że pytanie jest źle sformułowane lub zbyt oczywiste, by zainteresować innych.

Jest wyjątek od tej reguły. Jeśli uważasz, że na swoje pytanie otrzymasz mnóstwo podobnych odpowiedzi, napisz: "odpowiedzi proszę kierować na mój adres, a ja podsumuję je i prześlę na grupę". Ustrzeżenie listy bądź grupy dyskusyjnej przed zalewem identycznych wiadomości jest uprzejme - musisz jednak dotrzymać słowa i przesłać podsumowanie.

Pytając, wyrażaj się precyzyjnie

Nieprecyzyjne pytania są uważane za bardzo czasochłonne. Ludzie, którzy z pewnością udzielą Ci dobrej odpowiedzi, są również bardzo zajęci (biorą na siebie wiele obowiązków). Są uczuleni na czasochłonne pytania, więc na nieprecyzyjne też.

Najprawdopodobniej uzyskasz użyteczną odpowiedź, jeśli wyjaśnisz dokładnie, czego oczekujesz (dostarczenia wskazówki, przesłania kodu, sprawdzenia Twojej łatki itp.). To pozwoli skupić wysiłek na konkretnych czynnościach i pośrednio ograniczy czas i energię, którą trzeba włożyć, by Ci pomóc. To dobrze.

By zrozumieć świat, w którym żyją fachowcy, pomyśl o fachowości jako o niezmiernie obfitych zasobach i bardzo krótkim czasie, który masz na korzystanie z nich. Im mniej czasu fachowcy spędzą nad zrozumieniem pytania, tym prawdopodobniej otrzymasz odpowiedź od kogoś naprawdę dobrego (i bardzo zajętego).

Spraw, by forma Twojego pytania skróciła czas potrzebny fachowcowi na zagłębienie się - często nie sprowadza się to jedynie do uproszczenia pytania. Zatem na przykład "Czy możesz dać mi jakąś wskazówkę do wyjaśnienia X?" jest zwykle o wiele mądrzejsze niż "Czy możesz mi wyjaśnić X?". Jeśli jakiś kawałek kodu nie działa prawidłowo, zwykle lepiej poprosić kogoś, by wyjaśnił, co jest nie tak, niż prosić o naprawienie.

Nie wysyłaj zapytań z pracą domową

Potrafimy odróżnić pracę domową od innych problemów - większość z nas też je odrabiała. Te pytania są dla Ciebie, żebyś samodzielnie znalazł odpowiedź i czegoś się nauczył. Pytaj o wskazówki, ale nie o rozwiązanie.

Jeśli podejrzewasz, że ktoś podesłał Ci swoją pracę domową, ale i tak nie jesteś w stanie jej rozwiązać, spróbuj zapytać na grupie lub forum (w ostateczności na liście) użytkowników projektu. Nawet jeśli my zauważymy, że to czyjaś praca domowa, być może inni użytkownicy coś podpowiedzą.

Nie zadawaj bezcelowych pytań

Oprzyj się pokusie, by kończyć swoje prośby o pomoc nic nie znaczącymi pytaniami w stylu "Czy ktoś może mi pomóc?" lub "Czy jest na to jakaś odpowiedź?". Po pierwsze, jeśli opisałeś swój problem choć trochę fachowo, takie pytania są naprawdę zbędne. Po drugie, ponieważ są zbędne - niezmiernie nas drażnią - w odpowiedzi będziemy odpowiadać zgodnie z żelazną logiką, coś w stylu: "Tak, może Ci ktoś pomóc." lub "Nie, Tobie już nikt nie może pomóc."

Ogólnie rzecz biorąc, zadawania pytań "tak/nie" należy unikać, chyba że oczekuje się właśnie odpowiedzi "tak/nie".

Nie oznaczaj pytań jako "pilne", nawet jeśli Ci się spieszy

To Twój problem, nie nasz. Zaznaczenie pilności prawdopodobnie przyniesie odwrotny skutek - większość z nas po prostu skasuje takie wiadomości jako przejaw niegrzecznych i samolubnych prób natychmiastowego skoncentrowania na sobie uwagi i wymuszenia specjalnego traktowania.

Od takiego zachowania istnieje jeden wyjątek. Zaznaczenie pilności może być wskazane, jeżeli problem dotyczy ważnego programu, wykorzystywanego do zadań, które mogą nas interesować. W takim przypadku - kiedy jesteś pod presją czasu i zaznaczyłeś to grzecznie - ludzie mogą się wystarczająco zainteresować, by dać odpowiedź szybciej.

Jednak jest to dość ryzykowne z powodu subiektywnego podejścia do znaczenia usług lub serwerów - nasza ocena będzie prawdopodobnie inna od Twojej. Post z Międzynarodowej Stacji Kosmicznej uszedłby, ale post wynikający z chęci poprawienia sobie samopoczucia lub z powodów politycznych - raczej nie. W rzeczy samej post "Pilne, pomóżcie mi ocalić foczki!" prawdopodobnie spowoduje, że utoniesz w ogólnym flame autorstwa nawet tych, którzy uważają młode foczki za bardzo ważne.

Jeżeli wydaje Ci się to zadziwiające, zanim wyślesz jakikolwiek post, czytaj ten dokument jeszcze raz i jeszcze raz - do momentu, aż zrozumiesz.

Grzeczność nie boli, a czasem pomaga

Bądź uprzejmy. Używaj zwrotów 'proszę' i 'z góry dziękuję'. Doceniaj to, że ludzie spędzają czas, by Ci pomóc zupełnie za darmo.

Oczywiście nie jest to tak ważne, jak pisanie poprawnie gramatycznie, precyzyjnie i opisowo oraz unikanie zastrzeżonych formatów itd. - i nie może tego zastąpić. Generalnie wolimy raczej mieć do czynienia z czymś ciężkostrawnym, na przykład technicznie ścisłym raportem o błędzie, niż z grzeczną niejasnością.

Spróbuj jednak upiec dwie pieczenie na jednym ogniu - grzeczność zwiększy Twoje szanse otrzymania użytecznej i pomocnej odpowiedzi.

(Musimy zaznaczyć, że jedynym poważnym zarzutem, który padł pod adresem niniejszego dokumentu, jest zalecenie używania jedynie "z góry dziękuję". Niektórzy odbierają to jako zamierzenie braku podziękowań dla kogokolwiek później. Oczywiście zalecamy obydwie rzeczy -- uprzejmość z góry i podziękowania za czas/uwagę z dołu.)

Wyślij podsumowanie i podziękowania po rozwiązaniu problemu

Kiedy już rozwiązałeś problem, wyślij wiadomość do tych, którzy Ci pomogli. Daj znać, jak poszło, i podziękuj. Jeśli w rozwiązanie problemu była zaangażowana lista czy grupa dyskusyjna, podziękowania wypada wysłać też tam.

Najlepiej, gdyby podsumowanie było w tym samym wątku co oryginalne pytanie i miało dodane słowo "ROZWIĄZANIE", "ODPOWIEDŹ" lub coś równie oczywistego w temacie. Na listach dyskusyjnych o dużym ruchu osoba, która widzi wątek o "problemie X" zakończony wiadomością z tematem "Problem X - ROZWIĄZANY" wie dzięki temu, że nie musi poświęcać czasu na studiowanie tego wątku (chyba że uważa "problem X" za interesujący) i może analizowac inny problem.

Taka wiadomość nie musi być długa czy zawiła; proste "Witam - to był zepsuty kabel sieciowy! Dziękuję wszystkim - Bolek" jest lepsze niż nic. Tak naprawdę, jeżeli wyjaśnienie nie zawiera technicznych szczegółów, to krótkie, treściwe podsumowanie jest lepsze niż długa rozprawa. Powiedz, jak rozwiązałeś problem, ale nie musisz wdawać się w szczegóły.

Przy zaawansowanych problemach dobrze jest wysłać wiadomość z podsumowaniem historii rozwiązania bądź prób rozwiązania. Opisz także wynik wysiłków. Napisz, co zadziałało, a potem wskaż ślepe uliczki, które można ominąć. Potem, bo podsumowanie ma pokazywać rozwiązanie, a nie być nowelą detektywistyczną. Przedstaw osoby, które Ci pomogły - w ten sposób zyskuje się przyjaciół.

Poza kwestią uprzejmości, informacja o rozwiązaniu, które pomogło Tobie, ułatwi innym wyszukiwanie w archiwum pomocnych wiadomości.

I na koniec - tego typu mail daje wszystkim, którzy się w to zaangażowali, miłe poczucie rozwiązania problemu. Jeśli sam nie jesteś kumatym misiem, uwierz, że to dla nas bardzo ważne. Nierozwiązane problemy są niezmiernie frustrujace; chcielibyśmy mieć je przerobione. Dobra karma zgromadzona poprzez zaspokajanie tego pragnienia będzie Ci bardzo, bardzo pomocna, gdy będziesz musiał zadać kolejne pytanie.

Pomyśl, jak możesz pomóc innym w uniknięciu jakiegoś problemu. Zastanów się, czy poprawka w dokumentacji lub FAQ pomoże. Jeżeli tak, zaproponuj poprawki maintainerowi.

Dla nas takie zachowanie jest ważniejsze niż zwykła uprzejmość. W taki sposób zdobywa się reputację człowieka, który zachowuje się w porządku, a to bardzo pożyteczna sprawa.

Jak interpretować odpowiedzi

RTFM i STFW: Jak powiedzieć, że kompletnie dałeś ciała?

Istnieje starodawna i poważana tradycja: jeśli w odpowiedzi ujrzysz "RTFM", osoba, która to napisała, sugeruje Ci, byś Przeczytał Przyjazną Dokumentację (Read The Friendly Manual). I najczęściej ma rację. Zatem zrób to.

RTFM posiada młodszego krewniaka: jeśli w odpowiedzi dostaniesz "STFW", osoba, która to napisała, sugeruje Ci, że powinieneś Przeszukać Przyjazną Sieć (Search The Friendly Web). I najczęściej ma rację. Zatem zrób to.

Na forach mogą Cię odesłać do archiwum. Niektórzy są tak mili, że nawet podadzą Ci tytuł wątku, w którym problem został rozwiązany. Ale nie powinieneś na to liczyć; sam przeszukaj archiwum, zanim zadasz pytanie.

Często osoba odpowiadająca w ten sposób ma przed oczami dokument lub stronę WWW, której potrzebujesz, i widzi to, czego szukasz. Taka odpowiedź oznacza zatem, że a) potrzebna Ci informacja jest łatwa do odnalezienia, b) nauczysz się więcej, szukając jej samodzielnie, niż jeśli podać Ci ją na tacy.

Nie powinno Cię to urazić. Nie zignorowaliśmy Cię i w ten sposób daliśmy Ci do zrozumienia, że jednak zasłużyłeś na odpowiedź - właśnie ją dostałeś. Powinieneś raczej być wdzięczny za babcine pobłażanie.

Jeżeli nie zrozumiałeś...

Jeżeli nie zrozumiałeś odpowiedzi, nie wysyłaj natychmiast prośby o wytłumaczenie. Aby zrozumieć odpowiedź, zrób to, co wtedy, gdy rozwiązywałeś problem (manuale, FAQ, strony WWW, doświadczeni znajomi). Jeśli wciąż będziesz potrzebował wyjaśnień, zaznacz, co już zrozumiałeś.

Na przykład załóżmy, że napiszę: "Wygląda na to, że masz zapchane eglebegle, musisz wyczyścić".

Przykładem złego pytania jest: "Co to jest eglebegle?".

Przykładem dobrego pytania jest: "Przeczytałem dokumentację i jedyne eglebegle, jakie znalazłem, wspomniane są przy -z i przy -p foobarach. Żaden z nich nie wspomina o czyszczeniu eglebegle. Chodzi o jeden z nich, czy coś przegapiłem?".

Opryskliwe traktowanie

W naszym kręgu większość z tego, co wydaje się nieuprzejmością i opryskliwością, nie wynika z chęci obrażenia kogokolwiek. Raczej jest to efekt bezpośredniego, oczyszczonego z głupot stylu komunikacji, naturalnego dla ludzi, którzy bardziej koncentrują się na rozwiązaniu problemu, niż tworzeniu sympatycznego i miłego nastroju.

Jeśli dostrzeżesz tego typu opryskliwość, nie reaguj gwałtownie. Jeśli ktoś rzeczywiście przesadził, najprawdopodobniej ktoś ze starszyzny listy/grupy/forum go zmityguje. Jeśli jednak nic takiego się nie zdarzy, a Ty straciłeś cierpliwość, jest prawie pewne, że tamto podejście jest tam normalne i to Ty zachowałeś się niewłaściwie. Twój błąd. To zmniejsza Twoje szanse na uzyskanie informacji lub pomocy, której potrzebowałeś.

Z drugiej strony czasami spotkasz się też z całkowicie nieuzasadnioną nieuprzejmością i pozerstwem. Drugą stroną medalu jest to, że akceptowalnym sposobem na opryskliwców jest przywalenie im w ostrych słowach krytyczną analizą ich zachowania. Bądź jednak całkowicie pewien swoich racji, zanim tego spróbujesz. Granica pomiędzy zwróceniem uwagi na nieuprzejmość a prowokowaniem flame jest dość cienka i czasem sami popełniamy błąd. Jeśli jesteś nowy w środowisku, szanse na uniknięcie takiego błędu masz niewielkie. Jeśli przyszedłeś z pytaniami, a nie żeby się zabawić, lepiej trzymaj ręce z daleka od klawiatury i nie ryzykuj.

(Niektórzy ludzie twierdzą, że wielu z nas ma łagodną formę autyzmu lub zespołu Aspergera, że brakuje nam części mózgu odpowiadających za 'normalne' relacje międzyludzkie. Może to prawda, może nie. Jeśli nie jesteś jednym z nas, taki pomysł może pomóc Ci znosić naszą ekscentryczność. Prosimy bardzo. Nie dbamy o to, lubimy siebie, kimkolwiek jesteśmy - generalnie mamy dystans do przyklejanych ludziom łatek wariatów.)

W następnej części omówimy inny rodzaj gruboskórności, której doświadczysz, gdy to Ty zachowasz się niestosownie.

Żeby nie zachować się jak łajza

Prawdopodobnie parę razy dasz ciała w sposób tu opisany bądź podobny. Zostaniesz o tym dokładnie poinformowany, kwiecistymi słowy. Publicznie.

Najgorsze, co możesz wtedy zrobić, to jęczeć na temat tego, co Cię spotkało, twierdzić, że zostałeś obrażony, żądać przeprosin, krzyczeć, wstrzymywać oddech, aż posiniejesz, straszyć sądem, skarżyć się pracodawcom, zostawiać podniesioną deskę klozetową itp. Zamiast tego:

Żyj z tym. To normalne. Tak naprawdę, to jest to zdrowe i właściwe.

Standardy grupy nie biorą się znikąd - tworzą się i utrzymują dzięki ludziom aktywnie je stosujacym. Nie jęcz, że krytyka powinna być wysyłana na prywatny adres. To tak nie działa. Tak samo bez sensu jest twierdzenie, że zostałeś obrażony, bo ktoś powiedział, że nie masz racji bądź miał inne poglądy. Nie zachowuj się jak dupek.

Istnieją techniczne środowiska dyskusyjne, w których z powodu źle pojętej superuprzejmości piszącym nie wolno wspominać o błędach znalezionych w cudzych postach - "jeśli nie chcesz pomóc użytkownikowi w tym, o co pyta, to się nie odzywaj". Doświadczeni użytkownicy opuszczą taką grupę, a dyskusje tam zmienią się w bezsensowną paplaninę. Grupa stanie się bezużyteczna jako forum techniczne.

Wyolbrzymiając - albo forum będzie (w ten sposób) milutkie, albo użyteczne.

Pamietaj: kiedy mówimy Ci, że schrzaniłeś (bez względu na to, jak szorstko) i zebyś więcej tego nie robił, mówimy to z troski o 1) Ciebie 2) swoje środowisko. Łatwiej byłoby Cię zignorować lub wyfiltrować. Jeżeli nie potrafisz wykrzesać wdzięczności, miej przynajmniej trochę godności - nie jęcz i nie oczekuj, że będziesz traktowany jak porcelanowa laleczka tylko dlatego, że jesteś tu nowy, delikatny, wrażliwy i pełen złudzeń.

Może się zdarzyć, że ktoś na Ciebie naskoczy, zaatakuje bez wyraźnej przyczyny itp., nawet jeśli nie schrzaniłeś (tylko komuś się tak zdało). Jeśli wtedy zaczniesz marudzić i narzekać, naprawdę schrzanisz.

Tacy napadający to albo lamerzy bez pojęcia, którzy wierzą, że są niebywałymi fachowcami, albo psychologowie z bożej łaski, zabawiający się sprawdzaniem, czy schrzanisz, jeśli Cię podpuścić. Pozostali grupowicze albo ich zignorują, albo rozprawią się z nimi po swojemu. To, że napadający wymyślają sobie jakieś problemy, Ciebie nie musi dotyczyć.

Nie daj się wciągnąć w takiego flame'a. Kłótnie tego rodzaju najlepiej ignorować - oczywiście najpierw upewnij się, że to podpucha, a nie sposób na wskazanie Ci błędów czy sprytnie zakamuflowana odpowiedź na pytanie, które naprawdę zadałeś (czasem bywa i tak).

Pytania, których się nie zadaje

Poniżej kilka przykładów klasycznych głupich pytań - zobacz, co o tym sądzimy i dlaczego nie odpowiadamy.

P: Gdzie znajdę program X?

O: W tym samym miejscu gdzie ja znalazłem. Nie pajacuj - na drugim końcu jakiejś wyszukiwarki. Boże, czy ludzie jeszcze nie wiedzą, jak używać Google?

P: Jak mógłbym wykorzystać X do zrobienia Y?

O: Jeżeli chcesz zrobić Y, powinieneś zapytać bez określania metody, która może okazać się niewłaściwa. Pytania tego typu wskazują, że osoba coś tam wie o X, ale nie ma pojęcia o Y. Najlepiej ignorować takich ludzi, dopóki nie sformułują precyzyjnie swojego problemu.

P: Jak mogę skonfigurować wygląd shella, którego używam?

O: Jeżeli jesteś wystarczająco bystry, by zadać takie pytanie, to jesteś także wystarczająco bystry, by RTFM.

P: Czy mogę skonwertować dokument AcmeCorp do formatu TeX przy użyciu konwertera Bass-o-matic?

O: Sprawdź. Dzięki temu (a) poznasz odpowiedź i (b) przestaniesz marnować mój czas.

P: Mój {program, konfiguracja, polecenie SQL} nie działa.

O: To nie jest pytanie. Nie interesuje mnie granie w "Dwadzieścia pytań", żeby wyciągnąć, o co tak naprawdę Ci chodzi - mam lepsze rzeczy do roboty. Typowe reakcje:

P: Mam problem z moim Windowsem. Czy możesz mi pomóc?

O: Tak. Wyrzuć ten microsoftowy śmieć i zainstaluj otwarty (open-source) system operacyjny, jak np. Linux czy BSD.

Uwaga: możesz zadawać pytania związane z Windows, jeśli dotyczą programu, który ma swoją wersję na tę platformę lub musi z nią współdziałać (np. Samba). Niech nie dziwi Cię częstość odpowiedzi, że błąd tkwi w Windows, a nie w programie - Windows jest generalnie zepsuty i z tego wynikają problemy.

P: Mój program nie działa. Sądzę, że z powodu błędu w systemie X.

O: Istnieje pradopodobieństwo, że jesteś pierwszą osobą, która zauważyła błąd w funkcjach systemowych i bibliotekach używanych przez setki tysięcy osób, ale raczej jesteś wybitnie nieprzytomny. Nadzwyczajne twierdzenia wymagają nadzwyczajnych dowodów - kiedy wysuwasz takie tezy, musisz je uzupełnić wyczerpującą dokumentacją studium błędu.

P: Mam problem z zainstalowaniem Linuksa lub X. Czy możesz mi pomóc?

O: Nie. Musiałbym mieć bezpośredni dostęp do Twojej maszyny, by zdiagnozować Twój problem. Poproś kogoś o doraźną pomoc na lokalnej grupie związanej z Linuksem. Tu masz listę polskich grup.

Uwaga: pytania o instalację Linuksa są na miejscu, jeśli zadajesz je na forum lub liście konkretnej dystrybucji, z którą masz problem, albo na lokalnej grupie użytkowników. Dokładnie opisz szczegóły błędu. Pamiętaj, żeby najpierw przeszukać sieć i archiwa ze słowem kluczowym 'linux' pod kątem wszystkich podejrzanych części sprzętu.

P: Jak mogę zhackować roota/wykolidować opów/czytać cudze maile?

O: Jesteś niską formą życia, skoro chcesz takich rzeczy. Objawem ciężkiej głupoty jest proszenie nas o pomoc w takich sprawach.

Dobre i Złe pytania

Teraz pokażemy na przykładach, jak zadawać pytania mądrze. Przedstawimy po dwa pytania dotyczące tego samego problemu: jedno zadane głupio, a drugie mądrze.

Głupio: Gdzie mogę znaleźć wiadomości dotyczące Chruma Chrumowatego?

To pytanie prosi się o odesłanie do "STFW".

Mądrze: Szukałem informacji o "Chrumie Chrumowatym 2600" w Google, ale nie znalazłem żadnych użytecznych wskazówek. Nie wie ktoś może, gdzie mógłbym znaleźć informacje o programowaniu tego urządzenia?

To pytanie już przeszło przez etap STFW i zdaje się, że pytający naprawdę ma problem.

Głupio: Nie mogę skompilować kodu projektu brumbrum. Czemu to jest popsute?

On zakłada, że ktoś inny coś popsuł. Arogant.

Mądrze: Kod projektu brumbrum nie kompiluje się pod Nuliksem 6.2. Przeczytałem FAQ, ale nie ma tam nic o problemach związanych z Nuliksem. Tu jest zapis mojej próby kompilacji, coś popsułem?

Określił środowisko, przeczytał FAQ, wskazuje błąd i nie twierdzi, że to wina kogoś innego. Ten facet może być godny uwagi.

Głupio: Mam problem z płytą główną. Mógłby mi ktoś pomóc?

Jeden z nas prawdopodobnie zapyta: "Trzeba Cię też przewinąć i ponosić, żeby Ci się odbiło?" i nacisnie delete.

Mądrze: Próbowałem X, Y i Z na płycie głównej S2464. Kiedy to nie zadziałało, próbowałem A, B i C. Przy C zauważyłem ciekawe objawy. Niespodziewanie chrumkowanie się zbangladeszowało, ale niekoniecznie o to mi chodziło. Co zazwyczaj powoduje bangladeszowanie na płycie głównej Athlon MP? Ma ktoś pomysł, co jeszcze mogę sprawdzić, żeby zidentyfikować problem?

Ta osoba wydaje się warta uwagi. Wykazała inicjatywę w rozwiązywaniu problemu, a nie czekała na gotową odpowiedź.

W ostatnim pytaniu zauważ subtelną, lecz istotną różnicę pomiędzy 'co robić?', a 'pomóżcie mi wykombinować, co jeszcze mogę zrobić, żeby mnie oświeciło'.

Ostatni przykład jest oparty na prawdziwym wydarzeniu, które miało miejsce w sierpniu 2001 na liście dyskusyjnej linux-kernel. Tym razem to ja (Eric) zadawałem pytanie. Zaobserwowałem tajemnicze zwisy na płycie głównej Tyan S2464. Użytkownicy listy dostarczyli mi niezbędnych informacji potrzebnych do odkrycia, w czym tkwił problem.

Zadanie pytania w sposób, w jaki ja to zrobiłem, sprawiło, że ludzie łatwo i z zainteresowaniem zangażowali się w rozwiązanie problemu. Okazałem szacunek rozmówcom, doceniłem ich czas - wskazałem ślepe zaułki, w które już trafiłem.

Po wszystkim, kiedy dziękowałem wszystkim za pomoc i zaznaczyłem, jak świetnie wszystko poszło, pewien użytkownik listy zauważył, że współpraca nie wynikła z tego, że jestem na liście 'kimś ważnym', ale z tego, że zadałem pytanie we właściwej formie.

Jesteśmy na swój sposób bardzo merytokratycznym środowiskiem; jestem pewien, że facet miał rację. Gdybym zachował się jak dureń, zostałbym wysłany na drzewo - bez wzgledu na to, kim jestem. Sugestia faceta, by podać powyższy przypadek jako instrukcję dla innych, doprowadziła do stworzenia tego dokumentu.

Jeżeli nie otrzymujesz odpowiedzi

Gdy Twoje pytanie pozostaje bez odzewu, nie traktuj osobiście tego, że nie kwapimy się do pomocy. Czasem członkowie pytanej grupy mogą po prostu nie znać odpowiedzi. Brak odzewu to nie to samo, co ignorowanie, ale oczywiście trudno to odróżnić, patrząc z zewnątrz.

Przysłanie tego samego pytania jeszcze raz to zły pomysł. Jest drażniące i bezcelowe.

Istnieją inne źródła pomocy, z których możesz korzystać, często lepiej przystosowane do potrzeb nowicjuszy.

Jest wiele ogólnie dostępnych, lokalnych grup ludzi, którzy interesują się oprogramowaniem, nawet jeśli sami nigdy go nie pisali. Często celem tworzenia takich grup jest właśnie pomoc początkującym.

Ponadto istnieją komercyjne firmy, które możesz zatrudnić do pomocy - zarówno małe i duże (dwie najbardziej znane to RedHat i Linuxcare, jest też wiele innych). Nie bój się płacić za pomoc! Kiedy silnik w Twoim samochodzie wypluje uszczelkę, zazwyczaj zabierasz go do warsztatu i płacisz za naprawę. Nie możesz oczekiwać, że należy Ci się darmowa pomoc tylko dlatego, że oprogramowanie było za darmo.

W popularnych projektach takich jak Linux na jednego programistę przypada co najmniej 10 000 użytkowników. Jedna osoba nie jest w stanie służyć wsparciem technicznym ponad 10 000 ludzi. Pamiętaj, że jeśli płacisz za taką pomoc, wciąż kosztuje Cię ona o wiele mniej niż komercyjne oprogramowanie (wsparcie dla zamkniętego oprogramowania [closed source] jest zwykle o wiele droższe i mniej kompetentne niż wsparcie dla oprogramowania otwartego [open source]).

Jak być pomocnym w odpowiadaniu

Bądź łagodny. Stres związany z problemem może powodować, że ludzie zachowują się opryskliwie bądź głupio, nawet jeśli w rzeczywistości tacy nie są.

[...] Nie ma potrzeby publicznego upokarzania kogoś, kto naprawdę nie wiedział, co zrobić, a jego pomyłka nie wynikła ze złej woli. Zupełny początkujący może nie wiedzieć, jak przeszukiwać archiwa ani gdzie znaleźć FAQ.

Jeżeli nie wiesz czegoś na pewno, zaznacz to! Zła, ale wiarygodnie brzmiąca odpowiedź jest gorsza niż żadna. Nie kieruj nikogo na złą ścieżkę tylko dlatego, że fajnie jest brzmieć jak ekspert. Bądź skromny i uczciwy; dawaj dobry przykład każdemu z Twoich odbiorców.

Jeżeli nie możesz pomóc - nie przeszkadzaj. Nie wypisuj "śmiesznych" instrukcji, które mogą doprowadzić Twoich odbiorców do kłopotów - ktoś nieuświadomiony może wziąć Twój żart za dobrą monetę.

Zadawaj pytania sondujące, by wydobyć więcej szczegółów. Jeżeli robisz to dobrze, odbiorca może się czegoś nauczyć - podobnie jak Ty. Spróbuj zamienić pytania złe w dobre. Pamiętaj, że każdy kiedyś był początkujący.

Rzucanie "RTFM" jest uzasadnione przy odpowiadaniu ewidentnie leniwym łajzom; najlepiej polecić lekturę dokumentacji (nawet jeśli będzie to tylko odesłanie do Google z odpowiednim słowem kluczowym).

Jeżeli odpowiadasz, rób to treściwie. Nie proponuj skomplikowanych obejść, jeśli pytanie wynika z błędnego rozumowania lub użycia złego narzędzia. Wskaż dobre. Przeformułuj pytanie.

Niech każdy ma szansę wyciągnąć coś z pytania. Gdy trafi się dobre pytanie, pomyśl "jak zmienić dokumentację bądź FAQ, by nikt nie musiał ponownie na to odpowiadać?". Prześlij propozycję opiekunom dokumentacji/FAQ.

Jeżeli musiałeś trochę poszukać, aby odpowiedzieć na pytanie, raczej zaproponuj pytającemu wędkę niż usmażoną rybę. Odpowiadanie jest jak danie posiłku głodnemu, ale przedstawienie drogi rozumowania jest jak nauczenie go samodzielnego zdobywania żywności.

Do poduszki

Jeśli poszukujesz podstawowych wiadomości dotyczących zasad działania komputerów, Uniksa czy Internetu, poczytaj Podstawy Uniksa i Internetu.

Jeśli udostępniasz oprogramowanie bądź piszesz łaty do oprogramowania, postaraj stosować się do Praktyki Tworzenia Oprogramowania.

Podziękowania

Evelyn Mitchell zaproponowała kilka głupich pytań i zainspirowała "Jak być pomocnym w odpowiadaniu". Mikhail Ramendik zaproponował kilka istotnych ulepszeń.

Od tłumaczy

Tłumacze chcą przeprosić wszystkie osoby płci pięknej za to, że przy tłumaczeniu szowinistycznie pisali wszystkie zdania tak, jakby były adresowane do panów. Wstawianie "musiał/musiała" było ponad nasze siły.

Tłumacze dziękują (mimo wszystko) Wszystkim, Którzy Nie Umieją Poprawnie Zadawać Pytań w hierarchii pl.* Usenetu - oni właśnie byli bezpośrednią przyczyną popełnienia tegoż tłumaczenia.

Szczególne podziękowania dla Krzysztofa Kowalika, Pawła Kota i Adama Gąsiorowskiego za przejrzenie tłumaczenia i dokonanie poprawek.

Wszelkie uwagi, poprawki i komentarze odnośnie tego tłumaczenia mile widziane -> .

Ostatnia aktualizacja - 07 maja 2004.