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

Цей посібник пояснює, як ефективно ставити технічні питання у спільнотах, щоб отримати розумні та швидкі відповіді. Переклад класичного есе Еріка Стівена Реймонда та Ріка Моена «How To Ask Questions The Smart Way».

Автори:

• Eric Steven Raymond Thyrsus Enterprises, esr@thyrsus.com
• Rick Moen respond-auto@linuxmafia.com

Оригінал: How To Ask Questions The Smart Way. Переклад зроблено та опубліковано згідно copying policy.

Авторські права © 2001, 2006, 2014 Eric Steven Raymond, Rick Moen

Історія ревізій
Ревізія 3.10	21 травня 2014	esr	Нова секція про Stack Overflow.

Зміст

Відмова від відповідальності

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

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

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

Вступ

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

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

Перше, що потрібно зрозуміти, — хакери насправді люблять складні проблеми і хороші, що змушують задуматися, питання про них. Якби не так, нас би тут не було. Якщо ви дасте нам цікаве питання, ми будемо вдячні; хороші питання — це стимул і подарунок. Вони допомагають нам розвивати наше розуміння і часто виявляють проблеми, які ми могли не помітити або не подумати раніше. Серед хакерів «Гарне питання!» — це сильна і щира похвала.

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

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

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

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

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

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

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

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

Перед тим, як питати

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

1. Спробуйте знайти відповідь, шукаючи в архівах форуму або списку розсилки, куди плануєте звернутися.
2. Спробуйте знайти відповідь, шукаючи в Інтернеті.
3. Спробуйте знайти відповідь, читаючи документацію.
4. Спробуйте знайти відповідь, читаючи FAQ.
5. Спробуйте знайти відповідь, оглянувши або експериментуючи.
6. Спробуйте знайти відповідь, запитавши досвідченого друга.
7. Якщо ви програміст, спробуйте знайти відповідь, читаючи вихідний код.

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

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

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

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

Остерігайтеся ставити неправильне питання. Якщо воно базується на хибних припущеннях, випадковий хакер, ймовірно, дасть буквальну, але марну відповідь, думаючи: «Дурне питання…», і сподіваючись, що досвід отримати те, що ви просили, а не те, що вам потрібно, навчить вас.

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

З іншого боку, показати, що ви готові і хочете допомагати у процесі розвʼязання проблеми, — дуже хороший початок. «Хтось може дати посилання?», «Чого бракує в моєму прикладі?» і «Який сайт варто було перевірити?» частіше отримують відповіді, ніж «Будь ласка, надішліть точну інструкцію», бо ви показуєте, що справді готові завершити процес, якщо хтось вкаже правильний напрям.

Коли ставите питання

Обирайте форум уважно

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

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

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

Перший крок — знайти правильний форум. Знову ж таки, Google і інші пошукові системи — ваші друзі. Знайдіть сторінку проекту, повʼязану з апаратним чи програмним забезпеченням, що викликає у вас труднощі. Зазвичай там є посилання на FAQ, списки розсилки і їх архіви. Ці списки — останнє місце, куди варто звертатися, якщо власні зусилля (включно з читанням FAQ) не дали результату. На сторінці проекту може бути описана процедура звітування про помилки або посилання на неї; дотримуйтесь її.

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

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

Не розсилайте одразу у всі доступні канали допомоги — це як кричати і дратує людей. Йдіть поступово.

Знайте свою тему! Класична помилка — ставити питання про Unix або Windows API у форумі, присвяченому мові програмування, бібліотеці чи інструменту, що працює на обох. Якщо ви не розумієте, чому це помилка, краще не ставте питання взагалі.

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

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

Stack Overflow

Шукайте, потім питайте на Stack Exchange.

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

Спочатку зробіть пошук у Google; він індексує Stack Exchange в реальному часі. Дуже ймовірно, що хтось уже ставив подібне питання, і сайти Stack Exchange будуть у верхній частині результатів. Якщо через Google нічого не знайшли, шукайте безпосередньо на найбільш релевантному сайті (див. нижче). Пошук за тегами допоможе звузити результати.

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

Stack Exchange налічує понад 100 сайтів, але найпопулярніші:

• Super User — питання про загальне використання компʼютерів. Якщо ваше питання не про код або програми, з якими ви працюєте лише через мережу, воно, ймовірно, сюди.
• Stack Overflow — питання про програмування.
• Server Fault — питання про адміністрування серверів і мереж.

