Copyright © 2001 by Eric S. Raymond
Copyright © 2002 by Tomasz 'en' Dudzisz & Maciej 'Voovoos'
Wierzbicki (polskie tłumaczenie)
Oryginalny dokument angielskojęzyczny można znaleźć tutaj.
Dokument ten dostępny jest rownież w języku francuskim.
W naszym świecie rodzaj odpowiedzi, którą otrzymujesz na nurtujący Cię problem, zależy od sposobu, w jaki postawisz pytanie. Ten dokument nauczy Cię, jak formułować pytania, aby otrzymać w pełni satysfakcjonującą odpowiedź.
Pierwszą rzeczą jaką należy sobie uzmysłowić jest to, że lubimy zawiłe problemy oraz dobre, zmuszające do zastanowienia się nad nimi, pytania. Jeśli nie przyjmowalibyśmy zawsze takiego podejścia, nie byłoby nas tutaj. Gdy dostarczysz nam jakieś 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. Dobre zadania pomagają nam rozwijać nasze umiejętności i często odkrywać sprawy, na które nie zwracaliśmy wcześniej uwagi lub myśleliśmy o nich inaczej. "Dobre pytanie!" - jest dla nas szczerym i prawdziwym komplementem.
Powszechnie znaną opinią jest, iż reagujemy niechęcią lub opryskliwością na proste pytania. To czasem może wyglądać tak, że odruchowo oschle traktujemy i ignorujemy tych 'nowych'. W rzeczywistości tak nie jest.
Nie zamierzamy poświęcać swojego 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 całkiem innej osobie, która bardziej zasługuje na naszą odpowiedź. Tych pierwszych nazywamy "łajzami" ("losers" z racji historycznych wymawiane często jako "lusers").
Zdajemy sobie sprawę z tego, że jest wiele osób, które chcą korzystać z naszego oprogramowania i nie interesuje ich zagłębianie się w jego techniczne detale. Dla większości z nich komputer jest jedynie narzędziem - w dosłownym tego słowa znaczeniu - interesują się innymi rzeczami i żyją tylko po to by żyć. Rozumiemy to i akceptujemy, nie spodziewamy się, że każdego zafascynuje to, co nas. Jednakże nasz styl odpowiedzi przeznaczony jest dla ludzi, którzy jako tako interesują się tematem i gotowi są aktywnie uczestniczyć w rozwiązywaniu problemu. I to się nie zmieni. I nie powinno się zmienić - jeśli tak się stanie, staniemy się mniej efektywni w tym, co robimy najlepiej.
Jesteśmy (w większości) kimś w rodzaju wolontariuszy. Poświęcamy nasz wolny czas by odpowiadać na pytania, które momentami wręcz nas przygniatają ilością. Więc bezlitośnie musimy je filtrować. W szczególności ignorujemy pytania ludzi, którzy wydają się być łajzami, żeby znacznie efektywniej wykorzystać nasz cenny czas na pytania ludzi, którzy bardziej na to zasługują.
Jeśli twierdzisz, że taka postawa jest wstrętna, poniżająca, bądź arogancka, lepiej porzuć swoje uprzedzenia. Przecież nie błagamy każdego o wstąpienie do nas - jednak większość z nas chętnie powita Cię w naszym gronie jako równego sobie, jeśli tylko włożysz w to tyle wysiłku, ile tylko jest możliwe. Próba pomocy ludziom, którzy nie są skorzy pomóc samym sobie jest bezcelowa. Jeśli nie możesz pogodzić się z takim rodzajem "dyskryminacji", proponujemy Ci zatrudnić kogoś i płacić mu za techniczne wsparcie zamiast prosić nas o bezinteresowną pomoc.
Gdy zdecydujesz się jednak zwrócić do nas po pomoc, na pewno nie chciałbyś zachować się jak łajza. Najlepszym sposobem by otrzymać szybką odpowiedź jest pytać jak osoba inteligentna, wierząca w siebie, posiadająca wiedzę, której po prostu zdarzyło się szukać pomocy w tym jednym, konkretnym problemie.
Zanim wyślesz email z zapytaniem, zadasz pytanie na grupach dyskusyjnych, czy też na innym forum dyskusyjnym, to postaraj się znaleźć odpowiedź:
czytając manual,
studiując FAQ,
przeszukując sieć,
zadając pytanie bardziej doświadczonemu koledze.
Gdy będziesz zadawać pytanie, zaznacz, że zrobiłeś już powyższe rzeczy. Dzieki temu będziemy wiedzieć, że nie jesteś po prostu leniwy i nie marnujesz czasu innych ludzi. Jeszcze lepiej będzie, gdy przedstawisz to, czego sie nauczyłeś dzięki "zaliczeniu" powyższych punktów. Lubimy pomagac ludziom, którzy udowodnią, że sami potrafią sie uczyć i szukać odpowiedzi.
Przygotuj pytanie. Przemyśl je. Im lepiej udowodnisz, że włożyłeś sporo wysiłku w próbę rozwiązania problemu zanim zapytałeś nas, tym większe 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ę, iż 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 musisz otrzymać odpowiedź. Nie musisz, w końcu nie płacisz za to. Otrzymasz odpowiedź - jeżeli już ją otrzymasz - 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 wiedzę od innych.
Bardzo dobrym początkiem będzie wykazanie chęci do 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ę, żeby otrzymać odpowiedź, niż gdyby pytanie brzmiało: "Proszę o przesłanie dokładnej procedury, jakiej powinienem użyć". Daje to pewność, że dokończysz proces, jeśli ktoś Cię odpowiednio nakieruje.
Bądź staranny w doborze miejsca swojego zapytania. Prawdopodobnie będziesz zignorowany lub uznany za łajzę, jeśli:
wyślesz swoje pytanie na forum, gdzie będzie ono uznane za "nie na temat" (off topic),
wyślesz elementarny problem na forum, gdzie oczekiwane są raczej zaawansowane techniczne pytania (lub odwrotnie),
wyślesz to samo pytanie do zbyt wielu różnych grup naraz.
Zawsze odtrącamy pytania, które są błędnie sprecyzowane, źle ukierunkowane, by chronić nasz własny kanał komunikacyjny od zasypania go rzeczami zupełnie nie związanymi z tematem. Raczej nie chciałbyś zostać zignorowany.
Generalnie, pytania skierowane do właściwie obranego publicznego forum mają większą szansę uzyskać 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 raczej odpowiadać na pytania, które edukują wielu ludzi, niż na te, które pomogą zaledwie nielicznym.
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 projektu znajdziesz w dokumentacji bądź na stronie domowej projektu. Istnieje kilka powodów takiego zachowania:
Każde pytanie, które jest wystarczająco dobre, by zadać je jednemu z developerów, jest wystarczająco dobre, by zadać je pozostałym. W przeciwnym razie - jeżeli uważasz, że pytanie jest zbyt głupie, by zadać je na tej liście - nie ma powodu by niepokoić poszczególnych developerów.
Pytania zadawane na liście rozdzielają pracę pomiędzy developerów. Jeden developer (szczególnie, gdy jest on liderem projektu) może być zbyt zajęty, by odpowiedzieć na Twoje pytanie.
Większość list dyskusyjnych posiada posortowane archiwa, dostępne dla systemów indeksujących wyszukiwarek WWW, co ułatwia znalezienie pytania wraz z odpowiedziami, oszczędzając uczestnikom danego forum plagi pytań, na które odpowiedzi już udzielono.
Jeśli pewne pytania są zadawane dość często, może to być wskazówką dla developerów, by poprawić dokumentację lub sam program tak, by był bardziej przejrzysty.
Jeśli nie możesz znaleźć adresu listy, a widzisz jedynie adres maintainera, napisz do niego. Nie oznacza to jednakże, ż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. Wiele osób 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.
Z doświadczenia wiemy, że ludzie, którzy niedbale i niechlujnie piszą posty, najczęściej są niedbali i niechlujni w myśleniu i programowaniu (taka jest powszechna opinia). 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 potrafisz zrobić tych dwóch rzeczy jednocześnie, nie oczekuj od nas, że zwrócimy na Ciebie szczególną uwagę. Włóż więcej wysiłku w poprawność swojego języka. Nie chodzi tu o sztywność czy oficjalność - w rzeczywistości nasze środowisko cechuje się językiem swobodnym, żargonowym i humorystycznym, używanym jednak z precyzją. Tu musi być precyzja - pamiętaj, że muszą być jakiekolwiek oznaki Twojego myślenia, byśmy zwrócili na to uwagę.
Pisząc, używaj znaków przestankowych, wielkich i małych liter poprawnie. Nie PISZ WIELKIMI LITERAMI, to odczytywane jest 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 pseudo-inteligentny cycek - będziesz prawdopodobnie zignorowany. Pisanie l337 h4X0r - 'hakerskim alfabetem' - jest położeniem głowy pod topór i gwarantuje Ci, że nie otrzymasz nic poza grobową ciszą (lub, w najlepszym przypadku zostaniesz zasypany sarkazmem i 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 tolerancji dla lenistwa (tak jest, zwykle potrafimy dostrzec różnicę). Ponadto, jeżeli nie znasz języka swoich respondentów - pisz po angielsku. Mamy tendencję do olewania pytań zadanych w niezrozumiałym dla nas języku, angielski uważany jest za język 'roboczy' Internetu. Pisząc po angielsku minimalizujesz szansę odrzucenia swojego pytania.
Jeżeli Twoje pytanie będzie trudne do odczytania, jest bardzo prawdopodobne, że zostanie zignorowane. Dlatego:
Wysyłaj pocztę w formacie plain text (Nie jest trudno wyłączyć HTML.)
Załączniki MIME są zazwyczaj dopuszczalne, ale jedynie w wypadku, gdy zawierają istotną treść (np: plik źródłowy, łatka), a nie śmieci dołączane przez twojego klienta pocztowego (np: kopia twojej wiadomości).
Nie wysyłaj maili, w których całe akapity tworzą jedną, wielokrotnie zawiniętą linię. Utrudnia to odpowiedź na jakiś fragment maila. Pamiętaj, że osoba odpowiadająca może czytać Twojego maila na ekranie z ograniczeniem długości linii do 80 znaków, więc ustaw zawijanie linii do wartości niższej niż 80.
Nie zawijaj wierszy w cytowanych danych (we fragmentach logów czy zapisów sesji). Dane powinny być załączone w niezmienionej formie tak, aby czytający mieli pewność, że widzą dokładnie to samo, co Ty widziałeś.
Nie wysyłaj maili z kodowaniem MIME Quoted Printable na fora angielskojęzyczne. Tego typu kodowanie może być konieczne, gdy wysyłasz maila w języku, którego znaki diakrytyczne nie są określone w tablicy ASCII, ale niestety wiele klientów pocztowych nie obsługuje tego kodowania. W takim przypadku te znaki nie będą poprawnie wyświetlane i będą wprowadzały bałagan w wiadomości.
Nigdy nie oczekuj, że ktoś z nas zada sobie trud odczytania dokumentów w specyficznych formatach, takich jak na przykład Microsoft Word. Większość z nas reaguje na tego typu dokumenty tak, jak Ty reagujesz na psie odchody na wycieraczce.
Jeśli wysyłasz pocztę z systemu Windows, powyłączaj wcześniej wszelkie Microsoftowe głupoty. Dzięki temu unikniesz różnych śmieci w mailu.
Jeśli używasz klientów pocztowych pracujących w środowisku graficznym (Netscape Messanger, MS Outlook lub ich odpowiedniki), możesz naruszyć powyższe zasady, gdy pracujesz z ustawieniami domyślnymi. Większość takich klientów posiada opcję "Podejrzyj źródło" - przy jej pomocy sprawdź, czy poza czystym tekstem nie wysyłasz jakichś śmieci.
Na listach pocztowych lub grupach dyskusyjnych temat w nagłówku Twojej wiadomości, zawarty w około 50 znakach (lub mniej), jest doskonałym sposobem na przyciągnęcie uwagi wykwalifikowanych ekspertów. Nie trać szansy na ich odpowiedź poprzez bełkot w stylu "Proszę, pomóżcie mi" (nie mówiąc już o "PROSZĘ, POMÓŻCIE MI!"; wiadomości z takim tematem są omijane odruchowo). Nie próbuj wywrzeć na nas wrażenia, ukazując swoje ogromne cierpienie.
Dobrym zwyczajem dla tematów w nagłówkach, stosowanym przez organizacje typu tech-support, jest trzymanie się konwencji "obiekt - nieprawidłowość". Część "obiekt" specyfikuje z jaką rzeczą lub grupą rzeczy zaistniał problem, w części "nieprawidłowość" opis niespodziewanego zachowania.
POMOCY! Nie działa mi grafika w laptopie!
W XFree86 4.1 znika mój kursor, grafika Fooware z chipsetem MV1004
XFree86 4.1 na grafice Fooware z chipsetem MV1004 - znikający kursor.
Konwencja opisywania "obiekt - nieprawidłowość" pomoże Ci sformułować problem w bardziej 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 specyficzne dla chipsetów grafiki Fooware? Dla modelu MV1005? Jeśli widzimy rezultaty tych obserwacji, możemy natychmiast zrozumieć, co jest przyczyną Twoich problemów i stwierdzić na pierwszy rzut oka, jakiego rodzaju to jest problem.
Jeśli zadajesz pytanie w odpowiedzi na inną wiadomość (Reply), pamiętaj, aby tak zmienić temat listu, żeby wyraźnie wskazywał, iż zadajesz pytanie. Temat, który wygląda tak: "Re: test" lub "Re: nowy bug" prawdopodobnie nie przyciągnie wystarczającej uwagi. Obcinaj również cytaty poprzedniej wiadomości do minimum, zgodnie z wątkiem.
Opisz swój problem lub błąd Cię nurtujący jasno i przejrzyście.
Opisz środowisko, w którym się pojawia (sprzęt, system, aplikacja, cokolwiek).
Opisz, co zrobiłeś i spróbuj zrozumieć problem zanim zadasz pytanie.
Opisz kroki diagnostyczne, jakie spróbowałeś podjąć i spróbuj zająć jakies stanowisko zanim zadasz pytanie.
Opisz wszelkie zmiany w komputerze i konfiguracji oprogramowania, jakie zaszły w ostatnim czasie i mogą mieć jakieś znaczenie.
Skoro prosisz o pomoc, to 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 polecam Ci go przeczytać.
Musisz zwięźle i precyzyjnie określić problem. Nie pakuj olbrzymiej ilości kodu lub informacji w swoje zapytanie. Jeśli posiadasz wielki, skomplikowany wynik błędnego działania jakiegoś programu, spróbuj przyciąć go i uczynić go jak najmniejszym.
To jest użyteczne z co najmniej trzech powodów. Pierwszy: zauważalny wysiłek włożony w uproszczenie pytania sprawi, że z większym prawdopodobieństwem otrzymasz odpowiedzi. Drugi: samo uproszczenie pytania sprawi, że szybciej otrzymasz odpowiedź. Trzeci: w procesie oczyszczania Twojego raportu o błędzie może sam opracujesz jego rozwiązanie lub znajdziesz jego obejście.
Nie pisz co - według Ciebie - powoduje problem (gdyby Twoje domysły były słuszne, nie prosiłbyś o pomoc). Upewnij się, że podajesz konkretne symptomy problemu, a nie własną interpretację czy teorię. Interpretacje i diagnozy pozostaw nam.
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ó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 przez pierwsze 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.
Najbardziej użyteczna wskazówka w rozszyfrowywaniu czegoś, co poszło źle, najczęściej leży w poprzedzających to zdarzeniach. Zatem Twój raport powinien opisywać precyzyjnie, 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 dwudziestu linii jest bardzo przydatne.
Jeśli program, którego problem dotyczy, posiada wbudowane opcje diagnostyczne (jak np: -v for verbose), spróbuj pomyśleć nad starannym ich dobraniem, by wydobyć możliwie jak najwięcej pożytecznych informacji.
Jeśli Twój raport zrobił się dosyć duży (więcej niż 4 akapity), pożytecznym byłoby scharakteryzowanie krótko problemu na początku, a następnie posortowanie reszty w chronologicznej kolejności. W ten sposób, będziemy wiedzieli czego szukać podczas czytania Twojego raportu.
Uważamy, że rozwiązanie problemu powinno być przejrzyste, i powinno odbywać się na forum publicznym dlatego, by - jeśli w pierwszej odpowiedzi pojawi się błąd, bądź będzie ona niekompletna - ktoś o większej wiedzy mógł ją poprawić. Czasami także jesteśmy za udzielanie dobrych odpowiedzi postrzegani przez innych jako ludzie kompetentni i o solidnej wiedzy w danym temacie.
Gdy prosisz o prywatną odpowiedź, zakłócasz ten proces. Nie rób tego. Jest to wybór odpowiadającego jak odpowiedzieć. Jeśli ktoś odpowiada na adres prywatny, oznacza to zazwyczaj, że pytanie jest źle sformułowane lub zbyt oczywiste, by zainteresować innych.
Jest jeden wyjątek od tej reguły. Jeśli uważasz, iż pytanie jest takie, że 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 uprzejmym zachowaniem - musisz jednak dotrzymać obietnicy i przesłać podsumowanie.
Nieprecyzyjne pytania są postrzegane jako pytania bardzo czasochłonne. Ludzie, którzy z pewnością udzielą Ci dobrej odpowiedzi, są również bardzo zajęci (dlatego, że biorą na siebie wiele obowiązków). Tacy ludzie są uczuleni na pytania czasochłonne, więc również na pytania nieprecyzyjne.
Z dużym prawdopodobieństwem uzyskasz pozytywny odzew, jeśli wyjaśnisz dokładnie jakiego działania oczekujesz od swoich respondentów (dostarczenia wskazówki, przesłania kodu, sprawdzenia Twojej łatki, czegokolwiek). To skupi ich wysiłek na konkretnych czynnościach i pośrednio ograniczy czas i energię, którą musiałby ktoś włożyć, by Ci pomóc, w przypadku nieprecyzyjnych pytań.
By zrozumieć świat, w którym żyją fachowcy, pomyśl o fachowości, jak o niezmiernie obfitych zasobach i skąpo krótkim czasie, który masz na korzystanie z nich. Im mniejszą część czasu fachowcy zużyją na zrozumienie zadanego pytania, tym bardziej prawdopodobne będzie otrzymanie odpowiedzi od kogoś naprawdę dobrego (i bardzo zajętego jednocześnie).
Spraw by forma Twojego pytania zminimalizowała czas potrzebny fachowcowi na to, by zagłębić się w nie - bardzo często forma ta nie sprowadza się 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ć kogoś o naprawienie tego.
Jesteśmy nieźli w wynajdywaniu prac domowych - większość z nas bowiem też je odrabiała. Te pytania są dla Ciebie, zebyś samodzielnie znalazł odpowiedź i czegoś się nauczył. Pytaj o wskazówki, a nie o rozwiązanie.
Oprzyj się pokusie by sprowadzać Twoje prośby o pomoc do nic nie znaczących pytań 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 na wpół kompetentnie, 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ą lecz wymijająco, coś w stylu "Tak, może Ci ktoś pomóc." lub "Nie, Tobie już nikt nie może pomóc."
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 niegrzecznego i samolubnego zachowania - żądania natychmiastowej uwagi i specjalnego traktowania.
Bądź kurtuazyjny. Używaj 'Proszę' i 'Z góry dziękuję'. Doceń to, że ludzie spędzają czas, by Ci pomóc zupełnie za darmo.
Bycie przemiłym nie jest ważniejsze (i nie jest namiastką tego) niż pisanie poprawnie gramatycznie, precyzyjnie a zarazem opisowo, unikanie zastrzeżonych formatów itp. Generalnie wolimy raczej odebrać coś ciężkostrawnego, na przykład technicznie ścisły raport o błędzie, niż mglistą, niewiele mówiącą grzeczność i kurtuazję.
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 odebraliśmy pod adresem niniejszego howto, jest zalecenie używania jedynie "Z góry dziękuję". Niektórzy odbierają treść tej intencji jako zamierzenie braku podziękowań później dla kogokolwiek. Zalecamy robić obydwie rzeczy.)
Kiedy rozwiązałeś problem, wyślij wiadomość do wszystkich, którzy Ci pomogli; daj znać jak poszło i podziękuj. Jeśli w rozwiązanie problemu była zaangażowana lista pocztowa czy grupa dyskusyjna, podziekowania wypada wysłać też tam.
Ta wiadomość nie musi być długa czy zawiła; proste " Witam - to był zepsuty kabel sieciowy! Dziękuję wszystkim - Bolek" będzie lepsze niż nic. Tak naprawdę to krótkie, treściwe podsumowanie jest lepsze niż długa rozprawa, jeżeli wyjaśnienie nie zawiera technicznych szczegółów. Powiedz co rozwiązało problem, ale nie ma potrzeby wdawać się w szczegóły.
Poza uprzejmością, informacja, które konkretnie rozwiązanie pomogło Tobie, ułatwi innym wyszukiwanie w archiwum wiadomości, które mogą pomóc im.
I na koniec, tego typu mail usatysfakcjonuje wszystkich, którzy zaangażowali się w rozwiązanie problemu. Jeśli nie jesteś kumatym misiem zaufaj nam, że to uczucie jest bardzo dla nas ważne. Problemy przekształcające się w nierozwiązane ciągi dyskusyjne są niezmiernie frustrujacymi rzeczami; chcielibyśmy je rozwiązywać. Dobra karma zgromadzona poprzez zaspokajanie tego pragnienia, będzie Ci bardzo, bardzo pomocna, gdy będziesz zmuszony zadać kolejne pytanie.
Istnieje starodawna i poważana tradycja: jeśli w odpowiedzi ujrzysz "RTFM", osoba która to napisała sugeruje Ci, byś Przeczytał Tę 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ć Tę Przyjazną Sieć (Search The Friendly Web). I najczęściej ma rację. Zatem zrób to.
Często, osoba wysyłająca którykolwiek z tych rodzajów odpowiedzi posiada właśnie otwarty odpowiedni dokument lub stronę www, której potrzebujesz, i widzi to, czego szukasz. Ta odpowiedź oznacza ni mniej ni więcej, tylko po pierwsze potrzebna Ci informacja jest łatwa do odnalezienia, a po drugie nauczysz się więcej szukając jej samodzielnie, niż jeśli miałbyś podaną ją na tacy.
Nie powinieneś czuć się znieważony tym - to jest normalne - nie ignorujemy Cię i tym samym dajemy Ci do zrozumienia, iż jednak zasłużyłeś na odpowiedź - i właśnie ją dostałeś. Chyba raczej zamiast tego, powinieneś nam podziękować za babcine pobłażanie.
Jeżeli nie zrozumiałeś odpowiedzi, nie wysyłaj natychmiast prośby o wytłumaczenie. Aby zrozumieć odpowiedź, użyj tych samych sposobów, których używałes by rozwiązać problem (manuale, FAQ, www, doświadczeni przyjaciele). Jeśli wciąż będziesz potrzebował wyjaśnien, zaznacz co już zrozumiałeś.
Na przykład, załóżmy iż napiszę: "Wygląda na to, że masz zapchane eglebegle, musisz to wyczyścić". Wtedy:
Przykładem złego pytania jest: "Co to jest eglebegle?"
Przykładem dobrego pytania jest: "Przeczytalem odpowiedni manual i jedyne eglebeglesy, 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?"
W naszym kręgu większość z tego, co wydaje się nieuprzejmością i opryskliwością, nie jest chęcią obrazy kogokolwiek. Raczej jest to produkt bezpośredniego, wulgarnego stylu komunikacji, naturalnego dla ludzi, którzy bardziej koncentrują się na rozwiązaniu danego problemu niż aranżowaniu sympatycznego i miłego nastroju.
Jeśli dostrzeżesz tego typu opryskliwość, nie reaguj gwałtownie. Jeśli ktoś rzeczywiście przesadził, jest bardzo prawdopodobne, że ktoś ze starszyzny listy lub grupy lub forum go zmityguje. Jeśli w zasadzie nic się nie zdarzyło, a Ty nagle straciłeś cierpliwość, jest prawie pewne, iż to zachowanie jest tutaj normalne i to _Ty_ będziesz posądzony o niewłaściwe maniery. Twój błąd. To przekreśla Twoje szanse na uzyskanie informacji lub pomocy, której potrzebowałeś.
Z drugiej strony, czasami spotkasz się z całkowicie nieuzasadnioną nieuprzejmością i pozerstwem. Drugą stroną tego wszystkiego jest to, w jaki akceptowalny sposób ukrócić wyjątkowo twardych opryskliwców, uciąć takie ich zachowanie ostrym, słownym przytykiem. Bądź jednak całkowicie pewien swoich racji, zanim tego spróbujesz. Granica pomiędzy 'grzeczną nieuprzejmością' a 'frontalnym atakiem skierowanym na sprowokowanie lokalnej wojenki' jest wystarczająco cienka, by i po drugiej stronie popełnić ten błąd; jeśli jesteś nowy w danym środowisku, Twoje szanse na uniknięcie takiego błędu są niewielkie. Gdy w dalszym ciągu wydaje Ci się, iż jest to dobra zabawa, lepiej trzymaj ręce z daleka od klawiatury i nie ryzykuj.
(Niektórzy ludzie twierdzą, że wielu z nas posiada łagodną formę autyzmu lub zespołu Aspergera, że brakuje nam niektórych części mózgu, odpowiadających za poprawną ludzką interakcję. To może być prawda. Albo i nie. Jeśli nie jesteś jednym z nas, świadomość, iż jesteśmy chorzy psychicznie może pomóc Ci radzić sobie z naszym ekscentryzmem. Proszę bardzo. Nie dbamy o to, lubimy bycie tym, czym jesteśmy, czymkolwiek jesteśmy - generalnie posiadamy zdrowy sceptycyzm w stosunku do takich klinicznych diagnoz.)
W następnej części pomówimy na temat innego rodzaju gruboskórności, której doświadczysz, gdy zachowasz się niestosownie.
Bez sensu będzie, jeżeli dasz ciała w środowisku, w którym chcesz się porozumiewać, w sposób tu opisany, bądź podobny. Oczekuj, że zostaniesz o tym poinformowany, w kwiecisty sposób. I to publicznie.
Najgorszą rzeczą, jaką możesz zrobić, gdy Ci się to przytrafi, jest jęczenie na temat tego, co Cie spotkało, twierdzenie iż zostałeś obrażony, żądanie przeprosin, krzyk, przysłowiowe nabieranie wody w usta, straszenie sądem, skarżenie do pracodawcow, zostawianie podniesionej deski, i tym podobne. Zamiast tego lepiej:
Zignoruj to. To normalne. Tak naprawdę, to jest to zdrowe i właściwe.
Standardy grupy nie tworzą się same: są używane przez ludzi aktywnie je stosujacych publicznie. Nie marudź, że cała krytyka powinna być wysłana na prywatny adres. To nie działa w taki sposób. Tak samo nie ma sensu twierdzić, że zostałeś obrażony, bo ktoś powiedział, że nie masz racji, bądź miał inne poglądy. Takie zachowania to zachowania dupka.
Istnieją techniczne środowiska dyskusyjne pozbawione wszelkich zasad superuprzejmości, gdzie piszący są odsyłani z kwitkiem z komentarzem "jeśli nie chcesz pomóc, to się nie odzywaj", za każdy wytykający błędy post. To jest bez sensu - efektem opuszczenia grupy przez doświadczonych użytkowników będzie zamienienie dyskusji w bezsensowną paplaninę. Grupa stanie się bezużyteczna jako forum techniczne.
Do Ciebie należy wybór, czy interesuje Cię forum przesadnie uprzejme, czy uzyteczne, na którym znajdziesz pomoc.
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. Wiedz, że łatwiej byłoby Cię zignorować lub wyfiltrować ze swojego życia. Jeżeli nie potrafisz być wdzięczny, to przynajmniej miej trochę godności - nie jęcz, nie oczekuj, iż będiesz traktowany jak porcelanowa laleczka tylko dlatego, że jestes nowoprzybyłym z teatralnie superdelikatną duszą i złudnymi myślami.
Poniżej masz kilka przykładów klasycznych głupich pytań - zobacz, co o tym sądzimy.
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?
O: To nie jest pytanie, nie interesuje mnie granie w "Sto pytań do..." by dowiedzieć się o co tak naprawdę Ci chodzi - mam lepsze rzeczy do roboty. To są typowe moje reakcje:
Czy chciałbyś jeszcze coś dodać?
Ojej, to straszne, mam nadzieję, że uda Ci się z tym poradzić!
Znaczy, właściwie czego ode mnie oczekujesz?
O: Tak. Wyrzuć ten microsoftowy śmietnik i zainstaluj otwarty (open-source) system operacyjny, jak np. Linux czy BSD.
O: Nie. Musiałbym mieć bezpośredni dostęp do Twojej maszyny, by zdiagnozować Twój problem. Idź, poproś kogoś o doraźną pomoc na lokalnej grupie związanej z Linuksem.
Tutaj mamy zamiar zaprezentować, jak mądrze zadawać pytania. Przedstawimy pary pytań dotyczących tego samego problemu: jedno zadane głupio, a drugie mądrze.
To pytanie prosi się o odesłanie do "STFW".
To pytanie już przeszło przez etap STFW i zdaje się, że pytający naprawdę ma problem.
On zakłada, że ktoś inny coś popsuł. Arogant.
Określił środowisko, przeczytał FAQ, wskazuje błąd i nie twierdzi, że jego problem powstał z winy kogoś innego. Ten facet może być godny uwagi.
Jeden z nas prawdopodobnie odpowie : "Trzeba Cię też przewinąć i ponosić, żeby Ci się odbiło", i nacisnie delete.
Ta osoba wydaje się być warta tego, by udzielić jej odpowiedzi. Przedstawiła własne pomysły na rozwiązanie problemu, a nie czekała na gotową odpowiedź.
W ostatnim pytaniu zauważ subtelną, lecz istotną, różnicę pomiędzy "podajcie mi odpowiedź", a "pomóżcie mi proszę wykombinować, co jeszcze mogę zrobić, żeby rozwiązać problem."
Tak naprawdę, to forma ostatniego pytania jest oparta 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. Stwierdziłem tajemnicze zwisy na płycie głównej Tyan S2464. Użytkownicy listy dostarczyli mi niezbędnych informacji potrzebnych do rozwiązania problemu.
Zadanie pytania w sposob, w jaki ja to zrobiłem, sprawiło, że ludzie łatwo i z zainteresowaniem zangażowali się w rozwiązanie problemu. Okazałem szacunek dla moich rozmówców. Okazałem również szacunek dla ich czasu, gdyż wskazałem ślepe zaułki, które już sprawdziłem.
Po wszystkim, kiedy dziękowałem za pomoc i zaznaczałem, jak świetnie wszystko poszło, członek rzeczonej listy zauważył, że było to wynikiem nie tego iż jestem na liście "kimś ważnym", ale dlatego iż zadałem pytanie we właściwej formie.
Jesteśmy na swój sposób bardzo służbistym środowiskiem; jestem pewien, że miał rację, i gdybym się zachował jak dureń, zostałbym odesłany na drzewo lub zignorowany, bez wzgledu na to kim jestem. Jego sugestia, by podać powyższy przypadek jako instrukcję dla innych, doprowadzila do zawarcia go w tym howto.
Gdy Twoje pytanie pozostaje bez odzewu, nie oznacza to, że nie chcemy Ci pomóc, więc proszę, nie traktuj takiego stanu rzeczy personalnie. Czasem po prostu członkowie pytanej grupy nie znają na nie odpowiedzi. Brak odzewu nie jest jakimś rodzajem lekceważenia, co niestety dla niektórych często tak wygląda.
Zazwyczaj, ponowne rozesłanie tego samego pytania jest złym pomysłem. Jest to drażniące i bezcelowe.
Istnieją także inne źródła pomocy, z których możesz korzystać, często lepiej przystosowane do potrzeb nowicjuszy.
Jest też wiele ogólnie dostępnych, tudzież lokalnych, grup entuzjastów wolnego oprogramowania, którzy de facto nawet nigdy go nie pisali. Często celem takich grup jest właśnie pomoc użytkownikom jej potrzebującym.
Ponadto istnieją zupełnie komercyjne organizacje, które możesz zatrudnić do pomocy - zarówno małe i duże (RedHat i Linuxcare - dwie najbardziej znane, są też inne). Nie bądź przerażony wizją płacenia za udzielenie pomocy! Kiedy silnik w Twoim samochodzie wypluje uszczelkę, normalnym jest, iż udajesz się do warsztatu i płacisz za naprawę. Lecz nie możesz oczekiwać, że należy Ci się darmowa pomoc, tylko dlatego, iż oprogramowanie było za darmo.
W tak popularnym systemie operacyjnym jak Linux, na jednego programistę przypada 10 000 użytkowników. Jest po prostu niemożliwe, by jedna osoba radziła sobie ze wsparciem technicznym dla ponad 10 000 ludzi. Pamiętaj, że jeśli płacisz za taką pomoc, wciąż płacisz o wiele mniej niż kosztuje kupno komercyjnego oprogramowania (wsparcie dla zamkniętego oprogramowania [closed-source], jest zwykle o wiele droższe i mniej kompetentne niż takie wsparcie dla oprogramowania otwartego [open-source]).
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.
Tłumacze niniejszym 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. Musicie nas zrozumieć - wstawianie "musiał/musiała" i innych takich ukośników było ponad nasze siły .
Tłumacze chcieli również (mimo wszystko) podziękować Wszystkim Tym, Którzy Nie Umieją Poprawnie Zadawać Pytań w hierarchii pl. Usenetu - to Ci 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 -> en & Voovoos