Ваша местная группа пользователей или ваш дистрибутив 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”, значит, отвечающий думает, что вам стоит почитать руководство (Read The Fucking Manual). Он почти наверняка прав. Читайте.

У ответа RTFM есть более молодой аналог. Если вы получаете ответ “STFW”, значит, отвечающий думает, что вам стоит поискать ответ в сети (Search The Fucking Web). Он почти наверняка прав. Ищите.

В Web-форумах вам еще могут предложить поискать в архивах форума. Фактически, отвечающий может оказаться настолько любезен, что даст ссылку на предыдущее обсуждение, в котором эта проблема была решена. Но не надейтесь на это; поищите в архивах сами, прежде чем спрашивать.

Часто тот, кто посылает один из подобных ответов, имеет под рукой руководство или web-страницу с необходимой вам информацией, и смотрит на нее, когда набирает ответ. Эти ответы означают, что, по его мнению, во-первых, необходимую вам информацию легко найти и, во-вторых, вы большему научитесь при поиске информации, чем если вам ее преподнесут под нос на тарелочке.

Вас это не должно возмущать; по хакерским стандартам, он оказал вам достаточное уважение уже тем, что не проигнорировал вопрос. Вы должны поблагодарить ответившего за его отеческую доброту.