Деякі проекти мають власні сайти, наприклад Android, Ubuntu, TeX/LaTeX, SharePoint. Перевіряйте актуальний список на сайті Stack Exchange.

Веб- та IRC-форуми

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

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

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

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

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

Другий крок — списки розсилки проекту

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

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

Якщо у проекту є і «користувацький», і «розробницький» список або форум, і ви не займаєтеся розробкою, ставте питання у «користувацькому». Не думайте, що вас там радо приймуть; розробники можуть сприймати ваше питання як шум.

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

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

Використовуйте змістовні, конкретні заголовки тем

У списках розсилки, новинних групах або веб-форумах заголовок теми — це ваш шанс привернути увагу кваліфікованих експертів у приблизно 50 символів. Не витрачайте його на балачки типу «Допоможіть мені» (особливо «ДОПОМОЖІТЬ МЕНІ!!!!»; такі повідомлення видаляються автоматично). Не намагайтеся вразити глибиною свого страждання; використовуйте цей простір для короткого опису проблеми.

Добра практика — формат «обʼєкт — відхилення». «Обʼєкт» — це те, що має проблему, а «відхилення» — опис відхилення від очікуваної поведінки.

Дурне:

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

Розумне:

X.org 6.8.1 — деформований курсор миші, відеочіпсет Fooware² MV1005

Ще розумніше:

X.org 6.8.1 — курсор миші на відеочіпсеті Fooware MV1005 деформований

Процес написання опису «обʼєкт — відхилення» допоможе вам краще організувати думки про проблему. Що саме уражено? Тільки курсор миші чи інша графіка теж? Чи це специфічно для версії X.org? Для версії 6.8.1? Для чіпсету Fooware? Для моделі MV1005? Хакер, який побачить таку тему, одразу зрозуміє, що у вас за проблема і з чим вона повʼязана.

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

Якщо ставите питання у відповіді, обовʼязково змініть тему, щоб показати, що це нове питання. Тема «Re: test» або «Re: new bug» менш ймовірно приверне увагу. Також скоротіть цитування попередніх повідомлень до мінімуму, достатнього для розуміння нових читачів.

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

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

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

Зробіть відповідь легкою

Закінчувати запитання фразою «Будь ласка, надсилайте відповідь на…» дуже ускладнює отримання відповіді. Якщо ви не хочете витрачати кілька секунд на налаштування правильного заголовка Reply-To у поштовому клієнті, ми не хочемо витрачати час на думки про вашу проблему. Якщо ваш поштовий клієнт не дозволяє цього, змініть на кращий. Якщо ваша ОС не підтримує поштові програми з такою функцією, змініть ОС.

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

Пишіть чітко, грамотно, з правильним правописом

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

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

Правильно пишіть, ставте розділові знаки, використовуйте великі літери. Не плутайте «its» і «itʼs», «loose» і «lose», «discrete» і «discreet». Не ПИШІТЬ ВЕЛИКИМИ ЛІТЕРАМИ — це вважається криком і грубістю. (Писати маленькими літерами трохи менш дратує, бо важко читати. Алан Кокс⁴ (Alan Cox) може собі це дозволити, але ви — ні.)

Загалом, якщо ви пишете як напівграмотний дурень, вас, швидше за все, ігноруватимуть. Не використовуйте скорочення з миттєвих повідомлень. Писати «you» як «u» — виглядає як напівграмотний дурень, щоб заощадити пару натискань клавіш. Ще гірше — писати як «l33t script kiddie hax0r» — це гарантовано призведе до мовчання або, в кращому разі, до насмішок і сарказму.

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

Якщо англійська — не ваша рідна мова, добре попередити про це потенційних респондентів і запропонувати варіанти:

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

Надсилайте питання у доступних, стандартних форматах

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

