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

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

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

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

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

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

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

Несмотря на это, считается, что хакеры относятся к простым вопросам скорее враждебно или высокомерно. Иногда кажется, что мы достаточно грубы к новичкам и игнорируем их. Но, на самом деле, это не так.

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

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

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

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

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

Если вы решили обратиться к нам за помощью, не становитесь в позицию неудачника. И не ведите себя как неудачник. Лучший способ получить быстрый и чуткий ответ, - спрашивать как человек умный, уверенный в себе и знающий, которому просто понадобилась помощь при решении одной конкретной проблемы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Есть также масса коммерческих компаний, с которым можно заключить контракт на поддержку, как крупных, так и маленьких (одни из наиболее известных - Red Hat и Linuxcare, но есть и множество других). Пусть вас не пугает идея платить за поддержку! В конечном итоге, если необходим капремонт двигателя автомобиля, вы ведь отдадите его в мастерскую и заплатите за ремонт. Даже если программное обеспечение ничего не стоило, нельзя рассчитывать, что его всегда будут бесплатно поддерживать.

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

Будьте великодушны. Связанный с проблемой стресс может делать невежливыми или глупыми людей, которые таковыми не являются.

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

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

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

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

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

Если уж вы отвечаете на вопрос, давайте ответ по сути. Не предлагайте наспех придуманные обходные пути, если используется в принципе не то средство или неверный подход. Предлагайте хорошие средства. Переформулируйте вопрос.

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

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

Если вам необходима информация по основам работы персональных компьютеров, ОС Unix и сети Internet, см. руководство The Unix and Internet Fundamentals HOWTO.

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

Эвелин Митчел (Evelyn Mitchell) предложила прокомментировать ряд глупых вопросов и вдохновила на написание раздела "Как давать хорошие ответы". Михаил Рамендик дал ряд ценных предложений по улучшению документа.