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:

• wyślesz swoje pytanie na forum, gdzie będzie ono "nie na temat" (off topic),


• wyślesz podstawowy problem na forum, gdzie oczekiwane są raczej zaawansowane techniczne pytania (lub odwrotnie),


• wyślesz to samo pytanie na zbyt wiele grup naraz,


• wyślesz na grupę post będący pytaniem do konkretnej osoby, która ani nie ma wobec Ciebie żadnych zobowiązań, ani nie jest odpowiedzialna za rozwiązanie Twojego problemu.

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:

• 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 developerzy mogą rozdzielać między siebie.
  Jeden developer (szczególnie prowadzący projekt) może być
  zbyt zajęty, by odpowiedzieć na Twoje pytanie, a inny nie.


• Większość list dyskusyjnych posiada archiwa poindeksowane przez
  wyszukiwarki WWW. Dzięki temu kazdy będzie mógł znaleźć Twoje pytanie
  wraz z odpowiedziami już na etapie przeszukiwania sieci, co oszczędzi
  uczestnikom forum plagi powtarzających się pytań.


• 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 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, najprawdopodobnej zostanie
zignorowane. Dlatego:

• Wysyłaj pocztę w formacie plain text (nie jest trudno
  wyłączyć HTML).


• Załączniki MIME są dopuszczalne, jeśli zawierają istotną treść
  (np. plik źródłowy, łatkę), a nie śmieci dołączane przez Twojego
  klienta pocztowego (np. kopię Twojej wiadomości).


• Nie wysyłaj maili, w których akapity tworzą wielokrotnie zawinięte linie.
  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 na wartość
  niższą 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 widzieli dokładnie to samo, co Ty.


• 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. Znaki te mogą być niepoprawnie wyświetlane i wprowadzą
  bałagan w wiadomości.


• Nigdy nie oczekuj, że ktoś z nas zada sobie trud odczytania
  materiałów w zamkniętych, płatnych formatach, takich jak na przykład
  dokumenty Microsoft Worda czy Excela. Większość z nas reaguje na tego
  typu dokumenty tak, jak Ty na psie odchody na wycieraczce.


• Jeśli wysyłasz pocztę z systemu Windows, wyłącz te głupie microsoftowe
  "Smart Quotes". Dzięki temu Twój mail nie będzie okropnie uśmiecony
  ozdobnikami.


• Na forach WWW nie nadużywaj smileyów i możliwości htmla. Uśmieszek czy
  dwa są OK, ale kolorowany tekst jest uważany za lamerski. Nadużywanie
  uśmieszków, kolorów i innych ozdobników sprawi, że będziesz wyglądać
  jak rozchichotana nastolatka, co zasadniczo nie jest najlepszym pomysłem,
  jeśli przychodzisz po odpowiedzi, a nie na podryw.

Jeśli używasz klientów pocztowych pracujących w środowisku graficznym
(Netscape Messanger, 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

• Opisz swój problem lub błąd, który znalazłeś, dokładnie
  i przejrzyście.


• Opisz środowisko, w którym się pojawia (sprzęt, system, aplikacja,
  cokolwiek). Zaznacz wersję bądź dystrybucję systemu (na przykład "Red
  Hat 8.0", "Slackware 5.1" itp.).



• Opisz, co sprawdziłeś, próbując zrozumieć problem, zanim zadałeś
  pytanie.


• Opisz, jakie kroki podjąłeś, żeby ustalić, co jest problemem,
  zanim zadałeś pytanie.


• Opisz wszelkie zmiany w komputerze i konfiguracji oprogramowania,
  jakie zaszły w ostatnim czasie i mogą mieć znaczenie.

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 ostateczniś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 powininno 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: "Przeczytalem 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:

• Chciałbyś jeszcze coś dodać?


• Ojej, to straszne. Mam nadzieję, że dasz sobie z tym radę!



• I co to ma z nami wspólnego?

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.