• Надсилайте простий неформатований текст (plain text), а не HTML. (Вимкнути HTML не складно — інструкції.)
• MIME-вкладення зазвичай прийнятні, але лише якщо це справжній контент (наприклад, вихідний файл або патч), а не просто копія вашого повідомлення.
• Не надсилайте листи, де цілі абзаци — це один довгий рядок, обгорнутий кілька разів. (Це ускладнює відповідь на частину повідомлення.) Припускайте, що ваші респонденти читають пошту на дисплеях шириною 80 символів і налаштовуйте перенесення рядків відповідно, менше 80.
• Але не переносіть дані (лог-файли, транскрипти сесій) на фіксованій ширині. Дані мають бути як є, щоб респонденти бачили те саме, що і ви.
• Не надсилайте MIME Quoted-Printable кодування в англомовні форуми. Воно потрібне для мов, які не підтримує ASCII, але багато поштових клієнтів його не підтримують. Якщо воно зламається, у тексті зʼявляться неприємні символи, які псують зміст.
• Ніколи не очікуйте, що хакери зможуть читати закриті пропрієтарні формати, як Microsoft Word чи Excel. Більшість хакерів реагують на них так само, як ви — як на купу свіжого гною на порозі. Навіть якщо можуть впоратися, вони не люблять це робити.
• Якщо надсилаєте лист з Windows, вимкніть проблемну функцію «Розумні лапки» Microsoft (Інструменти > Автозаміна > зніміть прапорець «Розумні лапки» у розділі Автоформатування під час введення). Це допоможе уникнути сміттєвих символів у листі.
• На веб-форумах не зловживайте «смайликами» і «HTML»-функціями (якщо вони є). Один-два смайлики — нормально, але кольоровий текст і шрифти роблять вас схожими на безглузду дівчинку-підлітка, що не дуже добре, якщо ви хочете відповіді, а не уваги.
• Якщо користуєтеся графічним поштовим клієнтом (Netscape Messenger, MS Outlook тощо), будьте уважні — за замовчуванням вони можуть порушувати ці правила. Більшість мають команду «Перегляд джерела». Використовуйте її, щоб перевірити, що лист надсилається у простому тексті без зайвих вкладень.

Будьте точними і інформативними про проблему

• Чітко і докладно опишіть симптоми проблеми або помилки.
• Опишіть середовище, де вона виникає (машина, ОС, застосунок тощо). Вкажіть дистрибутив і версію (наприклад, «Fedora Core 7», «Slackware 9.1»).
• Опишіть, які дослідження ви провели, щоб зрозуміти проблему, перш ніж ставити питання.
• Опишіть діагностичні кроки, які ви зробили, щоб локалізувати проблему.
• Опишіть будь-які недавні зміни у конфігурації компʼютера або ПЗ.
• Якщо можливо, надайте спосіб відтворити проблему у контрольованому середовищі.

Спробуйте передбачити питання хакера і відповісти на них у своєму запиті.

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

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

Обсяг — не точність

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

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

Не поспішайте заявляти про баг

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

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

Розробники ПЗ дуже стараються, щоб воно працювало добре. Якщо ви заявляєте про баг, ви ставите під сумнів їх компетентність, що може образити деяких, навіть якщо ви праві. Особливо недипломатично писати «баг» у темі.

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

Самоприниження — не заміна домашньої роботи

Деякі, хто розуміє, що не варто бути грубим чи зарозумілим, переходять у протилежну крайність — самоприниження. «Я знаю, що я жалюгідний новачок, але…». Це відволікає і не допомагає. Особливо дратує, коли поєднується з нечітким описом самої проблеми.

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

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

Описуйте симптоми проблеми, а не свої здогадки

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

Дурне:

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

Розумне:

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

Щоб нагадати: «Всі діагностики з Міссурі». Девіз цього штату — «Покажи мені» (отриманий у 1899, коли конгресмен Віллард Вандівер сказав: «Я з країни, що вирощує кукурудзу, бавовну, репʼяхи і демократів, і пусті балачки мене не переконують і не задовольняють. Я з Міссурі. Покажи мені.») Для діагностів це не скептицизм, а потреба бачити сирі докази, як і ви, а не ваші здогадки. Покажіть нам.

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

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

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

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

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

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

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

Дурне:

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

Розумне:

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

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

Не просіть відповідати приватною поштою

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

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

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

Будьте конкретними у питанні

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

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

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

Тож корисно формулювати питання так, щоб мінімізувати час, потрібний експерту для відповіді — але це не те саме, що спрощувати питання. Наприклад, «Чи можете дати посилання на хороше пояснення X?» — розумніше, ніж «Поясніть, будь ласка, X». Якщо у вас є проблемний код, краще попросити пояснити, що з ним не так, ніж просити виправити.

