This page has been robot translated, sorry for typos if any. Original content here.

Як правильно задавати питання

(Це кешована копія; оригінал був на http://ln.ua/~openxs/articles/smart-questions-ru.html. Якщо Ви помітили старіння цієї копії, або відновили вихідний джерело, напишіть, будь ласка, веб-майстру даного сайту.)

Eric Steven Raymond Thyrsus Enterprises < esr@thyrsus.com >

Rick Moen < rick@linuxmafia.com >

Copyright © 2001 Eric S. Raymond

Переклад на російську мову: Copyright © 2002-2005 Валерій Кравчук

Хронологія версій:

  • Версія 3.1 - 28 жовтень 2004 року (Додано: 'Google - ваш друг!')
  • Версія 3.0 - 2 лютого 2004 року (Істотне додавання міркувань про етикет спілкування в Web-форумах.)

зміст

переклади
Відмова від зобов'язань
Вступ
Перш, ніж питати ...
Коли запитуєте ...
Правильно вибирайте форум
Web- і IRC-форуми для початківців часто дозволяють отримати відповідь якомога швидше
Як другий крок, в списку розсилки проектів
Задавайте осмислені, конкретні теми повідомлень
Спростіть посилку відповіді
Пишіть зрозумілою мовою, дотримуючись правил граматики і лексики
Надсилайте питання у всьому зрозумілих форматах
Точно і детально опишіть проблему
Обсяг ще не означає точність
Чи не затверджуйте, що знайшли помилку
Публічне самоприниження не замінює виконання домашніх завдань
Описувати симптоми проблеми, а не свої припущення
Описувати симптоми проблеми в хронологічному порядку
Описувати мета, а не окремий крок
Не просіть відповідати на особисту адресу електронної пошти
Задавайте ясні і чіткі питання
Не ставте питання з домашніх завдань
Уникайте безглуздих прохань
Чи не позначайте своє питання як "Строковий", навіть якщо для вас він саме такий
Ввічливість ніколи не зашкодить, і іноді допомагає
Пошліть короткий опис рішення
Як інтерпретувати відповіді
RTFM і STFW: як зрозуміти, що ви серйозно облажались
Якщо ви не зрозуміли ...
Реакція на грубість
Не реагуйте як невдаха
Питання, які задавати не треба
Хороші і погані питання
Якщо відповіді не отримано
Як давати хороші відповіді
Додаткові джерела інформації
Подяки

Є переклади цього документа на китайський , чеський , датський , естонський , французький , німецький , іврит , угорська , італійська , японська , польська , російська , іспанська , шведська і турецька мови. Якщо ви хочете копіювати, підтримувати дзеркало, перевести або процитувати цей документ, прочитайте, будь ласка, мої правила копіювання .

Відмова від зобов'язань

На сайтах багатьох проектів в розділах про те, як поводитися за допомогою, є посилання на цей документ. Це добре, саме для цього він і призначений, але якщо ви - web-майстер, що збирається додати таку посилання на сторінці свого проекту, будь ласка, поруч з посиланням на видному місці вкажіть, що ми не є службою підтримки для вашого проекту!

Ми на власному гіркому досвіді переконалися, що, за відсутності такого попередження, нас постійно будуть дошкуляти ідіоти, які вважають, що публікація цього документа зобов'язує нас вирішувати всі технічні проблеми в світі.

Якщо ви читаєте цей документ тому, що потребуєте допомоги, і вам в результаті здається, що ви її можете отримати безпосередньо від авторів, то ви - один з цих самих ідіотів. Не ставте питання нам. Ми будемо їх просто ігнорувати. Наша мета - показати вам, як отримати допомогу у тих, хто розбирається в програмному або апаратному забезпеченні, з яким ви працюєте, але в 99% випадків, цими розбираються будемо не ми. Якщо не знаєте напевно, що один з авторів є експертом в тому, з чим ви розбираєтеся, - дайте нам спокій, і від цього всім стане краще.

Вступ

У світі хакерів , стиль відповідей, які ви отримуєте на поставлені технічні питання, залежить від способу завдання питань не менше, ніж від їх складності. Це керівництво навчить задавати питання так, щоб збільшити ймовірність отримання задовільної відповіді.

Зараз, коли програмне забезпечення з відкритими вихідними текстами стало широко поширене, ви часто можете отримати відповіді від інших, більш досвідчених, користувачів, а не від хакерів. Це добре; користувачі зазвичай трохи більш терпимо ставляться до помилок, які часто роблять новачки. Але, якщо звертатися до досвідчених користувачів як до хакерів, відповідно до представлених тут рекомендаціями, то це буде найефективнішим способом отримати корисні відповіді і від них.

Перш за все, треба зрозуміти, що хакерам насправді подобаються складні проблеми і гарні, здібні розворушити мізки, питання про ці проблеми. Якби нам це не подобалося, ми не були б хакерами. Якщо задати нам цікаве питання, що вимагає тривалих роздумів, ми будемо за нього вдячні; хороші питання - це стимул і подарунок. Хороші питання допомагають краще зрозуміти предмет і часто розкривають проблеми, яких раніше не помічали або про які не замислювалися. З вуст хакера: "Хороше питання!" - це великий і щирий комплімент.

Незважаючи на це, вважається, що хакери відносяться до простих питань швидше вороже або зарозуміло. Іноді здається, що ми досить грубі до новачків і ігноруємо їх. Але, насправді, це не так.

Ми, без сумніву, неприязно ставимося до людей, імовірно не бажають подумати або повчитися перш, ніж задавати питання. Такі люди вбивають час - вони беруть, нічого не даючи взамін, вони забирають час, який ми могли б присвятити іншого питання, більш цікавого, і іншій людині, більш гідного відповіді. Таких людей ми називаємо "невдахами" ( "losers") (з історичних причин це слово іноді пишеться як "lusers" - користувачі-невдахи).

Ми розуміємо, що багато людей просто хочуть використати створюване нами програмне забезпечення, і зовсім не збираються вивчати технічні деталі. Для більшості комп'ютер - це просто інструмент, засіб досягнення мети; у них є і більш цікаві заняття та інші проблеми в житті. Ми визнаємо це і не очікуємо, що кожного будуть цікавити технічні нюанси, настільки привабливі для нас. Проте, наш стиль відповідей на питання підходить для людей, дійсно цікавляться цим, і бажаючих бути активними учасниками процесу вирішення проблем. Це не зміниться. Та й не повинно змінюватися; в іншому випадку, ми не зможемо ефективно робити те, в чому ми - кращі.

Ми (в основному) - добровольці. Ми присвячуємо час свого нелегкого життя відповідей на питання, і часом ми не справляємося зі шквалом запитань. Тому доводиться безжально "фільтрувати базар". Зокрема, відкидати питання потенційних невдах, щоб витратити відведений на відповіді час більш ефективно, присвячуючи його переможцям.

Якщо ця позиція здається вам смішний, зарозумілою або зарозумілою, ви помиляєтеся. Ми не просимо вас на нас молитися - фактично, більшість з нас хотіли б спілкуватися з вами на рівних і прийняти вас в свою культуру, якщо ви докладете необхідні для цього зусилля. Але для нас просто неефективно намагатися допомогти людям, які не хочуть допомогти собі самі. Бути грубим - нормально, а ось прикидатися ідіотом - немає.

Отже, хоча зовсім не обов'язково бути технічно компетентним, щоб удостоїтися нашої уваги, треба продемонструвати якості, що дозволяють стати компетентним - уважність, вдумливість, спостережливість, бажання активно брати участь у виробленні рішення. Якщо ви не можете змиритися з подібного роду дискримінацією, має сенс заплатити комусь за комерційну підтримку, а не просити хакерів допомогти даром особисто вам.

Якщо ви вирішили звернутися до нас за допомогою, не ставайте в позицію невдахи. І не ведіть себе як невдаха. Кращий спосіб отримати швидкий і чуйний відповідь, - питати як людина розумна, впевнений в собі і знає, яким просто знадобилася допомога при вирішенні однієї конкретної проблеми.

(Доповнення до цього керівництву вітаються. Пропозиції можна надсилати на адресу esr@thyrsus.com . Врахуйте, проте, що цей документ не створювався як загальне керівництво по мережевому етикету , і я зазвичай ігнорую пропозиції, не пов'язані безпосередньо з отриманням корисних відповідей в технічному форумі .)

Перш, ніж питати ...

Перш, ніж задавати технічне питання по електронній пошті або в дискусійну групу, в чаті або на форумі, зробіть наступне:

  1. Спробуйте знайти відповідь за допомогою пошуку в Web.

  2. Спробуйте знайти відповідь в керівництві.

  3. Спробуйте знайти відповідь у списку поширених запитань (ЧаВО).

  4. Спробуйте знайти відповідь шляхом перевірок або експериментів.

  5. Запитайте досвідченого товариша.

  6. Якщо ви - програміст, спробуйте знайти відповідь, аналізуючи вихідний код.

Коли задаєте питання, вкажіть з самого початку, що ви все це вже зробили; це допоможе зрозуміти, що ви не якийсь там ледар, що тринькає чуже час. Ще краще, покажіть, що ви дізналися в результаті своїх пошуків. Нам подобається відповідати людям, що продемонстрував свою здатність сприймати відповіді.

Використовуйте прийоми типу пошуку в Google по тексту отриманого повідомлення про помилку (пошукайте також в дискусійних групах - Google groups, а не тільки на Web-сторінках). Це може привести або безпосередньо до документації, присвяченій тому, як цю помилку усунути, або до дискусії в списку розсилки, в якій можна буде знайти відповідь. Навіть якщо відповідь і не знайдеться, фраза: "Я пошукав в Google за наступним запитом, але нічого корисного не знайшов" стане в нагоді при зверненні за допомогою по електронній пошті або в дискусійну групу.

Підготуйте питання. Продумайте його. На поверхневі питання ви отримаєте поверхневі відповіді, або взагалі відповідей не отримаєте. Чим більше ви зробите, щоб продемонструвати свої роздуми і зусилля за рішенням проблеми до того, як просити допомоги, тим імовірніше, що ви цю допомогу отримаєте.

Не ставте неправильних питань. Якщо питання будується на помилкових припущеннях, будь хакер (в оригіналі - J. Random Hacker, прим. Перекладача), швидше за все, дасть непотрібний буквальну відповідь, подумавши при цьому "Дурне питання ...", і сподіваючись, що отримання того, про ніж ви просили, замість того, що дійсно потрібно, чогось вас навчить.

Не думайте, що вам повинні відповісти. Вам ніхто нічого не винен; ви ж, в кінцевому рахунку, не платили за ці послуги. Ви отримаєте відповідь, якщо заслужите його, задаючи істотний, цікавий і наводить на роздуми питання - питання, неявно дає спільноті новий досвід, а не просто пасивно вимагає від інших поділитися знаннями.

З іншого боку, непогано відразу ясно дати зрозуміти, що ви можете і хочете допомогти в процесі вироблення рішення. На запитання на кшталт "Чи може хтось підказати?", "Що не враховано в моєму прикладі?" і "А чи немає сайту, який стоїть на цю тему подивитися?" ймовірніше буде отримана відповідь, ніж на вимогу надіслати точну послідовність дій для вирішення проблеми, оскільки ви явно показали, що вирішите проблему самі, якщо хтось вкаже вам правильний напрямок дій.

Коли запитуєте ...

Правильно вибирайте форум

Ретельно продумайте, де саме ставити питання. Вас з великою ймовірністю проігнорують або спишуть як невдахи, якщо ви:

  • пошлете питання в форум, який не відповідає за тематикою (off topic)

  • пошлете самий елементарний питання в форум, де обговорюються складні технічні питання, чи навпаки

  • пошлете питання одночасно (cross-post) в безліч різних дискусійних груп

  • пошлете приватне повідомлення по електронній пошті незнайомій людині, особисто не відповідає за рішення ваших проблем

Хакери ігнорують питання, спрямовані не за адресою, щоб не завантажувати свої канали зв'язку з цим не має відношення до справи інформацією. Не варто потрапляти в цей розряд питань.

Тому спочатку треба знайти відповідний форум. У цьому вам знову допоможе пошукова система Google і інші засоби пошуку в Web. Використовуйте їх для пошуку сторінки проекту, найбільш тісно пов'язаного з обладнанням або програмним забезпеченням, з яким виникли труднощі. Зазвичай на цій сторінці будуть посилання на список поширених запитань (ЧаВО, FAQ - Frequently Asked Questions), списки розсилки проекту і їх архіви. Саме там і треба просити допомоги, якщо ваші власні зусилля (включаючи прочитання цих, виявлених вами, ЧаВО) не увінчалися успіхом. На сторінці проекту може бути також описана процедура інформування про помилку або представлена ​​посилання на неї. В такому випадку, скористайтеся рекомендованої процедурою.

Посилка ж повідомлення людині або в форум, з яким ви не знайомі, - підприємство, як мінімум ризиковане. Наприклад, не думайте, що автор інформативною web-сторінки хоче стати для ваших безкоштовним консультантом. Не робіть оптимістичних припущень про те, що вашого запитання будуть раді - якщо не впевнені, пошліть його за іншою адресою або відмовтеся від його посилки взагалі.

При виборі Web-форуму, дискусійною групи або списку розсилки, що не приймайте рішення тільки на основі імені; прочитайте список поширених запитань (FAQ) або правила, щоб переконатися, що питання відповідає тематиці. Почитайте повідомлення деякий час, перш ніж посилати питання, щоб відчути, як і що тут робиться. Насправді, перед посилкою питання не завадить пошукати за ключовими словами, пов'язаними з вашою проблемою, в архівах дискусійною групи або списку розсилки. В результаті можна знайти відповідь, а якщо немає, такий пошук допоможе краще сформулювати питання.

Не використовуйте всі доступні канали допомоги одночасно. Це схоже на крик і обурює людей. Звертайтеся до них по черзі.

Правильно визначте тему! Одна з класичних помилок - задавати питання про програмному інтерфейсі Unix або Windows в форумі, присвяченому мови, бібліотеці або інструментального засобу, що працює на обох платформах. Якщо ви не розумієте, чому це - груба помилка, краще взагалі не задавайте питань, поки не зрозумієте.

У загальному випадку, ймовірність отримати відповіді на питання в правильно обраному загальнодоступному форумі вище, ніж в приватному. Причин для цього декілька. Одна з них - кількість потенційних відповідають. Інша - розмір аудиторії, яка дізнається відповідь; хакери з великим задоволенням відповідають на питання, які можуть цікавити багатьох, ніж на питання, корисні лише одиницям.

Зрозуміло, що досвідчені хакери і творці популярних програм і так вже отримують набагато більше не відносяться до справи питань, ніж хотіли б. Збільшуючи цей потік, ви в деяких випадках можете стати останньою краплею - зрідка учасники популярних проектів припиняють їх підтримку, тому що не виносять більше супутніх їй проблем у вигляді потоку непотрібних повідомлень по електронній пошті на їх особисті адреси.

Web- і IRC-форуми для початківців часто дозволяють отримати відповідь якомога швидше

Ваша місцева група користувачів або ваш дистрибутив Linux може підтримувати Web-форум або канал IRC, призначений для допомоги початківцям. (В неангломовних країнах форуми для початківців, як і раніше, швидше за все, організовані у вигляді списків розсилки.) Це - відповідні місця для початкового завдання питань, особливо якщо передбачається, що ви зіткнулися з відносно нескладною або типовою проблемою. Відкрито рекламований канал IRC - це явне запрошення задавати питання, і, найчастіше, можливість отримувати відповіді в реальному часі.

Фактично, якщо програма, з якою у вас виникли проблеми, взята з дистрибутива (що, на сьогодні, типово), може виявитися краще спочатку запитати в форумі / списку розсилки за відповідним дистрибутива, перш ніж звертатися в форум / список розсилки програми. Хакери, які працюють над проектом, можуть просто відповісти: "Використовуйте нашу збірку".

Перш ніж ставити питання в будь-якому Web-форумі, перевірте, чи немає на ньому можливості пошуку. І якщо вона є, пошукайте пару раз за ключовими словами обговорення проблеми, подібної вашої; це може допомогти. Якщо перед цим ви виконали спільний пошук в Web (що треба було зробити), все одно пошукайте на форумі; можливо, ваша пошукова система давно не індексувала повторно цей форум.

Спостерігається цікава тенденція виконувати підтримку користувачів проектів через Web-форум або канал IRC, залишаючи електронну пошту для спілкування між розробниками. Тому, якщо потрібна допомога по проекту, зверніться спочатку до цих його джерелами інформації.

Як другий крок, в списку розсилки проектів

Якщо у проекту є список розсилки для розробників, шліть питання в цей список розсилки, а не окремим розробникам, навіть якщо впевнені, що знаєте, хто саме найкраще може відповісти на ваше запитання. Знайдіть адресу списку розсилки проекту в документації або на сайті проекту, і шліть питання за цією адресою. Є кілька хороших причин надходити саме так:

  • Будь-яке питання, досить хороший, щоб з ним звернутися до одного розробнику, буде цінним і для всієї групи. Навпаки, якщо здається, що питання надто примітивний для списку розсилки, це ще не привід морочити їм голову окремих розробників.

  • Якщо питання задається в списку розсилки, навантаження розподіляється між усіма розробниками. Конкретний розробник (особливо якщо він - керівник проекту) може бути занадто зайнятий, щоб відповідати на ваші запитання.

  • Більшість списків розсилки архівується, а архіви - індексуються пошуковими системами. Хтось зможе знайти ваше запитання і відповіді в мережі, і не здасть його знову в списку розсилки.

  • Якщо певні питання задаються часто, розробники можуть використовувати цю інформацію для поліпшення документації або самого програмного продукту, щоб вони стали більш зрозумілими. Але якщо ці питання задаються особисто, ні у кого немає загальної картини, - про що найчастіше запитують.

Якщо у проекту є окремі списки розсилки або Web-форуми для "користувачів" і для "розробників" (або "хакерів"), і ви не займаєтеся розбором (hacking) коду, задайте питання в списку / форумі для "користувачів". Не розраховуйте на теплий прийом в списку розсилки для розробників, де ваше запитання, ймовірно, віднесуть до розряду "шуму", що заважає обміну інформацією про хід розробки.

Однак, якщо ви впевнені в нетривіальністю свого питання і не отримали відповіді в списку розсилки / форумі для "користувачів" протягом декількох днів, зверніться до розробників. Має сенс перед цим постежити за відповідним списком розсилки або на форумі кілька днів, щоб вивчити його традиції (насправді, це має сенс робити перед зверненням в будь-який приватний або напівзакритий список розсилки).

Якщо не вдається знайти адресу списку розсилки проекту, але відома адреса особи, ведучого проект, пошліть своє запитання ведучому. Але і в цьому випадку не думайте, що списку розсилки немає. У своєму повідомленні вкажіть, що намагалися, але не змогли знайти відповідний список розсилки. Згадайте також, що не проти пересилання Вашого повідомлення іншим адресатам. (Багато хто вважає, що особиста кореспонденція повинна залишатися особистої, навіть якщо нічого секретного в ній немає. Вирішуючи переслати своє повідомлення, ви даєте людям вибір.)

Задавайте осмислені, конкретні теми повідомлень

При посилці повідомлення в список розсилки або в дискусійну групу, тема повідомлення - прекрасна можливість привернути увагу кваліфікованих експертів рядком довжиною до 50 символів. Не витрачайте їх на лепет типу "Допоможіть мені, будь ласка" (не кажучи вже про теми "PLEASE HELP ME !!!!"; повідомлення з такими темами викидаються рефлекторно). Не намагайтеся вразити нас глибиною своїх страждань; краще використовуйте відведене місце для максимально короткого опису проблеми.

Гарне угоду з оформлення тим повідомлень, що використовується багатьма службами технічної підтримки, - застосування шаблону "об'єкт - відхилення". Частина "об'єкт" задає, з чим саме виникла проблема, а частина "відхилення" описує відхилення від очікуваної поведінки.

нерозумно:

ДОПОМОЖІТЬ! Відеокарта на моєму ноутбуці не працює належним чином!

розумно:

Неправильна форма курсора миші в XFree86 4.1, відео на чіпсеті Fooware MV1005

Ще краще:

XFree86 4.1 курсор миші на чіпсеті Fooware MV1005 - неправильна форма

Процес написання теми за шаблоном "об'єкт-відхилення" допоможе більш детально осмислити проблему. Що саме неправильно працює? Тільки курсор миші або з іншого графікою теж є проблеми? Проблема тільки в XFree86? Тільки у версії 4.1? Ця проблема виникає тільки на відкритих з чіпсетом Fooware? Тільки в моделі MV1005? Хакер, отримавши повідомлення з подібною темою, зможе, в загальних рисах, зрозуміти, з чим саме у вас виникала проблема і що це за проблема.

У загальному випадку, уявіть, що переглядаєте список питань в архіві, в якому представлені тільки рядки теми. Зробіть так, щоб рядок теми досить добре відображала суть питання і наступний переглядає архів в пошуках відповіді на подібне питання міг знайти обговорення, що приводить до відповіді, а не посилав питання заново.

Якщо ви задаєте питання у відповідь, не забудьте змінити рядок теми так, щоб по ній було зрозуміло - задається питання. Рядок теми виду "Re: test" або "Re: new bug" не притягне достатньої уваги. Крім того, зведіть цитування попередніх повідомлень до мінімуму, достатнього, щоб нові користувачі могли зрозуміти, про що йшла мова.

Не посилайте просто відповідь на повідомлення списку розсилки, якщо збираєтеся обговорювати нову тему (почати нитку обговорення). Це звузить коло відповідальних. Деякі програми читання пошти, наприклад, mutt, дозволяють користувачеві сортувати повідомлення за темами, а потім ховати повідомлення по темі, згортаючи нитку обговорення. Ті, хто цією можливістю користується, ніколи Вашого повідомлення не побачать.

Поміняти тему недостатньо. Mutt і, можливо, інші програми читання електронної пошти, враховують не тільки рядок теми, а й іншу інформацію в заголовках повідомлень при прив'язці їх до нитки обговорення. Створіть абсолютно нове повідомлення.

У Web-форумах правила обговорення трохи відрізняються, оскільки повідомлення зазвичай більш тісно пов'язані з конкретними нитками обговорення і часто невидимі за межами цих ниток. Зміна теми при завданні питання у відповідь не суттєво (в повному обсязі форуми навіть дозволяють вказувати теми у відповідях, а якщо їх і можна задати, практично ніхто їх не читає). Але, задавати зустрічне запитання у відповідь саме по собі - сумнівна практика, оскільки питання це побачать тільки ті, хто стежить за відповідною ниткою обговорення. Тому, якщо ви не впевнені, що хочете звернутися саме до тих, хто бере участь в обговоренні теми, почніть нову тему.

Спростіть посилку відповіді

Завершення питання фразою "Відповідь, будь ласка, надсилайте на адресу ..." робить отримання відповіді дуже малоймовірним. Якщо у вас немає пари секунд на те, щоб правильно поставити заголовок Reply-To в своїй поштовій програмі, то у нас немає і пари секунд на те, щоб подумати про вашу проблему. Якщо ваша поштова програма не дозволяє це зробити - викиньте її. Якщо ваша операційна система не підтримує поштові програми, що дозволяють це зробити, пошукайте операційну систему краще.

Просити відповідати по електронній пошті в Web-форумах - вкрай неввічливо, якщо тільки ви не впевнені, що інформація може виявитися конфіденційної (і хтось, з невідомих причин, захоче повідомити її вам особисто, а не всьому форуму). Якщо ви хочете отримати повідомлення поштою про те, що хтось відповів на тему в форумі, запитайте це повідомлення у інтерфейсі Web-форуму; ця можливість підтримується практично скрізь у вигляді опцій "watch this thread" ( "стежити за обговоренням"), "send email on answers" ( "повідомляти поштою") і т.п.)

Пишіть зрозумілою мовою, дотримуючись правил граматики і лексики

Експериментальним шляхом встановлено, що люди, які пишуть неуважно і недбало, зазвичай так само неуважні і недбалі в думках і в коді створюваних програм (по крайней мере, досить часто, щоб впевнено так стверджувати). Відповідати на питання людей неуважних і недбало мислячих - заняття невдячне; ми свого часу краще витратимо на щось інше.

Тому чіткість і правильність формулювання питання має значення. Якщо ви не хочете морочити собі цим голову, ми не хочемо морочити голову собі, приділяючи увагу таким питанням. Постарайтеся сформулювати питання правильною мовою. Він не повинен бути великоваговим і формальним - насправді, в хакерській культурі цінується неформальний, повний сленгу і гумору мова, яка використовується правильно. Але думки повинні бути виражені чітко; необхідно продемонструвати хоч якісь ознаки вдумливості і уваги.

Дотримуйтесь правил синтаксису, пунктуації та використання великих літер. Не плутайте "its" з "it's", "loose" з "lose" або "discrete" з "discreet". Чи не ПИШІТЬ ВСЕ В верхньому регістрі, - це сприймається як крик і вважається грубістю. (Якщо все написано в нижньому регістрі, - не набагато краще, оскільки так складно читати. Алану Коксу це прощається, а вам - ні.)

У загальному випадку, якщо ви пишете на рівні дитячого белькотіння або марення божевільного, ваше запитання, швидше за все, проігнорують. Писанина в стилі малолітніх "хацкери" (в оригіналі - l33t script kiddie hax0r - прим. Перекладача) - абсолютно безнадійна, і гарантує у відповідь - тишу (або, в кращому випадку, порцію зневаги і сарказму).

Якщо ви задаєте питання в форумі, де використовується не рідний для вас мову, то деякі лексичні і граматичні помилки вам пробачать - але ніякого прощення елементарну лінь не чекайте (так, ми зазвичай здатні зрозуміти різницю). Крім того, якщо не знаєте точно, які мови для адресата - рідні, пишіть по-англійськи. Зайняті хакери зазвичай просто пропускають питання на мовах, які вони не розуміють, а англійська - робоча мова Internet. Поставивши запитання по-англійськи, ви зменшуєте ймовірність, що його пропустять, не читаючи.

Надсилайте питання у всьому зрозумілих форматах

Якщо ви штучно утрудняєте читання питання, збільшується ймовірність, що замість нього дадуть відповідь на питання, який прочитати не складно. Тому:

  • Надсилайте повідомлення у вигляді звичайного тексту, а не в форматі HTML. ( Відключити HTML не так вже й складно.)

  • MIME-додатки зазвичай цілком припустимі, але тільки якщо вони мають реальний зміст (наприклад, додається вихідний текст або файл виправлень), а не просто автоматично генеруються поштовим клієнтом (бувши, наприклад, ще одну копію листа, але в форматі HTML).

  • Не посилайте повідомлення, в яких абзаци представлені одним рядком, візуально переносячи на наступні рядки на клієнті. (Це ускладнює відповідь на частину повідомлення.) Виходите з припущення, що адресати будуть читати повідомлення на текстових терміналах з рядками в 80 символів, і налаштуйте відповідно вставку жорстких переносів рядків, завершуючи рядок до 80 позиції.

  • При цьому, однак, не розбивайте на кілька рядків по фіксованій позиції дані (наприклад, дампи журналів або записи сеансів). Дані необхідно включати в повідомлення як вони є, одержувачі повинні бути впевнені, що вони бачать саме те, що бачили ви.

  • Не посилайте повідомлення в кодуванні MIME Quoted-Printable в англомовний форум. Це кодування може знадобитися при посилці повідомлення мовою, яка не покривається кодуванням ASCII, але багато користувальницькі поштові агенти її не підтримують. Читати повідомлення з розкиданими по тексту керуючими символами виду = 20 незручно і неприємно.

  • Навіть і не думайте, що хакери зможуть прочитати документи в закритих, патентованих форматах типу Microsoft Word або Excel. Більшість хакерів реагують на них приблизно так, як реагували б ви, якби вам вимазали вхідні двері поросячьим лайном. Навіть коли вони можуть їх прочитати, необхідність возитися з цими форматами їх обурює.

  • При посилці повідомлення з машини під керуванням Windows, вимкніть дебільну Microsoft-івську підтримку "Smart Quotes". Це дозволить позбутися від безлічі сміттєвих символів, розкиданих по всьому повідомленням.

  • У Web-форумах не зловживайте "смайликами" і можливостями вставки "html" (якщо вони надаються). Один-два смайлика - це, звичайно, нормально, але різнокольоровий забавний текст наводить людей на думку, що ви - ламер. Надмірне використання смайликів, кольору і шрифтів представляє вас як сміхотливу дівчинку-підлітка, що не має сенсу, якщо звичайно вас цікавлять відповіді, а не секс.

При використанні поштового клієнта з графічним інтерфейсом, (наприклад, Netscape Messenger, MS Outlook і їм подібних) пам'ятайте, що він може порушувати ці правила при використанні стандартних установок. У більшості таких клієнтів в меню є команда типу "View Source". Перевірте з її допомогою по одному з відправлених повідомлень, що надсилається звичайний текст, без зайвого сміття.

Точно і детально опишіть проблему

  • Уважно і чітко опишіть симптоми виявленої проблеми або помилки.

  • Опишіть середовище, в якій вона виникає (машина, ОС, додаток і т.д.) Вкажіть дистрибутив і реліз (наприклад: "Fedora Core 2", "Slackware 9.1" і т.п.).

  • Опишіть проведене вами дослідження при спробах зрозуміти проблему перш, ніж задавати питання.

  • Опишіть самостійно виконані вами кроки з діагностики та ізоляції проблеми перш, ніж задавати питання.

  • Опишіть останні зміни в конфігурації комп'ютера або програмного забезпечення, які можуть мати відношення до справи.

Зробіть максимум можливого, щоб передбачити потенційні питання хакера і заздалегідь на них відповісти у своєму зверненні по медичну допомогу.

Саймон Тетхем (Simon Tatham) написав чудове есе під заголовком Як ефективно повідомляти про помилки . Я настійно рекомендую його прочитати.

Обсяг ще не означає точність

Будьте точні і інформативні. Для цього недостатньо просто вставити в запит великий обсяг коду або даних. Якщо є великий, складний тестовий випадок, що приводить до помилки в програмі, постарайтеся максимально скоротити його.

Це корисно, як мінімум, з трьох причин. Перша: продемонстровані зусилля зі спрощення питання підвищують ймовірність отримання відповіді. Друга: спрощення питання підвищує ймовірність отримання корисного відповіді. Третя: в ході уточнення повідомлення про помилку ви самі можете знайти рішення або спосіб вирішити цю проблему.

Чи не затверджуйте, що знайшли помилку

При виникненні проблем з тим чи іншим програмним забезпеченням заявляйте, що знайшли помилку, якщо тільки абсолютно не впевнені в цьому. Підказка: якщо ви не можете надати виправлення вихідного коду, яке вирішує проблему або тестовий приклад для попередньої версії, що демонструє неправильну поведінку, ви, швидше за все, недостатньо впевнені в своїй заяві.

Пам'ятайте, що безліч інших користувачів з такою проблемою не стикалися. Інакше ви б вже дізналися про це при читанні документації або при пошуку в Web (ви ж зробили це, перш ніж робити подібні твердження, чи не так ?). Це означає, що, швидше за все, саме ви щось робите неправильно, а не програмне забезпечення.

Творці програмного забезпечення докладають величезних зусиль для того, щоб воно працювало якомога краще. Якщо ви стверджуєте, що знайшли помилку, то, тим самим, припускаєте, що вони зробили щось не так, і це майже напевно їм не сподобається - навіть якщо ви маєте рацію. Особливо недипломатичним буде написати "bug" ( "Помилка") в рядку теми повідомлення.

Коли задаєте питання, краще описувати проблему, виходячи з припущення, що ви робите щось не так, навіть якщо ви особисто абсолютно впевнені, що знайшли помилку. Якщо це дійсно помилка, ви прочитаєте про це у відповіді. Намагайтеся вести себе так, щоб займаються підтримкою програми люди захотіли вибачитися перед вами, якщо виявлена ​​реальна помилка, а не щоб вам довелося вибачатися за свою безглуздість.

Публічне самоприниження не замінює виконання домашніх завдань

Деякі, усвідомивши, що не треба вести себе грубо або гордовито, вимагаючи відповідь, вибирають протилежну крайність - самоприниження. "Я знаю, я початківець, невдаха і повний чайник, але ...". Це відволікає від суті і не має сенсу. Особливо в поєднанні з невизначеністю в описі фактичної проблеми.

Не витрачайте свій час, і наше, сподіваючись на жалість. Уявіть краще факти і своє питання якомога ясніше. Так ви заявите про себе набагато краще, ніж шляхом самоприниження.

Іноді в Web-форумах є окремі місця для запитань початківців. Якщо ви відчуваєте, що таке питання може задати тільки початківець користувач, задавайте його саме там. Але і там не треба принижуватися.

Описувати симптоми проблеми, а не свої припущення

Марно повідомляти хакерам свою думку про причини проблеми. (Якщо ваші діагностичні теорії настільки цінні, чи треба звертатися за допомогою до інших?) Тому перевірте, що повідомляєте фактичні симптоми того, що відбувається, а не свої інтерпретації та теорії. Нехай інтерпретацією і діагностикою займуться відповідають.

нерозумно:

Я постійно отримую помилки SIG11 при компіляції ядра, і підозрюю, що причина - мікротріщина на материнській платі. Як найкраще це перевірити?

розумно:

На зібраному мною комп'ютері K6 / 233 на материнській платі FIC-PA2007 (чіпсет VIA Apollo VP2) з 256MB пам'яті Corsair PC133 SDRAM починають часто виникати помилки SIG11 приблизно через 20 хвилин після включення живлення, в ході компіляції ядра, але вони не виникають в перші 20 хвилин. Перезавантаження ні до чого не призводить, а ось відключення на ніч допомагає. Заміна всієї пам'яті не допомогла. Відповідна частина результатів типовою компіляції додається.

Описувати симптоми проблеми в хронологічному порядку

Найбільш важлива інформація для з'ясування причин того, що відбувається часто пов'язана з безпосередньо попередніми цієї ситуації подіями. Тому необхідно точно описати, що ви робили, і що робила машина аж до виникнення проблеми. У разі роботи з інтерфейсом командного рядка дуже може допомогти запис сеансу (наприклад, за допомогою утиліти script) і включення в повідомлення пари десятків відповідних рядків.

Якщо програма, в якій стався збій, має опції діагностики (наприклад, -v - детальне інформування), спробуйте підібрати опції, що додають корисну зневадження в "стенограму" сеансу.

Якщо запис вийшла досить довгою (більше сторінки), має сенс заздалегідь сформулювати проблему на початку, а потім вказати хронологічну послідовність дій, до неї призводять. В цьому випадку хакери будуть знати, на що звернути увагу при читанні сеансу.

Описувати мета, а не окремий крок

Якщо ви намагаєтеся розібратися, як що-небудь зробити (а не повідомляєте про помилку), починайте з опису мети. І тільки потім потрібно описувати конкретний крок на шляху до неї, який ви не змогли виконати.

Найчастіше люди, яким необхідна технічна допомога, мають на думці високорівневу мета і прив'язуються до одного з можливих, на їхню думку, шляхів її досягнення. Вони просять допомогти виконати один крок, не віддаючи собі звіту в тому, що вибрали невірний шлях. Щоб розібратися в цьому, може знадобитися багато зусиль.

нерозумно:

Як змусити діалог вибору кольору в програмі FooDraw сприймати шестнадцатеричное RGB-значення?

розумно:

Я намагаюся замінити таблицю кольорів в зображенні потрібними мені значеннями. Зараз я бачу тільки один спосіб зробити це - редагуючи кожен слот таблиці, але я не можу поставити шестнадцатеричное RGB-значення в діалозі вибору кольору програми FooDraw.

Друга версія питання - розумна. Вона дозволяє отримати відповідь, в якому буде запропоновано засіб, більш підходяще для вирішення завдання.

Не просіть відповідати на особисту адресу електронної пошти

Хакери вважають, що рішення проблем має бути загальнодоступним, прозорим процесом, в ході якого перша спроба знайти відповідь може і повинна бути виправлена, якщо хтось, більш знає, помітить, що ця відповідь - неповний або некоректний. Крім того, відповідальні частково винагороджуються тим, що їх компетентність і знання будуть помічені колегами.

Коли ви просите особистого відповіді, ви заважаєте як процесу вироблення рішення, так і отримання винагороди. Не робіть цього. Відповідати особисто - це вибір відповідає, - і якщо він так і робить, то зазвичай тому, що вважає питання занадто невдало сформульованим або очевидним, щоб бути цікавим іншим.

З цього правила є одне невелике виключення. Якщо ви припускаєте, що на своє питання отримаєте безліч подібних між собою відповідей, не забудьте магічні слова "пошліть відповідь мені, а я резюмую отримані відповіді в статті для дискусійною групи". Спроба уберегти дискусійну групу або список розсилки від потоку, по суті, ідентичних повідомлень - це дуже люб'язно, але ви повинні стримати обіцянку і послати підсумкове резюме.

Задавайте ясні і чіткі питання

Необмежені питання вимагають зазвичай необмеженого часу для відповіді. Люди, швидше за все здатні дати вам корисний відповідь, ще й самі зайняті люди (ще й тому, що більшу частину своєї роботи роблять самі). Такі люди ревно ставляться до свого часу, і тому часто не сприймають необмежені питання.

Імовірність отримання корисного відповіді підвищується, якщо ви чітко даєте зрозуміти, чого домагаєтеся від відповідальних (надати посилання, послати код, перевірити ваше рішення і т.п.). Це сконцентрує зусилля відповідають і неявно задасть обмеження за часом і зусиллям, які доведеться витратити відповідає, щоб вам допомогти. Це добре.

Щоб зрозуміти, в якому світі живуть експерти, треба ставитися до знань експертів, як до ресурсу рясного, а до їх часу - як до ресурсу досить обмеженої. Чим менше часу ви неявно вимагаєте, тим більше ймовірно отримання відповіді від дійсно гарного і зайнятого експерта.

Тому має сенс обмежити питання, щоб звести до мінімуму час, необхідний експерту для його вирішення. Але найчастіше це не те ж саме, що спростити питання. Так, наприклад, питання: "Чи можете ви дати мені посилання на хороший опис X?" - зазвичай куди розумніше, ніж прохання: "Поясніть мені X, будь ласка". Якщо у вас проблема з непрацюючим кодом, розумніше буде попросити пояснити, що в ньому не так, а не просити виправити помилки.

Не ставте питання з домашніх завдань

Хакери добре вміють відповідати на питання з домашніх завдань - більшість з нас їх робило самостійно. Ці питання задані для роботи вам, щоб ви могли навчитися на власному досвіді. Просити можна про підказкою, але не про повне вирішення.

Якщо ви підозрюєте, що вам підкинули питання з домашнього завдання, але все одно не можете дати на нього відповідь, спробуйте задати питання в форумі групи користувачів або (в крайньому випадку) в "призначеному для користувача" списку розсилки / форумі відповідного проекту. Хоча хакери його і "впізнають", деякі з просунутих користувачів можуть, по крайней мере, дати вам підказку.

Уникайте безглуздих прохань

Не піддавайтеся спокусі завершити свій запит безглуздими питаннями виду: "Чи не допоможе мені хто-небудь?" або "Чи є взагалі відповідь?" По-перше, якщо ви хоч скільки-небудь компетентно описали свою проблему, подібні додаткові питання, як мінімум, зайві. По-друге, оскільки вони зайві, хакерам вони здаються надокучливими - і у відповідь їх так і підбиває написати логічно бездоганну відписку типу: "Так, допомогти вам можна" або "Ні, вам вже нічим не допоможеш".

У загальному випадку, питання з відповідями так-ні краще не ставити, якщо тільки ви не хочете отримати відповідь так-або-ні .

Чи не позначайте своє питання як "Строковий", навіть якщо для вас він саме такий

Це ваша проблема, а не наша. Згадка про терміновість часто контрпродуктивно: більшість хакерів просто видаляє такі повідомлення як грубі і егоїстичні спроби терміново привернути до себе особливу увагу.

З цього правила є одне часткове виключення. Згадка про терміновість може мати сенс, якщо ви використовуєте програму в серйозній організації, яка може зацікавити хакерів; в такому випадку, якщо вам не вистачає часу і ви повідомите про це ввічливо, люди можуть виявитися досить зацікавленими, щоб відповісти швидше.

Так робити, однак, - вкрай ризиковано, тому що точка зору хакера на серйозність і його інтереси, ймовірно, відрізняються від ваших. Питання з міжнародної космічної станції, наприклад, викличе інтерес, а ось питання від імені процвітаючого благодійного фонду або політичної партії, майже напевно, - немає. Фактично, питання з темою "Терміново: Допоможіть мені врятувати пухнастих тюленя!" буде проігнорований або злобно прокоментований навіть тими хакерами, які вважають, що життя пухнастих тюленя має для них значення.

Якщо це вас дивує, перечитуйте весь інший документ до тих пір, поки не зрозумієте, а до того утримайтеся від посилки питань взагалі.

Ввічливість ніколи не зашкодить, і іноді допомагає

Будьте ввічливі. Використовуйте фрази "Будь ласка" і "Заздалегідь вдячний". Дайте зрозуміти, що вдячні людям, безкоштовно присвячуються вам свого часу.

Якщо чесно, це не так важливо, як відсутність помилок в тексті питання, ясність, точність і детальність опису, використання відкритих форматів і т.д. (І не замінює все перераховане); хакери, в загальному випадку, вважали за краще б отримувати грубі, але технічно точні повідомлення про помилки, ніж ввічливе словоблуддя. (Якщо вас це дивує, згадайте, що ми цінуємо питання за те, чого він нас вчить.)

Однак при нормальному технічному рівні питання ввічливість дійсно підвищує ймовірність отримати корисний відповідь.

(Необхідно відзначити, що єдине серйозне заперечення, отримане на цей документ від ветеранів хакерського руху, пов'язане з рекомендацією використовувати фразу "Заздалегідь вдячний". Деякі хакери вбачають в ній небажання дякувати кого б то не було після того, як проблема буде вирішена. Ми рекомендуємо дякувати і заздалегідь, і після отримання відповіді, або висловити свою подяку по-іншому, скажімо, фразою "Спасибі за увагу" або "Спасибі за розгляд".)

Пошліть короткий опис рішення

Після того, як проблема вирішена, пошліть повідомлення всім, хто вам допоміг; дайте їм знати, чим все закінчилося, і подякуйте ще раз за допомогу. Якщо проблема викликала загальний інтерес в списку розсилки або розмовної кімнати, має сенс таке повідомлення послати туди.

Оптимально буде відповісти в нитки обговорення, розпочатої з вихідного питання, додавши в темі повідомлення позначку 'FIXED', 'RESOLVED', 'РІШЕННЯ' або інший не менш очевидна ознака рішення. У списках розсилки з великою кількістю повідомлень, потенційний відповідає при погляді на нитку обговорення "Проблема X", що завершується повідомленням "Проблема X - РІШЕННЯ" розуміє, що йому не потрібно витрачати час навіть на читання повідомлень (якщо він особисто не вважає Проблему X цікавою) , і тому може витратити час на рішення іншої проблеми.

Таке повідомлення не обов'язково має бути довгим і докладним; просте: "Привіт! Проблема була пов'язана з розривом в мережевому кабелі! Спасибі всім. Білл", - вже краще, ніж нічого. Фактично, короткий і ввічливе резюме краще, ніж довга дисертація, якщо тільки рішення не зачіпає серйозні технічні аспекти. Напишіть, які дії дозволили вирішити проблему, але всю послідовність пошуку рішення повторно описувати не треба.

Для досить серйозних проблем можна послати резюме з історією пошуку їх причин. Опишіть остаточну постановку проблеми. Опишіть, яким виявилося рішення, і вкажіть тупикові шляхи, яких варто уникати. Назвіть всіх, хто допоміг вам: так ви знайдете собі друзів.

Крім прояви ввічливості і інформування, такого роду резюмуюче повідомлення допоможе іншим при пошуку в архівах списку розсилки / дискусійною групи / форуму точно дізнатися, яке рішення допомогло вам, і, отже, може допомогти і їм.

Останнє, але важливе, - такого роду повідомлення допомагає всім які брали участь в обговоренні отримати почуття задоволення від того факту, що проблема закрита. Якщо ви самі - не технічний фахівець і не хакер, просто повірте нам, що це почуття дуже важливо для гуру та експертів, до яких ви зверталися за допомогою. Описи проблем, так в підсумку і не вирішених - це суцільне розчарування; хакери жадають побачити їх вирішеними. Гарна карма, що виникає, коли ви задовольняєте цю спрагу, дуже допоможе вам при завданні питання в наступний раз.

Подумайте, як ви можете запобігти виникненню такої ж проблеми у інших користувачів в майбутньому. Запитайте себе, чи допоможе зміна документації або списку ЧаВО, і якщо так - пошліть відповідну зміну тим, хто підтримує ці документи.

Серед хакерів така поведінка, насправді, вважається важливіше звичайної ввічливості. Саме так заробляють репутацію хорошого командного гравця, яка є дуже цінною якістю.

Як інтерпретувати відповіді

RTFM і STFW: як зрозуміти, що ви серйозно облажались

Є стародавня і священна традиція: якщо ви отримуєте відповідь "RTFM", значить, що відповідає думає, що вам варто почитати керівництво (Read The Fucking Manual). Він майже напевно має рацію. Читайте.

У відповіді RTFM є молодший аналог. Якщо ви отримуєте відповідь "STFW", значить, що відповідає думає, що вам варто пошукати відповідь в мережі (Search The Fucking Web). Він майже напевно має рацію. Шукайте.

У Web-форумах вам ще можуть запропонувати пошукати в архівах форуму. Фактично, відповідальний може виявитися настільки люб'язний, що дасть посилання на попереднє обговорення, в якому ця проблема була вирішена. Але не сподівайтеся на це; пошукайте в архівах самі, перш ніж питати.

Часто той, хто посилає один з подібних відповідей, має під рукою керівництво або web-сторінку з необхідною вам інформацією, і дивиться на неї, коли набирає відповідь. Ці відповіді означають, що, на його думку, по-перше, необхідну вам інформацію легко знайти і, по-друге, ви більшого навчитеся при пошуку інформації, ніж якщо вам її піднесуть під ніс на тарілочці.

Вас це не повинно обурювати; з хакерських стандартам, він надав вам достатню повагу вже тим, що не проігнорував питання. Ви повинні подякувати відписав за його батьківську доброту.

Якщо ви не зрозуміли ...

Якщо ви не зрозуміли відповідь, що не шліть тут же вимога його пояснити. Використовуйте ті ж джерела інформації, що і при пошуку відповіді на вихідний питання (керівництва, ЧаВО, Web, досвідчені колеги), щоб зрозуміти відповідь. Якщо і після цього вам необхідні роз'яснення, покажіть, що ви дізналися самі.

Наприклад, припустимо, я вам відповів: "Схоже, у вас завис zentry; треба перевірити". Тоді поганим уточнюючим запитанням буде: "А що таке zentry"? А хорошим: "OK, я прочитав сторінку довідкового керівництва, і про zentry там згадано тільки в опціях -z і -p. У жодній з них не сказано, як скинути завислий zentry. Чи треба використовувати одну з цих опцій, або я що -то неправильно зрозумів? "

Реакція на грубість

Велика частина того, що може здатися грубістю, в хакерських колах використовується не для образи. Це, скоріше, наслідок безпосереднього, без натяків, стилю спілкування, природного для людей, що намагаються вирішувати проблеми, а не здаватися іншим м'якими і пухнастими.

Коли зустрічаєтеся з грубістю, постарайтеся реагувати спокійно. Якщо хтось дійсно виходить за рамки допустимого, цілком ймовірно, що ведучий списку розсилки, дискусійною групи або форуму поставить його на місце. Якщо цього не відбулося і ви вийдете з себе, цілком ймовірно, що стало причиною цього особа поводиться в рамках норм хакерського співтовариства, і всі будуть вважати, що саме ви не праві. Це істотно знизить шанси отримання необхідної інформації або допомоги.

З іншого боку, іноді можна зустрітися з грубістю і викликом, що не мають ніяких видимих ​​підстав. Зворотний бік цієї медалі в тому, що така реакція є цілком прийнятною формою постановки на місце дійсних грубіянів, - ми відкидаємо їх негідну поведінку гостро відточеним словесним скальпелем. Однак ви повинні бути дуже впевнені в своїй позиції, перш ніж намагатися цим зайнятися. Грань між зазначенням на неввічливість і початком безглуздого "базару" (в оригіналі - flamewar - прим. Перекладача) настільки тонка, що і самі хакери нерідко її переходять. Якщо ви - новачок або просто випадковий читач, шансів уникнути такої грубої помилки трохи. Якщо вас цікавить інформація, а не розвага, краще приберіть руки з клавіатури і не ризикуйте вступати в подібні дискусії.

(Деякі наполягають, що багато хакерів страждають м'якою формою аутизму, або синдрому Аспергера , і у них просто не вистачає тієї частини мозку, яка відповідає за "нормальне" соціальна взаємодія між людьми. Можливо, це правда, а може і ні. Якщо ви - НЕ хакер, уявлення про хакерів як про хворих на голову може вам допомогти змиритися з нашими дивацтвами. Думайте, що хочете. нас це не хвилює; нам подобається бути саме такими, і до клінічних діагнозів ми ставимося зі здоровим скептицизмом.)

У наступному розділі ми поговоримо про іншу проблему; про свого роду "грубості", з якої можна зустрітися, коли саме ви не праві.

Не реагуйте як невдаха

Цілком ймовірно, що ви вже облажались кілька разів в хакерських форумах - так, як описано в цій статті, або аналогічно. І вам вже пояснили, як саме ви облажались, можливо, в фарбах. При всьому чесному народі.

Коли таке відбувається, найбільш невдала реакція - скаржитися на те, що трапилося, вважати себе ображеним словесно, вимагати вибачень, волати, задихатися від гніву, подавати позови до суду, скаржитися роботодавцям кривдників, не опускати за собою сидіння унітазу і т.п. Замість усього цього треба зробити наступне:

Змиритися. Це нормально. Насправді, це добре і доцільно.

Громадські норми не підтримують себе самі - їх підтримують люди, активно, відкрито, публічно ці норми застосовують. Не думайте, що критикувати повинні тільки в особистому листуванні - це не так. Не має сенсу приймати як особисту образу чийсь коментар, що одне з ваших тверджень - помилково, або що у нього є інша думка. Так діють невдахи.

Були хакерські форуми, де, виходячи з неправильно понятий гіпертрофованої ввічливості, учасникам заборонялося посилати повідомлення про помилки в чужих повідомленнях. Їм було сказано: "Якщо не хочете допомогти користувачеві, мовчіть". Відтік знають учасників до інших форумів привів до їх виродження в безглузду балаканину і до повної марності з технічної точки зору.

Вибирайте: перебільшена "дружність" (такого роду) або корисність.

Пам'ятайте: коли цей хакер пише, що ви облажались, і (не важливо, наскільки грубо) просить вас більше так не робити, він робить це, коли журиться, по-перше, про вас, а по-друге, про своїй спільноті. Йому було б набагато простіше вас проігнорувати і викреслити зі свого життя. Якщо вас не вистачає на подяку, збережіть гідність, - не нарікайте, і не думайте, що з вами будуть звертатися як з тендітної лялькою лише тому, що ви - новачок з театрально гіперчутливою душею і ілюзіями про власну значимість.

Іноді люди будуть переходити на особистості, вступати в брудну полеміку без видимої причини і т.д., навіть якщо ви і не облажались (або облажались тільки в їхній уяві). Обурюватися в цьому випадку, - спосіб дійсно облажався.

Ці "скандалісти" - або ламери, які нічого не розуміють, але вважають себе експертами, або потенційні психологи, перевіряючі, облажався ви чи ні. Інші читачі їх або проігнорують, або знайдуть способи самостійно з ними розібратися. Поведінка скандалістів створює проблеми для них самих, що не повинно вас турбувати.

Не дозволяйте також втягнути себе в даремний "базар". Такі обговорення краще ігнорувати, розібравшись попередньо, що це дійсно даремний "базар", а не натяки на те, чому ви дійсно облажались, і не тонко зашифровані відповіді на ваші фактичні питання (так теж буває).

Питання, які задавати не треба

Ось ряд класичних дурних питань і про що думають хакери, коли на них не відповідають.

питання:

Де можна знайти програму або ресурс X?

відповідь:

Там же, де і я її взяв, придурок, - знайти в Internet. Боже, невже ще не всі знають, як користуватися Google ?

питання:

Як можна за допомогою X зробити Y?

відповідь:

Якщо ви хочете зробити Y, треба так і питати, не припускаючи заздалегідь використання методу, який може зовсім не підходити. Питання такого виду часто задають ті, хто не просто нічого не знає про X, але збитий з пантелику вирішуваною проблемою Y і занадто сконцентрований на деталях своєї конкретної ситуації. Зазвичай краще ігнорувати таких людей, поки вони не сформулюють свою проблему краще.

питання:

Як настроїти запрошення командного інтерпретатора?

відповідь:

Якщо ви досить розумні, щоб цим зацікавитися, вам вистачить розуму і на самостійний пошук відповіді.

питання:

Чи можна перетворити AcmeCorp-документ в TeX-файл за допомогою програми перетворення файлів Bass-o-matic?

відповідь:

Спробуйте і ви пізнаєте. Так ви, по-перше, дізнаєтеся відповідь, а, по-друге, перестанете витрачати мій час.

питання:

Моя {програма, конфігурація, мій оператор SQL} не працює

відповідь:

Це взагалі не питання, і я не збираюся ставити ще десяток навідних запитань, щоб з'ясувати, в чому насправді полягає ваша проблема - у мене є справи і цікавіше. Коли я бачу подібні питання, то зазвичай посилаю один з наступних відповідей:

  • Вам до цього більше нічого додати?

  • Ой, це дуже погано. Сподіваюся, ви вже це виправили.

  • І яке це має відношення особисто до мене?

питання:

У мене проблеми з Windows-машиною. Чи не могли б ви допомогти?

відповідь:

Так. Викиньте цей Microsoft-івської сміття і поставте собі операційну систему з відкритим вихідним кодом, наприклад, Linux або BSD.

Примітка: ви можете задавати питання, пов'язані з Windows-машинами, якщо вони відносяться до програми, що має офіційну версію для Windows, або взаємодіє з машинами під Windows (наприклад, Samba). Просто не дивуйтеся відповіді, що проблема - в Windows, а не в самій програмі, тому що Windows - настільки "крива" в цілому, що найчастіше саме так і буває.

питання:

Моя програма не працює. Я думаю, проблема в системному компоненті X.

відповідь:

Хоча і можливо, що саме ви першим виявили очевидну помилку в системних викликах і бібліотеках, інтенсивно використовуваних сотнями або тисячами розробників, але набагато ймовірніше, що ви просто не розібралися. Серйозні твердження вимагають серйозних доказів; якщо ви робите подібні твердження, їх треба підкріплювати точній і повній формі описом ситуації, в якій виникає збій.

питання:

У мене виникли проблеми з установкою Linux (або X). Чи не могли б ви допомогти?

відповідь:

Ні. Щоб вирішити цю проблему, мені потрібен безпосередній доступ до вашого комп'ютера. Задайте питання місцевої групі користувачів Linux, які зможуть допомогти особисто. (Список груп користувачів можна знайти тут .)

Примітка: питання про встановлення Linux можуть бути доречними в форумі або списку розсилки, присвяченому конкретному дистрибутива, якщо проблема пов'язана з цим дистрибутивом, або в форумах локальних груп користувачів. В цьому випадку, не забудьте точно описати подробиці збою. Але спочатку ретельно пошукайте в Web, вказавши ключові слова "linux" і все підозрілі компоненти обладнання.

питання:

Як зламати пароль користувача root / отримати розширені привілеї / прочитати чужу електронну пошту?

відповідь:

Та ти просто пошляк, раз хочеш таке зробити, і ідіот, раз просиш хакера тобі допомогти.

Хороші і погані питання

Нарешті, я збираюся показати на прикладах, як правильно ставити запитання. Я представлю пару питань про одну й ту ж проблему, один - заданий нерозумно, а другий - правильно.

Нерозумно: Де мені знайти інформацію про Foonly Flurbamatic?

Це питання просто напрошується на відповідь "STFW" .

Правильно: Я спробував пошукати в Web за допомогою Google за запитом "Foonly Flurbamatic 2600", але корисних посилань не отримав. Чи не знає хто-небудь, де знайти інформацію про програмуванні цього пристрою?

Цей запитує вже пошукав в Web і, схоже, у нього - реальна проблема.

Нерозумно: Я не можу скомпілювати код проекту foo. Чому він не є коректним?

Він думає, що хтось інший облажався. Самовпевнений тип.

Правильно: Код проекту foo НЕ компілюється в ОС Nulix версії 6.2. Я прочитав ЧаВО (FAQ), але там немає нічого про проблеми з Nulix. Ось запис сеансу компіляції; що я зробив неправильно?

Він вказав середу, прочитав часто задають питання, показав повідомлення про помилку, і він не думає, що причина його проблеми в помилку когось іншого. Цьому хлопцю можна приділити трохи уваги.

Нерозумно: У мене проблеми з материнською платою. Чи не може хто-небудь допомогти?

Будь-хакер на таке питання в розумі відповість, швидше за все так: "Добре. Може, тобі ще допомогти відригнути і пелюшку поміняти?", І натисне клавішу Delete.

Правильно: Я спробував X, Y і Z на материнській платі S2464. Коли це не спрацювало, я спробував A, B і C. Зверніть увагу на дивний симптом при спробі зробити C. Очевидно, що ця фігня НЕ фуричіт, але результати виходять непередбачувані. Що зазвичай призводить до того, що ні фуричат багатопроцесорні материнські плати з Athlon? Чи немає у кого ідей для додаткових тестів, які допоможуть ізолювати проблему?

Цей товариш, навпаки, здається, гідний відповіді. Він продемонстрував здатність вирішувати проблеми, а не просто чекає, поки відповідь впаде йому з неба.

В останньому питанні зверніть увагу на невелику, але важливу різницю між "Дайте мені відповідь" і "Будь ласка, допоможіть розібратися, які додаткові діагностичні дії можна виконати, щоб прояснити ситуацію".

Фактично, форма завдання останнього питання дуже схожа на використану реально в серпні 2001 року в списку розсилки linux-kernel. Я (Ерік) поставив тоді це питання. Я спостерігав дивні зависання на материнській платі Tyan S2464. Учасники списку розсилки надали цінну інформацію, яка дозволила мені від цих зависань позбутися.

Ставлячи питання так, як це зробив я, ви даєте людям їжу для роздумів; я зробив для них участь у вирішенні проблеми простим і привабливим. Я продемонстрував повагу здібностей колег і запросив їх до обговорення на рівних. Я також продемонстрував, що ціную їх час, описавши, по яким тупиковим гілкам я вже пройшов.

В кінцевому підсумку, коли я подякував усім і підкреслив, наскільки добре пройшов процес вирішення проблеми, один з учасників списку розсилки звернув увагу на те, що, на його думку, все вийшло не тому, що я - "відома людина" в цьому списку, а через правильної форми постановки питання.

Хакери, в певному відношенні, дуже жорстока інтелектуальна еліта (в оригіналі - meritocracy . Прим. Перекладача). Я впевнений, що він має рацію, і якби я облажався, то був би розкритикований або проігнорований, незалежно від колишніх заслуг. Його пропозицію описати ситуацію як інструкції для всіх інших стало безпосередньою причиною складання цього керівництва.

Якщо відповіді не отримано

Якщо ви не отримали відповіді, не беріть це на свій рахунок, як наш відмова допомогти особисто вам. Іноді учасники форуму просто не знають відповідь. Відсутність відповіді не рівносильно ігнорування, хоча ззовні різницю помітити складно.

У загальному випадку, повторна посилка питання - не найкраща ідея. Це буде сприйнято як безглузда надокучливість.

Є й інші джерела допомоги, до яких можна звернутися, причому часто більш пристосовані до потреб початківців.

Існує безліч груп користувачів в мережі і на місцях, з ентузіазмом займаються програмним забезпеченням, хоча багато їхніх учасників в житті не написали жодної серйозної програми. Ці групи часто формуються для того, щоб учасники допомагали один одному і новим користувачам.

Є також маса комерційних компаній, з яким можна укласти контракт на підтримку, як великих, так і маленьких (одні з найбільш відомих - Red Hat і Linuxcare, але є і безліч інших). Нехай вас не лякає ідея платити за підтримку! В кінцевому підсумку, якщо необхідний капремонт двигуна автомобіля, ви адже віддасте його в майстерню і заплатите за ремонт. Навіть якщо програмне забезпечення було легко, не можна розраховувати, що його завжди будуть безкоштовно підтримувати.

У популярного програмного забезпечення, на кшталт Linux, на одного розробника припадає, принаймні, 10000 користувачів. Одна людина просто не може впоратися з підтримкою 10000 користувачів. Пам'ятайте, що навіть якщо за підтримку доводиться платити, це все одно обходиться набагато дешевше, ніж коли доводиться купувати ще й саме програмне забезпечення (та й підтримка закритого програмного забезпечення зазвичай коштує дорожче і виконується менш компетентними фахівцями, ніж в разі програмного забезпечення з відкритим вихідним кодом).

Як давати хороші відповіді

Будьте великодушні. Пов'язаний з проблемою стрес може робити неввічливими або дурними людей, які такими не є.

На першу помилку вкажіть в приватному порядку. Немає необхідності публічно принижувати людину, яка, можливо, чесно помиляється. Початківець користувач може не знати, як шукати в архівах або де знаходиться або публікується список поширених запитань.

Якщо ви не впевнені, так і говорите! Помилковий, але авторитетно звучить відповідь гірше, ніж відсутність відповіді. Не спрямовуйте людей по хибному шляху просто тому, що вам приємно побути в ролі експерта. Будьте скромні й чесні; показуйте хороший приклад для запитувачів і колег.

Якщо не можете допомогти, не заважайте. Не жартуйте з приводу процедур, які можуть зруйнувати середу користувача - цей бовдур може прийняти ваші жарти як керівництво до дії.

Задавайте додаткові питання, щоб отримати більше інформації. Якщо це робити правильно, запитувач дещо чому навчиться, - та й ви теж. Спробуйте перетворити поганий питання в хороший; пам'ятайте - все ми були початківцями.

Хоча проста відповідь RTFM буває виправданий, коли дається просто ледареві, посилання на документацію (навіть якщо це набір ключових слів для пошуку в Google) все ж краще.

Якщо вже ви відповідаєте на питання, давайте відповідь по суті. Чи не пропонуйте наспіх придумані обхідні шляхи, якщо використовується в принципі не той засіб або невірний підхід. Пропонуйте хороші засоби. Переформуліруйте питання.

Допоможіть громадськості отримати користь з питання. Коли зустрічаєтеся з хорошим питанням, запитайте себе: "Як треба змінити відповідні документи та список ЧаВО, щоб більше це питання ніхто не ставив?". Потім пошліть відповідне доповнення того, хто підтримує ці документи.

Якщо для відповіді на питання довелося провести дослідження, поділіться своїм досвідом, а не пишіть так, як ніби відповідь звалився на вас з неба. Відповісти на один хороший питання - це як нагодувати голодного один раз, а ось викласти методику дослідження на прикладі, - значить, навчити добувати їжу на все життя.

Додаткові джерела інформації

Якщо вам необхідна інформація з основ роботи персональних комп'ютерів, ОС Unix і мережі Internet, див. У посібнику The Unix and Internet Fundamentals HOWTO .

При створенні програмного забезпечення або випуску виправлень для програм, постарайтеся слідувати принципам, викладеним у керівництві Software Release Practice HOWTO .

Подяки

Евелін Мітчел (Evelyn Mitchell) запропонувала прокоментувати ряд дурних питань і надихнула на написання розділу "Як давати хороші відповіді". Михайло Рамендік дав ряд цінних пропозицій щодо поліпшення документа.

Примітки перекладача

Оригінал статті взято звідси .