Прежде, чем задавать технический вопрос по электронной почте или в дискуссионную группу, в чате или на форуме, сделайте следующее:

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

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

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

Не задавайте неправильных вопросов. Если вопрос строится на ошибочных предположениях, любой хакер (в оригинале - J. Random Hacker, прим. переводчика), скорее всего, даст бесполезный буквальный ответ, подумав при этом "Глупый вопрос...", и надеясь, что получение того, о чем вы просили, вместо того, что действительно нужно, чему-то вас научит.

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

С другой стороны, неплохо сразу ясно дать понять, что вы можете и хотите помочь в процессе выработки решения. На вопросы типа "Может ли кто-то подсказать?", "Что не учтено в моем примере?" и "А нет ли сайта, который стоит на эту тему посмотреть?" более вероятно будет получен ответ, чем на требование прислать точную последовательность действий для решения проблемы, поскольку вы явно показали, что решите проблему сами, если кто-то укажет вам правильное направление действий

Поэтому сначала надо найти соответствующий форум. В этом вам снова поможет поисковая система 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!!!!"; сообщения с такими темами выбрасываются рефлекторно). Не пытайтесь поразить нас глубиной своих страданий; лучше используйте отведенное место для максимально краткого описания проблемы.

Хорошее соглашение по оформлению тем сообщений, используемое многими службами технической поддержки, - применение шаблона "объект - отклонение". Часть "объект" задает, с чем именно возникла проблема, а часть "отклонение" описывает отклонение от ожидаемого поведения.

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

Не посылайте просто ответ на сообщение списка рассылки, если собираетесь обсуждать новую тему (начать нить обсуждения). Это сузит круг отвечающих. Некоторые программы чтения почты, например, mutt, позволяют пользователю сортировать сообщения по темам, а затем прятать сообщения по теме, сворачивая нить обсуждения. Те, кто этой возможностью пользуется, никогда вашего сообщения не увидят.

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

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

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

Поэтому четкость и правильность формулировки вопроса имеет значение. Если вы не хотите морочить себе этим голову, мы не хотим морочить голову себе, уделяя внимание таким вопросам. Постарайтесь сформулировать вопрос правильным языком. Он не должен быть тяжеловесным и формальным — на самом деле, в хакерской культуре ценится неформальный, полный сленга и юмора язык, используемый правильно. Но мысли должны быть выражены четко; необходимо продемонстрировать хоть какие-то признаки вдумчивости и внимания.

Соблюдайте правила синтаксиса, пунктуации и использования прописных букв. Не путайте "its" с "it's", "loose" с "lose" или "discrete" с "discreet". Не ПИШИТЕ ВСЕ В ВЕРХНЕМ РЕГИСТРЕ, - это воспринимается как крик и считается грубостью. (Если все написано в нижнем регистре, - не многим лучше, поскольку так сложно читать. Алану Коксу это прощается, а вам - нет.)

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

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

Если вы искусственно затрудняете чтение вопроса, увеличивается вероятность, что вместо него ответят на вопрос, который прочитать не сложно. Поэтому:

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

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

Саймон Тэтхем (Simon Tatham) написал замечательное эссе, озаглавленное Как эффективно сообщать об ошибках. Я настоятельно рекомендую его прочитать.

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

Вероятность получения полезного ответа повышается, если вы четко даете понять, чего добиваетесь от отвечающих (предоставить ссылки, послать код, проверить ваше решение и т.п.). Это сконцентрирует усилия отвечающих и неявно задаст ограничение по времени и усилиям, которые придется затратить отвечающему, чтобы вам помочь. Это хорошо.

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

Поэтому имеет смысл ограничить вопрос, чтобы свести к минимуму время, необходимое эксперту для его решения. Но зачастую это не то же самое, что упростить вопрос. Так, например, вопрос: "Можете ли вы дать мне ссылку на хорошее описание X?" - обычно куда разумнее, чем просьба: "Объясните мне X, пожалуйста". Если у вас проблема с неработающим кодом, разумнее будет попросить объяснить, что в нем не так, а не просить исправить ошибки.

Не поддавайтесь соблазну завершить свой запрос бессмысленными вопросами вида: "Не поможет ли мне кто-нибудь? " или "Есть ли вообще ответ?" Во-первых, если вы хоть сколько-нибудь компетентно описали свою проблему, подобные дополнительные вопросы, как минимум, излишни. Во-вторых, поскольку они излишни, хакерам они кажутся надоедливыми — и в ответ их так и подбивает написать логически безукоризненную отписку типа: "Да, помочь вам можно" или "Нет, вам уже ничем не поможешь".

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

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

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

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

Если это вас удивляет, перечитывайте весь остальной документ до тех пор, пока не поймете, а до того воздержитесь от посылки вопросов вообще.

Будьте вежливы. Используйте фразы "Пожалуйста" и "Заранее благодарен". Дайте понять, что благодарны людям, бесплатно посвящающим вам свое время.

Если честно, это не так важно, как отсутствие ошибок в тексте вопроса, ясность, точность и детальность описания, использование открытых форматов и т.д. (и не заменяет все перечисленное); хакеры, в общем случае, предпочли бы получать грубые, но технически точные сообщения об ошибках, чем вежливое словоблудие. (Если вас это удивляет, вспомните, что мы ценим вопрос за то, чему он нас учит.)

Однако при нормальном техническом уровне вопроса вежливость действительно повышает вероятность получить полезный ответ.

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