Якщо питаєте про код

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

Найкращий спосіб бути точним у питанні про код — надати мінімальний тестовий приклад, що демонструє баг. Що таке мінімальний тест? Це ілюстрація проблеми; мінімум коду, що проявляє небажану поведінку. Як зробити мінімальний тест? Якщо знаєте рядок або частину коду, що викликає проблему, скопіюйте її і додайте мінімум допоміжного коду, щоб приклад був повним (тобто компілювався або виконувався). Якщо не можете звузити, скопіюйте код і починайте видаляти частини, що не впливають на проблему. Чим менший мінімальний тест, тим краще (див. розділ «Обсяг — не точність»).

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

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

Не публікуйте домашні завдання

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

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

Відсікайте безглузді запити

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

Загалом, уникайте питань з відповіддю «так» чи «ні», якщо ви не хочете саме такої відповіді.

Не позначайте питання як «термінове», навіть якщо воно таке для вас

Це ваша проблема, не наша. Заявки про терміновість часто контрпродуктивні: більшість хакерів просто видаляють такі листи як грубі і егоїстичні спроби отримати негайну увагу. Крім того, слово «термінове» (і подібні спроби привернути увагу у темі) часто спрацьовує як спам-фільтр — ваші адресати можуть і не побачити листа.

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

Це ризиковано, бо критерії хакерів, що цікаво, можуть відрізнятися від ваших. Наприклад, лист з Міжнародної космічної станції буде цікавим, а лист від благодійної чи політичної організації — ні. Фраза «Терміново: допоможіть врятувати пухнастих тюленів!» швидше призведе до ігнорування або образ навіть від хакерів, які вважають тюленів важливими.

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

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

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

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

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

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

Надсилайте коротке повідомлення про рішення

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

Оптимально, щоб відповідь була у тій же темі, що й початкове питання, і мала у темі позначку «FIXED», «RESOLVED» або подібну. У списках з швидкою реакцією учасники, що бачать тему «Проблема X — FIXED», знають, що не треба витрачати час на читання (якщо тільки їм особисто не цікава ця проблема), і можуть присвятити час іншим питанням.

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

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

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

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

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

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

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

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

Є давня традиція: якщо ви отримали відповідь «RTFM», це означає, що вам радять «Read The Fucking Manual» — прочитати, чорт забирай, інструкцію. І це майже завжди правильно. Читайте.

RTFM має молодшого родича. Якщо вам відповіли «STFW», це означає «Search The Fucking Web» — шукайте, чорт забирай, в Інтернеті. І це теж майже завжди правильно. Шукайте. (Мʼякша версія — «Google — ваш друг!»)

На веб-форумах вам можуть порадити шукати в архівах форуму. Хтось навіть може дати посилання на попередню тему, де проблему вирішили. Але не покладайтеся на це; шукайте в архівах перед тим, як питати.

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

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

Якщо не розумієте...

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

Наприклад, якщо я скажу: «Здається, у вас застряг zentry; треба його очистити», то погане уточнення: «Що таке zentry?» А гарне уточнення: «Добре, я прочитав man, zentry згадуються лише під ключами -z і -p. Там нічого не сказано про очищення. Це один із них, чи я щось пропускаю?»

Як поводитися з грубістю

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

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

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

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

Спостереження Джеффа Біглера (Jeff Bigler) про фільтри такту також актуальні і варто їх прочитати.

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

Як не поводитися як невдаха

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

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

Переживіть це. Це нормально. Насправді це здорово і доречно.

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

Були форуми, де через надмірну ввічливість забороняли критикувати чужі пости і казали: «Не кажи нічого, якщо не хочеш допомогти». Відтік розумних учасників призводив до беззмістовної балаканини і втрати цінності форуму.

Занадто «дружній» (у такому сенсі) чи корисний — вибирайте.

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

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

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

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

Питання, які не варто ставити

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

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

Там, де і я, дурнику, у веб-пошуку. Чорт, хіба всі ще не вміють користуватися Google?

Як використати X, щоб зробити Y?

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

Як налаштувати мій shell prompt?

Якщо ви достатньо розумні, щоб ставити таке питання, ви достатньо розумні, щоб RTFM і дізнатися самі.

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

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

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

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

У мене проблеми з Windows. Можете допомогти?

Так. Викиньте цей смітник Microsoft і встановіть відкриту ОС, як Linux або BSD. Примітка: ви можете ставити питання про Windows, якщо це програма з офіційною збіркою для Windows або взаємодіє з Windows (наприклад, Samba). Просто не дивуйтеся відповіді, що проблема у Windows, а не у програмі, бо Windows дуже часто ламається загалом.

Моя програма не працює. Думаю, системна функція X зламана.

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

У мене проблеми з встановленням Linux або X. Можете допомогти?

Ні. Мені потрібен фізичний доступ до вашої машини, щоб це діагностувати. Зверніться до місцевої групи користувачів Linux за допомогою. (Список груп можна знайти тут.) Примітка: питання про встановлення Linux можуть бути доречними на форумах чи списках розсилки конкретного дистрибутиву, якщо проблема саме з ним, або на форумах місцевих груп. У такому разі опишіть деталі помилки. Але спочатку ретельно шукайте, використовуючи «linux» і все підозріле обладнання.

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

Ви — покидьок, який хоче робити такі речі, і дурень, що просить хакера допомогти.

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

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

Дурне: Де можна дізнатися про Foonly Flurbamatic?

Це питання лише просить відповіді «STFW».

Розумне: Я шукав у Google «Foonly Flurbamatic 2600» в Інтернеті, але не знайшов корисних результатів. Можете дати посилання на програмну інформацію про цей пристрій?

Це питання вже пройшло STFW і звучить як реальна проблема.

Дурне: Код проекту foo не компілюється. Чому він зламаний?

Запитувач вважає, що хтось інший винен. Пихатий ідіот...

Розумне: Код проекту foo не компілюється на Nulix версії 6.2. Я прочитав FAQ, але там немає нічого про проблеми з Nulix. Ось транскрипт моєї спроби компіляції; це моя помилка?

Запитувач вказав середовище, прочитав FAQ, показав помилку і не звинувачує інших. Це питання варте уваги.

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

Відповідь хакера, ймовірно, буде: «Правильно. Потрібно ще й памперси міняти?» і видалення повідомлення.

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

Ця людина показала розуміння проблеми і не чекає відповіді з неба.

У останньому питанні помітна тонка, але важлива різниця між вимогою «Дайте відповідь» і проханням «Допоможіть мені зрозуміти, які додаткові діагностики провести».

Насправді форма останнього питання базується на реальному випадку в серпні 2001 року на списку linux-kernel (lkml). Я (Ерік) ставив це питання. Я бачив загадкові зависання на материнській платі Tyan S2462. Учасники списку дали мені критичну інформацію для розвʼязання.

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

Після цього, коли я подякував усім і відзначив, як добре це спрацювало, один із учасників lkml сказав, що це спрацювало не тому, що я «знавець» у списку, а тому, що я поставив питання правильно.

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

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

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

Загалом, повторне надсилання питання — погана ідея. Це вважається дратівливим. Терпіть: людина з вашою відповіддю може бути в іншому часовому поясі і спати. Або ваше питання було погано сформульоване спочатку.

Є інші джерела допомоги, часто кращі для новачків.

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

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

Для популярного програмного забезпечення, такого як Linux, на одного розробника припадає щонайменше 10 000 користувачів. Просто неможливо, щоб одна людина обробляла звернення в службу підтримки від понад 10 000 користувачів. Памʼятайте, що навіть якщо вам доводиться платити за підтримку, ви все одно платите набагато менше, ніж якби вам довелося ще й купувати саме програмне забезпечення (до того ж підтримка закритого програмного забезпечення зазвичай дорожча й менш компетентна, ніж підтримка відкритого).

Як відповідати на запитання корисним чином

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

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

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

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

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

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

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

Відповідайте саме на поставлене запитання! Якщо людина була такою ретельною, що провела дослідження й написала у своєму запиті, що X, Y, Z, A, B і C вже були спробувані безуспішно, то надзвичайно некорисно відповідати “Спробуйте A чи B” або давати посилання, яке лише каже: “Спробуйте X, Y, Z, A, B чи C”.

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

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

Повʼязані ресурси

Якщо вам потрібні основи про те, як працюють персональні компʼютери, Unix та Інтернет, перегляньте The Unix and Internet Fundamentals HOWTO.

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

Подяки

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

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