Copyright © 2001,2006 Eric S. Raymond, Rick Moen
Перевод на русский язык: Copyright © 2002-2006 Валерий Кравчук, 2008-2018 Алексей Стёпин ака MadDog <aleksey.stepin@gmail.com>
| Хронология версий | ||
|---|---|---|
| Версия 3.10 | 21 мая 2014 года | esr |
| Новый раздел Stack Overflow. | ||
| Версия 3.9 | 23 апреля 2013 года | esr |
| Обновление ссылок | ||
| Версия 3.8 | 19 июня 2012 года | esr |
| Обновление ссылок | ||
| Версия 3.7 | 06 декабря 2010 года | esr |
| Полезные советы для людей, у которых английский является вторым языком | ||
| Версия 3.7 | 02 ноября 2010 года | esr |
| Убраны ссылки на некоторые переводы | ||
| Версия 3.6 | 19 марта 2008 года | esr |
| Небольшое обновление и новые ссылки | ||
| Версия 3.5 | 2 января 2008 года | esr |
| Исправление ошибок и некоторые ссылки на переводы | ||
| Версия 3.4 | 24 марта 2007 года | esr |
| Новый раздел, «Когда спрашиваете о коде» | ||
| Версия 3.3 | 29 сентября 2006 года | esr |
| Добавлен хороший совет от Кая Нигемана (Kai Niggemann). | ||
| Версия 3.2 | 10 января 2006 года | esr |
| Включены правки Рика Моена (Rick Moen). | ||
| Версия 3.1 | 28 октября 2004 года | esr |
| Добавлен документ «Гугл — ваш друг» | ||
| Версия 3.0 | 2 февраля 2004 года | esr |
| Существенное добавление рассуждений об этикете общения на Web-форумах. | ||
Оригинал этого руководства можно найти здесь.
Это руководство переведено на: арабский язык, индонезийский язык (бахаса), белорусский язык, бразило-португальский, китайский (традиционный), хорватский, чешский, датский, эстонский, французский, грузинский, немецкий, греческий, хинди, венгерский, ирландский, индонезийский, японский, литовский, польский, португальский, румынский, русский, сербский, испанский, узбекский. Если вы хотите скопировать, поддерживать зеркало, перевести или процитировать этот документ, пожалуйста, прочитайте мои правила копирования.
Многие веб-сайты различных проектов размещают ссылку на это руководство в своих разделах помощи. Это нормальная практика, ведь именно для этого и задумывалось это руководство. Однако, если вы являетесь веб-мастером и хотите добавить такую ссылку на страницах своего проекта, убедительно вас просим рядом, на видном месте, добавить текст, что мы не являемся службой поддержки вашего проекта!
Мы на собственном горьком опыте убедились, что, при отсутствии такого предупреждения, нас постоянно будут донимать идиоты, считающие, что публикация этого документа обязывает нас решать все технические проблемы в мире.
Если вы читаете этот документ потому, что нуждаетесь в помощи, и вам в итоге кажется, что вы её можете получить непосредственно от авторов данного руководства, то вы — один из этих идиотов. Не задавайте нам вопросов. Мы будем их просто игнорировать. Наша цель — рассказать вам, как получить помощь у тех, кто разбирается в программном или аппаратном обеспечении, с которым вы работаете, но в 99,9% случаев, этими разбирающимися людьми будем не мы. Если вы не знаете наверняка, что один из авторов этого руководства является экспертом в том, с чем вы разбираетесь, - оставьте нас в покое, и от этого всем станет легче.
В мире хакеров, стиль ответов, которые вы получаете на задаваемые технические вопросы, чаще всего зависит не от сложности самого вопроса, а от того каким образом вы зададите свой вопрос. Мы надеемся, что это руководство научит вас грамотно и правильно задавать вопросы так, чтобы увеличить вероятность получения удовлетворительного ответа.
Сейчас, когда программное обеспечение с открытыми исходными текстами стало широко распространено, вы чаще будете получать ответы от других, более опытных пользователей, а не от хакеров. Это Хорошо, т.к. пользователи обычно немного терпимее относятся к ошибкам, которые часто делают новички. Стоит заметить, что обращаясь к опытным пользователям как к хакерам, и руководствуясь рекомендациями данного руководства, вы тем самым воспользуетесь самым эффективным способом получения от них полезного ответа.
Прежде всего следует понять, что хакерам на самом деле нравятся сложные и «заковыристые» вопросы, которые позволяют расшевелить мозг. Если бы нам это не нравилось, мы не были бы хакерами. Если задать нам интересный вопрос, требующий продолжительных размышлений, мы будем за него только благодарны, ведь хорошие вопросы — это и стимул, и подарок. Хорошие вопросы помогают лучше понять предмет и часто вскрывают проблемы, которых ранее не замечали или о которых просто не задумывались. У хакеров возглас «Хороший вопрос!», означает большой и искренний комплимент.
Несмотря на это, почему-то считается, что хакеры относятся к простым вопросам скорее враждебно и высокомерно. Со стороны может показаться, что мы достаточно грубы к новичкам и игнорируем их. Но на самом деле это не верно.
Мы, без всякого сомнения, неприязненно относимся к людям, которые, такое складывается впечатление, не хотят немного подумать своими мозгами или немного поучиться прежде, чем задавать свои вопросы. Такие люди попросту тратят время - они берут, ничего не давая взамен, они отнимают наше время, которое мы могли бы посвятить другому более интересному вопросу, и другому человеку, который больше них достоин ответа. Таких людей мы называем «неудачниками» («losers») (по историческим причинам это слово иногда пишется как «lusers» — пользователи-неудачники).
Мы понимаем, что большинство людей просто хотят использовать создаваемое нами программное обеспечение, и совершенно не собираются вникать в технические детали. Для многих компьютер - это просто инструмент, средство достижения цели. У таких людей есть более важные и насущные вещи в жизни. Мы прекрасно понимаем это и не ожидаем, что всех интересуют только технические нюансы, столь привлекательные для нас. Тем не менее, наш стиль ответов рассчитан на людей, которые действительно интересуются этим, и активно помогающие в процессе решения проблемы. И это никогда не изменится. А в принципе, и не должно меняться, ведь в противном случае, мы вряд ли сможем эффективно делать то, в чём мы лучше всего разбираемся.
Мы (в основном) — добровольцы. Мы тратим своё личное время своей нелёгкой жизни на решение тех или иных вопросов и проблем, но временами мы просто не справляемся со шквалом вопросов. Поэтому приходится безжалостно фильтровать поступающие вопросы. В частности, приходится отбрасывать вопросы потенциальных неудачников, чтобы потратить более эффективно время на ответы действительно заинтересованным людям.
Если такая позиция кажется вам неприемлемой, высокомерной, или заносчивой, то вы глубоко ошибаетесь. Мы не просим вас относится к нам как богам. Если говорить, положив руку на сердце, большинство из нас хотели бы общаться с вами на равных, принять вас в свой круг культуры и общения, при условии, что и вы со своей стороны приложите все необходимые для этого усилия. Согласитесь, что бессмысленно помогать людям, которые не хотят помочь сами себе. Не знать чего-то — это нормально, а вот прикидываться идиотом — нет.
Итак, вовсе не обязательно быть технически компетентным, чтобы удостоиться нашего внимания, надо всего лишь продемонстрировать качества, позволяющие стать компетентным — внимательность, вдумчивость, наблюдательность, желание активно участвовать в выработке решения. Если по каким-либо причинам вы не можете смириться с подобного рода дискриминацией, то мы можем предложить вам заплатить за коммерческую поддержку вместо того, чтобы просить хакеров безвозмездно помочь вам.
Если вы всё-таки решили обратиться к нам за помощью, не стоит сразу принимать позу неудачника. Да и вести как неудачник тоже не стоит. Лучший способ получить быстрый и исчерпывающий ответ — это спрашивать как человек умный, уверенный в себе и знающий, которому просто понадобилась помощь при решении одной конкретной проблемы.
(Дополнения к этому руководству приветствуются. Предложения можно направлять по электронной почте на адрес esr@thyrsus.com или на адрес respond-auto@linuxmafia.com. Учтите, однако, что это руководство не создавалось как общее руководство по сетевому этикету, и мы обычно игнорируем предложения, не связанные непосредственно с получением полезных ответов на технических форумах.)
Прежде, чем задать технический вопрос по электронной почте или дискуссионной группе, в чате или на форуме, сделайте следующее:
попытайтесь найти ответ, воспользовавшись поиском по архивам форума, на котором собираетесь задать вопрос
попытайтесь поискать ответ в интернете, воспользовавшись поисковыми сайтами
попытайтесь найти ответ в прилагаемом руководстве
попытайтесь найти ответ в списке часто задаваемых вопросов (FAQ)
попытайтесь найти ответ путём проверок и экспериментов
спросите у более опытного товарища
если вы программист, попытайтесь найти ответ, анализируя исходный код
Когда вы задаёте вопрос, укажите с самого начала, что вы всё это уже сделали; это поможет понять, что вы не какой-нибудь лентяй, тратящий чужое время. Будет даже лучше, если вы покажите, что вы узнали в результатах своих поисков. Нам нравится отвечать людям, способным анализировать и делать выводы из полученных ответов.
Возьмите на вооружение контекстный поиск, как это делает поисковая система Google, по тексту полученного сообщения об ошибке (имеет смысл также поискать в дискуссионных группах — Google groups, а не только на веб-страницах). Это может привести вас либо непосредственно к документации, посвящённой тому, как устранить эту ошибку, либо к обсуждению в списке рассылки, в которой можно будет найти ответ. Даже если вам и не удалось найти ответ на свою проблему, фраза: «Я поискал в Google по следующему запросу, но ничего полезного не нашёл» пригодится при обращении за помощью по электронной почте или в дискуссионную группу хотя бы потому, что свидетельствует о бесполезности поиска. В дальнейшем это поможет быстрее найти ответ другим людям с подобной проблемой, т.к. решение данной проблемы будет связано в одну цепочку с вашим описанием проблемы.
Не ленитесь, потратьте время на поиск решения. Можете даже не думать, что у вас получится решить сложную проблему, поискав с помощью Google всего лишь несколько секунд. Почитайте и попытайтесь понять ответы из разных ЧаВО, посидите, расслабьтесь и немного подумайте над проблемой, прежде чем обращаться к экспертам. Поверьте, по вашим вопросам они смогут понять, как много вы читали и думали, и с большим удовольствием помогут, встретив подготовленного и умеющего думать пользователя. Не надо забрасывать людей вопросами только потому, что вы не смогли найти ответ на свою проблему (или получили их слишком много).
Подготовьте свой вопрос. Тщательно его продумайте. На поверхностные вопросы вы получите поверхностные ответы, или вообще не получите ответа. Чем больше вы сделаете, чтобы продемонстрировать свои размышления и усилия по решению проблемы до того, как попросить о помощи, тем вероятнее, что вы эту помощь получите.
Не задавайте глупых и неправильных вопросов. Если вопрос строится на ошибочных предположениях, любой хакер (в оригинале J. Random Hacker - прим. переводчика В.К.), скорее всего, даст настолько же бесполезный ответ, подумав про себя «Глупый вопрос…», и надеясь что, то что вы получили вместо того, что вам действительно надо, заставит вас лишний раз подумать.
Никогда не думайте и не надейтесь, что вам должны ответить. Вам никто и ничего не должен, в конце концов, вы же не платили за оказание этих услуг поддержки. Вы получите ответ на свой вопрос, если вы его заслужили, задав значимый, интересный и наводящий на размышления вопрос — вопрос, неявно дающий сообществу новый опыт, а не просто пассивно требующий от других поделиться знаниями.
С другой стороны, неплохо сразу ясно дать понять, что вы можете, желаете и хотите помочь в процессе выработки решения. На вопросы типа: «Может ли кто-то подсказать?», «Что не учтено в моём примере?» или «А нет ли сайта, который стоит на эту тему посмотреть?» более вероятно будет получен ответ, чем требование прислать точную последовательность действий для решения проблемы, поскольку вы явно показали, что решите проблему самостоятельно, если кто-то кажет вам правильное направление дальнейших действий.
Тщательно продумайте, где именно задавать свой вопрос. Ведь в случае ошибки, вас с большой долей вероятности либо проигнорируют, либо спишут как неудачника, если вы:
зададите свой вопрос на форуме, не соответствующей тематике (off topic);
зададите самый элементарный вопрос на форуме, где обсуждаются сложные технические вопросы, или наоборот;
зададите вопрос одновременно во множестве дискуссионных групп (cross-post);
отправите личное сообщение по электронной почте незнакомому человеку, который не отвечает за решение ваших проблем.
Хакеры игнорируют вопросы, направленные не по адресу, чтобы не загружать свои каналы связи не относящейся к делу информации. Не стоит попадать в разряд таких вопросов.
Поэтому сначала надо найти соответствующий форум. В этом вам снова поможет поисковая система Google и другие поисковые системы поиска в Web. Используйте их для поиска страницы проекта, наиболее тесно связанного с оборудованием или программным обеспечением, с которым возникли трудности. Как правило на страницах такого проекта размещаются ссылки на список часто задаваемых вопросов (ЧаВО, FAQ — Frequently Asked Questions), ссылки на список рассылки проекты и их архивы. Списки рассылки должны быть вашей последней инстанцией для поиска, если ваши собственные усилия (включая прочтение найденных вами ЧаВО) не увенчались успехом. На странице проекта также может быть описана процедура сообщения об ошибках или представлена соответствующая ссылка, которой и следует воспользоваться.
Отправка сообщения человеку или в форум, с которым вы лично не знакомы, — предприятие, как минимум, рискованное. Например, не стоит даже думать, что автор информационной web-странички захочет стать вашим бесплатным консультантом. Не делайте оптимистических предположений о том, что вашему вопросу будут рады - если вы в этом не уверены, отправьте его по другому адресу или вообще откажитесь от его отправки.
При выборе Web-форума, дискуссионной группы или списка рассылки, не принимайте решение только на основе имени; прочитайте список часто задаваемых вопросов (FAQ) или правила, чтобы убедиться, что ваш вопрос соответствует тематике. Прежде, чем отправлять свой вопрос, имеет смысл потратить своё время на прочтение сообщений, чтобы понять, как и что делается. На самом деле, очень хорошей идеей будет воспользоваться поиском по ключевым словам, связанные с вашей проблемой, в архивах дискуссионных групп или в списках рассылки, до того как вы отправите свой вопрос. В результатах поиска можно найти ответ, а если его нет, то поможет лучше сформулировать ваш вопрос.
Не забрасывайте своими вопросами все доступные каналы получения помощи одновременно. Это похоже на крик и раздражает людей. Имеет смысл обращаться по очереди.
Правильно определите тему! Одна из классических ошибок — задавать вопрос о программном интерфейсе Unix или Windows в форуме, посвящённому языку, библиотеке или инструментальному средству, работающему на обеих платформах. Если вы не понимаете, почему это грубая ошибка, лучше вообще не задавайте вопрос, пока не поймёте.
В общем случае, вероятность получить ответы на вопросы в правильно выбранном общедоступном форуме выше, чем в приватном. Причин для этого несколько. Одна из них — количество потенциально отвечающих. Другая — размер аудитории, которая узнает ответ; хакеры с большим удовольствием отвечают на вопросы, которые могут быть интересовать многих, чем на вопросы, полезные лишь единицам.
Понятно, что опытные хакеры и создатели популярных программ и так уже получают намного больше не относящихся к делу вопросов, чем хотели бы. Увеличивая этот поток, вы в некоторых случаях можете стать последней каплей - изредка участники популярных проектов прекращают их поддержку, потому что не выносят больше сопутствующих ей проблем в виде потока бесполезных сообщений по электронной почте на их личные адреса.
Ищите, затем уже спрашивайте на Stack Exchange.
В последние годы сообщество сайтов Stack Exchange стало основным ресурсом для получения ответа на технические и другие вопросы, и даже является предпочтительным форумом для многих проектов с открытым исходным кодом.
Начните с поиска Google, прежде чем смотреть на Stack Exchange; Google индексирует его в режиме реального времени. Есть очень хороший шанс, что кто-то уже задавал аналогичный вопрос и сайты Stack Exchange часто находятся в верхней части результатов поиска. Если вы ничего не нашли через Google, повторите поисковый запрос на конкретном сайте, который наиболее близок к теме вашего вопроса (см.ниже). Поиск с помощью тегов позволяет сузить результаты.
Если вы всё ещё ничего не нашли, попробуйте разместить свой вопрос на одном сайте, где он больше всего соответствует теме. Используйте инструменты форматирования, особенно для кода, и добавьте теги, связанные с содержанием вашего вопроса (в частности, название языка программирования, операционной системы или библиотеки, с которой у вас возникла проблема). Если отвечающий просит у вас дополнительной информации, отредактируйте основной пост, чтобы добавить необходимую информацию. Если какой-либо ответ полезен, нажмите стрелочку вверх, чтобы поднять его; если ответ даёт решение вашей проблемы, нажмите на флажок под стрелками голосования, чтобы принять его как правильный.
Stack Exchange заметно вырос и содержит более сотни сайтов, но вот наиболее подходящие кандидаты:
Super User предназначен для компьютерных вопросов общего назначения. Если ваш вопрос не о коде или о программах, с помощью которых вы общаетесь в сети, скорее всего он вам подойдёт.
Stack Overflow предназначен для вопросов о программировании.
Server Fault предназначен для вопросов о сервере и сетевом администрировании.
Несколько проектов имеют свои собственные сайты, включая Android, Ubuntu, TeX/LaTeX и SharePoint. Проверьте сайт Stack Exchange для получения обновлённого списка.
Ваша местная группа пользователей или ваш дистрибьютор Linux могут поддерживать Web-форум или IRC, предназначенный для помощи начинающим. (В не англоязычных странах форумы для начинающих, по-прежнему, скорее всего, организованы в виде списков рассылки.) Это подходящие места, чтобы задать свои первые вопросы, тем более, если вы столкнулись с относительно несложной или типичной проблемой. Открыто рекламируемый канал IRC — это явное приглашение задавать вопросы, и, зачастую, возможность получать ответы в режиме реального времени.
Фактически, если программа, с которой у вас возникли проблемы, взята из дистрибутива (что на сегодня типично), может оказаться, что сначала лучше спросить на форуме/списке рассылки по соответствующему дистрибутиву, прежде чем обращаться в форум/список рассылки непосредственно самой программы. Хакеры, работающие над проектом, могут просто ответить: «Используйте нашу сборку».
Прежде, чем задать вопрос в любом Web-форуме, проверьте, нет ли на нём возможности поиска. И если такая возможность есть, поищите по ключевым словам обсуждение проблемы подобной вашей. Как правило, это помогает. Если перед этим вы выполнили общий поиск в Web (что надо было сделать), всё равно поищите на форуме; вполне возможно, что ваша поисковая система давно не индексировала этот форум.
Наблюдается интересная тенденция выполнять поддержку пользователей проектов через Web-форум или канал IRC, оставляя электронную почту для общения между разработчиками. Поэтому, если нужна помощь по проекту, обратитесь сначала к этим его источникам информации.
Если у проекта есть список рассылки для разработчиков, отправляйте вопросы в этот список рассылки, а не отдельным разработчикам, даже если вы уверены и точно знаете, кто именно может помочь с вашим вопросом. Адрес списка рассылки можно найти или в документации, или на сайте проекта, на который и следует отправлять свой вопрос. Есть несколько хороших причин поступать именно так:
Любой вопрос, достаточно хороший и интересный, чтобы с ним обратиться к одному разработчику, будет не менее ценным и для всей группы. И наоборот, если кажется, что вопрос слишком простой и примитивный для списка рассылки, это ещё не повод морочить им голову отдельных разработчиков.
Задавая вопрос в списке рассылки, вы невольно распределяете нагрузку между всеми разработчиками. Какой-то конкретный разработчик (особенно если он руководитель проекта) может быть слишком занят в данный момент времени, чтобы отвечать на ваши вопросы.
Большинство списков рассылки со временем архивируются, а архивы индексируются поисковыми системами. Кто-то сможет найти ваш вопрос и ответы на него, и, вполне возможно, не станет задавать его снова в списке рассылки.
Если определённые вопросы задаются достаточно часто, разработчики могут использовать эту информацию для улучшения документации или самого программного продукта, чтобы они стали более понятными. Но если подобные вопросы будут задавать кому-то из разработчиков лично, то ни у кого не будет общей картины о том, какие вопросы чаще всего задают.
Если у проекта есть отдельные списки рассылки или Web-форумы для «пользователей» и для «разработчиков» (или «хакеров»), и вы не занимаетесь разбором (hacking) кода, задайте вопрос в списке/форуме для «пользователей». Не рассчитывайте на тёплый приём в списке рассылке для разработчиков, где ваш вопрос, вероятно, отнесут к разряду «шума», мешающего обмену информацией о ходе разработки.
Однако, если вы уверены в нетривиальности своего вопроса и не получили ответа в списке рассылки/форуме для «пользователей» в течение нескольких дней, имеет смысл обратиться к разработчикам. Но прежде, чем отправлять свой вопрос, последите за соответствующим списком рассылки или форумом хотя бы несколько дней, чтобы изучить его традиции (на самом деле, так следует поступать в любом случае, если вы обращаетесь на частный или полузакрытый список рассылки/форум).
Если не удаётся найти адрес списка рассылки, но известен адрес лица ведущего проекта, отправьте свой вопрос ему. Но и в этом случае не думайте, что списка рассылки нет. В своём сообщении укажите, что вы пытались, но не смогли найти соответствующий список рассылки. Также стоит упомянуть, что вы не против пересылки вашего сообщения другим адресатам. (Многие считают, что личная корреспонденция должна оставаться личной, даже если ничего секретного в ней нет. Разрешая пересылать своё сообщение, вы даёте людям выбор.)
При отправке сообщения в список рассылки, в дискуссионную группу или на Web-форум, тема сообщения длиной до 50 символов — прекрасная возможность привлечь внимание квалифицированных экспертов. Не стоит тратить эти драгоценные символы на детский лепет типа «Помогите мне, пожалуйста!» (не говоря уже про темы «ПОМОГИТЕ МНЕ!!!!!»; сообщения с такими темами, как правило, выбрасываются или удаляются рефлекторно). Не пытайтесь поразить нас глубиной своих страданий. Лучше используйте отведённое место для максимально краткого описания проблемы.
Многие службы технической поддержки в своей работе используют шаблон «объект — отклонение», который отлично впишется в схему оформления сообщений. Часть «объект» задаёт, с чем именно возникла проблема, а часть «отклонение» описывает отклонение от ожидаемого поведения.
ПОМОГИТЕ! На моём ноутбуке видео работает неправильно.
Неправильная форма курсора мыши в XFree86 4.1, видео на чипсете Fooware MV1005
XFree86 4.1 курсор мыши на чипсете Fooware MV1005 - неправильная форма
Процесс написания темы по шаблону «объект-отклонение» поможет более детально осмыслить проблему. Что именно неправильно работает? Только курсор мыши или с другой графикой тоже есть проблемы? Проблема только в XFree86? Только в версии 4.1? Эта проблема возникает только на видеокартах с чипсетом Fooware? Только в модели MV1005? Хакер, получив сообщение с подобной темой, сможет в общих чертах понять, с чем именно у вас возникла проблема и что это за проблема.
В общем случае, представьте себе, что просматриваете содержимое архива вопросов, в котором представлены только темы. Задайте тему настолько хорошо отражающую суть вопроса, чтобы следующий, кто будет искать в архиве ответ на вопрос похожий на ваш, смог найти его в соответствующем обсуждении, а не задавал вопрос снова.
Если вы задаёте вопрос в ответ, не забудьте изменить строку темы так, чтобы по ней было понятно — задаётся вопрос. Строка темы вида «Re: тест» или «Re: новая ошибка» не привлечёт достаточного внимания. Кроме того, сведите цитирование предыдущих сообщений к минимуму, достаточному, чтобы новые пользователи могли понять, о чём шла речь.
Не отправляйте просто ответ на сообщение списка рассылки, если собираетесь обсуждать новую тему (начать нить обсуждения). Это сузит круг отвечающих. Некоторые программы для чтения электронной почты, например, mutt, позволяют пользователю сортировать сообщения по темам, а затем прятать сообщения по теме, сворачивая нить обсуждения. Те, кто пользуется такой возможностью почтовых клиентов, вряд ли заметят ваше сообщение.
Просто сменить тему сообщения недостаточно. Mutt и, возможно, другие программы для чтения электронной почты, учитывают не только строку темы, но и другую информацию в заголовках сообщений при привязке их к нити обсуждения. Лучше всего и правильнее будет создать абсолютно новое сообщение.
На Web-форумах правила обсуждения немного отличаются, поскольку сообщения обычно более тесно связаны с конкретными нитями обсуждения и часто не видны за пределами этих нитей. Изменение темы при задании вопроса в ответ в данном случае не существенно (да и не всех фоумах существует возможность изменять тему при ответе, а если такая возможность и существует, их практически никто не читает). Но, задавать встречный вопрос в ответ уже само по себе сомнительная практика, поскольку вопрос этот увидят только те, кто следит за соответствующей нитью обсуждения. Поэтому, если вы не уверены, что хотите обратиться именно к тем, кто участвует в обсуждении темы, начните новую тему.
Завершение вопроса фразой «Ответ, пожалуйста, направляйте по адресу…» делает получение ответа весьма маловероятным. Если у вас нет пары секунд на то, чтобы правильно задать заголовок Reply-To в своей почтовой программе, то у нас нет и пары секунд на то, чтобы подумать о вашей проблеме. Если ваша почтовая программа не позволяет это сделать — найдите программу получше. Если ваша операционная система не поддерживает почтовые программы, позволяющие это сделать, поищите операционную систему получше.
Просить отвечать по электронной почте на заданный вопрос в Web-форумах — крайне невежливо, если только вы не уверены, что информация может оказаться конфиденциальной (и кто-то, по неизвестной причине, захочет сообщить её вам лично, а не всему форуму). Если вы хотите получить уведомление по почте о том, что кто-то ответил на тему в форуме, запросите уведомление в интерфейсе Web-форума; эта возможность поддерживается практически везде в виде опций «watch this thread» («следить за обсуждением»), «send e-mail on answers» («уведомлять по почте при ответе») и т.п.
Учитывая наш опыт, мы заметили, что люди, пишущие невнимательно и небрежно, обычно так же невнимательны и небрежны в мыслях и в коде создаваемых программ (по-крайней мере, мы с таким сталкиваемся достаточно часто, чтобы утверждать это). Отвечать на вопросы людей невнимательных и небрежно мыслящих — занятие неблагодарное, лучше мы своё время потратим на что-нибудь другое.
Поэтому чёткость и правильность формулировки вопроса имеет большое значение. Если вы не хотите морочить себе этим голову, мы, в свою очередь, не хотим морочить голову себе, уделяя внимание таким вопросам. Постарайтесь сформулировать вопрос правильным языком. Он не должен быть тяжеловесным и формальным — на самом деле, в хакерской культуре ценится неформальный, полный сленга и юмора язык, используемый правильно и к месту. Но мысли должны быть выражены чётко; необходимо продемонстрировать хоть какие-то признаки вдумчивости и внимания.
Соблюдайте правила орфографии, старайтесь писать грамотно, без ошибок («очепятки» меньше раздражают, нежели полное нежелание писать грамотно — прим. переводчика А.С.). Не путайте «its» с «it's», «loose» с «lose» или «discrete» с «discreet». Не ПИШИТЕ ВСЁ В ВЕРХНЕМ РЕГИСТРЕ, — это воспринимается как крик и считается грубостью. (Если всё написано в нижнем регистре, — не многим лучше, поскольку такой текст сложно читать. Алану Коксу это прощается, а вам — нет.)
В общем случае, если вы пишете на уровне детского лепета или бреда сумасшедшего, ваш вопрос, скорее всего, проигнорируют. Так что, использование сокращений, например, вместо «you» написать «u», приемлемых в программах по обмену быстрыми сообщениями, не приветствуется. Писанина в стиле малолетних «кул-хацкеров» (в оригинале — l33t script kiddie haxOr — прим. переводчика В.К.) — абсолютно безнадёжна, и гарантирует в ответ — тишину (или, в лучшем случае, порцию пренебрежения и сарказма).
Если вы задаёте вопросы в форуме, где используется не родной для вас язык, то некоторые лексические и грамматические ошибки вам простят — но никакого прощения лени не ждите (да, мы обычно способны почувствовать разницу). Кроме того, если вы не знаете точно, какой язык для адресата является родным, пишите по-английски. Занятые хакеры обычно пропускают вопросы на языках, которые они не понимают, а английский язык является основным и рабочим языком Интернет. Задав вопрос по-английски, вы уменьшаете вероятность того, что его пропустят не читая.
Если вы пишете на английском языке, который для вас является вторым языком, то будет хорошим тоном предупредить потенциальных респондентов о некоторых языковых трудностях и вариантов их разрешения. Примеры:
Если вы искусственно затрудняете чтение вопроса, увеличивается вероятность того, что вместо него ответят на вопрос, который прочитать не сложно. Поэтому:
Отправляйте сообщение в виде обычного текста, а не в формате 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 4», «Slackware 9.1» и т.п.).
Опишите проведённое вами исследование при попытках понять проблему прежде, чем задали свой вопрос.
Опишите какие вы предприняли самостоятельные шаги по диагностике и устранению проблемы прежде, чем задали свой вопрос.
Опишите последние изменения в конфигурации компьютера или программного обеспечения, которые могут иметь отношение к делу.
Сделайте максимум возможного, чтобы предугадать потенциальные вопросы хакера и заранее на них ответить в своём обращении за помощью.
Саймон Тэтхем (Simon Tatham) написал замечательное эссе, озаглавленное «Как эффективно сообщать об ошибках». Я настоятельно рекомендую его прочитать.
Будьте точны и информативны. Для этого недостаточно просто вставить в запрос большой объём кода или данных. Если имеется большой, сложный тестовый случай, приводящий к ошибке в программе, постарайтесь максимально сократить его.
Это полезно, как минимум, по трём причинам. Первая: продемонстрированные усилия по упрощению вопроса повышают вероятность получения ответа. Вторая: упрощение вопроса повышает вероятность получения полезного ответа. Третья: в ходе уточнения сообщения об ошибке вы сами можете найти решение или способ обхода проблемы.
При возникновении проблем с тем или иным программным обеспечением не заявляйте, что нашли ошибку, если только абсолютно в этом не уверены. Подсказка: если вы не можете предоставить исправление исходного кода, которое решает проблему или тестовый пример для предыдущей версии, демонстрирующий неправильное поведение, вы, скорее всего, недостаточно уверены в своём заявлении. Это же относится и к web-страницам и документации, если вы нашли «ошибку» в документации, пришлите текст, который вы считаете более уместным, и укажите страницы, на которых он должен быть представлен.
Помните, что есть много пользователей, которые с такой проблемой не сталкивались. Иначе, вы уже узнали бы об этом при чтении документации или при поиске в Web (вы же сделали это, прежде, чем делать такие утверждения, не так ли?). Это означает, что, скорее всего, именно вы делаете что-то неправильно, а не программное обеспечение.
Авторы программного обеспечения прикладывают огромные усилия для того, чтобы оно работало как можно лучше. Если вы утверждаете, что нашли ошибку, то тем самым предполагаете, что они сделали что-то не так, и это почти наверняка им не понравится — даже если вы правы. Особенно не дипломатичным будет написать «bug» («Ошибка») в строке темы сообщения.
Если вы задаёте свой вопрос, то описывайте возникшую проблему, исходя из предположения, что вы делаете что-то не так, даже если вы абсолютно уверены, что нашли ошибку. Если это действительно ошибка, то вскоре вы получите ответ на своё письмо. Старайтесь вести себя так, чтобы занимающиеся поддержкой программы люди захотели перед вами извиниться, если обнаружена реальная ошибка, а не чтобы вам пришлось извиняться за свою бестолковость.
Некоторые пользователи, уяснив, что не надо вести себя грубо или надменно, вымогая ответ, выбирают противоположную крайность — самоунижение. «Я знаю, я начинающий, неудачник и полный чайник, но…». Это отвлекает от сути и не имеет никакого смысла. Особенно в сочетании с неопределённостью в описании фактической проблемы.
Не тратьте своё и наше время, уповая на жалость. Лучше предоставьте факты и задайте свой вопрос как можно яснее. Так вы заявите о себе гораздо с лучшей стороны, нежели избрав путь самоунижения.
На некоторых web-форумах есть отдельное место для вопросов новичков. Если вы чувствуете, что такой вопрос может задать только начинающий пользователь, задавайте его именно там. Но и там не надо унижаться.
Бесполезно сообщать хакерам своё мнение о причинах проблемы (Если ваши диагностические теории настолько значимы, надо ли обращаться за помощью к другим?). Поэтому, убедитесь, что вы сообщаете фактические симптомы происходящего, а не свои интерпретации и теории. Пусть интерпретацией и диагностикой займутся отвечающие. Если вы чувствуете, что ваше предположение будет полезным и важным, то стоит чётко и ясно написать почему по вашему мнению это не работает.
Я постоянно получаю ошибки SIG11 при компиляции ядра, и подозреваю, что причина — микротрещина на материнской плате. Как лучше всего это проверить?
На собранном мною компьютере K6/233 на материнской плате FIC-PA2007 (чипсет VIA Apollo VP2) с 256MB памяти Corsair PC133 SDRAM начинают частно возникать ошибки SIG11 примерно через 20 минут после включения питания, в ходе компиляции ядра, но они не возникают в первые 20 минут работы после включения. Перезагрузка ни к чему не приводит, а вот отключение на ночь помогает. Замена всей памяти не помогла. Соответствующая часть результатов типичной компиляции прилагается.
Вполне возможно, что многим предыдущий пункт покажется немного трудным и непонятным, чтобы вникнуть в суть. Поэтому следующая фраза поможет вам понять: «Все диагносты из Миссури!» Официальный девиз штата США Миссури: «Покажите мне.» (стал использоваться с 1899 года, когда конгрессмен Уиллард Д. Ванивер (Willard D. Vandiver) сказал, что «я из местности, где выращивают кукурузу, хлопок, листья коки и демократов, и бессодержательное красноречие не убедит и не удовлетворит меня. Я — из Миссури. Вы должны показать мне.»). В случае с диагностами, это не скептический вопрос, а скорее всего буквальный, функциональная потребность увидеть как можно ближе проблему в сыром виде, а не ваши предположения и догадки. Покажите нам.
Наиболее важная информация для выяснения причин происходящего часто связана с непосредственно предшествующими этой ситуации событиями. Поэтому необходимо точно описать, что именно вы делали, и что происходило с компьютером вплоть до возникновения проблемы. В случае работы с интерфейсом командной строки очень может помочь запись сеанса (например, с помощью утилиты script) и включение в сообщение пары десятков соответствующих строк.
Если программа, в которой произошёл сбой, имеет опции диагностики (например, -v — подробная информация), попытайтесь подобрать опции, добавляющие полезную отладочную информацию в лог сеанса. Помните, что больше — не обязательно лучше. Подберите такой уровень вывода отладочной информации, который будет отображать сжато и полно суть проблемы, а не выливать массу не нужной информации.
Если запись получилась достаточно длинной (больше страницы), имеет смысл заранее сформулировать проблему в самом начале, а потом уже указать хронологическую последовательность действий к ней приводящих. В этом случае хакеры будут знать на что именно стоит обратить внимание при чтении сеанса.
Если вы пытаетесь разобраться как что-либо сделать (а не сообщать об ошибке), начинайте с описания цели. И только потом описывайте конкретный шаг на пути к ней, который вы не смогли выполнить.
Зачастую люди, которым необходима техническая помощь, имеют на уме цель высокого уровня и привязываются к одному из возможных, по их мнению, путей её достижения. Они просят помочь выполнить один шаг, не отдавая себе отчёта в том, что выбрали неверный путь. Чтобы разобраться в этом, может потребоваться много усилий.
Как заставить диалог выбора цвета в программе FooDraw воспринимать шестнадцатеричное RGB-значение?
Я пытаюсь заменить таблицу цветов в изображении нужными мне значениями. Сейчас я вижу только один способ сделать это — редактируя каждый слой таблицы, но я не могу задать шестнадцатеричное RGB-значение в диалоге выбора цвета программы FooDraw.
Вторая версия вопроса — разумна. Она позволяет получить ответ, в котором будет предложено средство, более подходящее для решения задачи.
Хакеры считают, что решение проблемы должно быть общедоступным, прозрачным процессом, в ходе которого первая попытка найти ответ может и должна быть исправлена, если кто-то, более знающий, заметит, что этот ответ неполный или некорректный. Кроме того, отвечающие отчасти вознаграждаются тем, что их компетентность и знания будут замечены коллегами.
Когда вы просите личного ответа, вы мешаете процессу выработки решения, так и получения вознаграждения. Не делайте этого. Отвечать лично — это выбор отвечающего, и если он так и делает, то обычно потому, что считает вопрос слишком неудачно сформулирован или очевидным, чтобы быть интересным другим.
Из этого правила есть одно небольшое исключение. Если вы предполагаете, что на свой вопрос получите множество подобных между собой ответов, не забудьте магические слова «отправьте ответ мне, а я резюмирую полученные ответы в статье для дискуссионной группы». Попытка уберечь дискуссионную группу или список рассылки от потока, по сути, идентичных сообщений — это очень любезно, но вы должны сдержать своё обещание и отправить итоговое резюме в дискуссионную группу или список рассылки.
Не ограниченные по времени вопросы зачастую требуют и не ограниченного по времени ответа. Люди, скорее всего способные дать вам полезный ответ, ещё и самые занятые люди (ещё и потому, что большую часть своей работы делают сами). Такие люди ревностно относятся к своему времени, и поэтому часто не воспринимают вопросы не ограниченные по времени.
Вероятность получения полезного ответа повышается, если вы чётко даёте понять, чего добиваетесь от окружающих (предоставить ссылки, отправить код, проверить ваше решение и т.п.). Это сконцентрирует усилия отвечающих и неявно задаст ограничение по времени и усилиям, которые придётся затратить отвечающему, чтобы помочь вам. И это хорошо.
Чтобы понять, в каком мире живут эксперты, надо относиться к знаниям экспертов, как к ресурсу обильному,а к их времени — как к ресурсу весьма ограниченному. Чем меньше времени вы неявно требуете, тем более вероятно получение ответ от действительно хорошего и занятого эксперта.
Поэтому имеет смысл ограничить вопрос, чтобы свести к минимуму время, необходимое эксперту для его решения. Но зачастую это не тоже самое, что упростить вопрос. Так, например, вопрос: «Можете ли вы дать ссылку на хорошее описание X?» — обычно куда разумнее, чем просьба: «Объясните мне X, пожалуйста». Если у вас проблемы с неработающим кодом, разумнее будет попросить объяснить, что в нём не так, а не просить исправить ошибки.
Даже и не просите других отладить ваш неработающий код, без какого-либо описания проблемы, которую должны найти. Отправка нескольких сотен строк кода со словами: «Чего-то у меня не работает», будет проигнорирована. Лучше отправить десяток строк кода со словами: «после 7-ой строки я ожидал увидеть <x>, но вместо этого получил <y>», и скорее всего ответ вы получите.
Наиболее эффективным способом точнее показать проблемный код, является предоставление минимального теста, демонстрирующего ошибку. Что такое минимальный тест? Это иллюстрация проблемы; всего лишь необходимый минимум кода для выявления проблемы, не больше. Если вы знаете строку или часть кода, из-за которой, по вашему мнению, возникают проблемы, скопируйте этот кусок кода и добавьте ровно столько дополнительного кода, чтобы можно было получить полный пример (т.е. достаточно кода для обработки его компилятором/интерпретатором/любым приложением процессов). Если вы не можете уменьшить код до необходимой части, создайте копию и начните удалять куски кода, которые никак не влияют на появление ошибки. Чем меньше будет ваш минимальный тест, тем лучше (см. раздел «Объём размещаемой информации, не означает точность»).
Создание действительного минимального теста не всегда будет возможна, но такая попытка хорошо само дисциплинирует. Это может быть поможет вам узнать, что именно вам нужно, чтобы решить проблему самостоятельно — и даже когда ничего не получается, хакеры будет видеть, что вы пытались. Это сделает их более дружелюбными и сговорчивыми.
Если вы хотите, чтобы ваш код просто посмотрели, дали ему оценку, на забудьте указать какие именно куски кода необходимо посмотреть и почему.
Хакеры хорошо умеют отвечать на вопросы из домашних заданий — большинство из нас их делало самостоятельно. Эти вопросы заданы для работы именно вам, чтобы вы могли научиться на собственном опыте. Просить можно о подсказке, но не о полном решении.
Если вы подозреваете, что вам подкинули вопрос из домашнего задания, но всё равно не можете дать на него ответ, попытайтесь задать вопрос в форуме группы пользователей или (в крайнем случае) в «пользовательском» списке рассылки/форуме соответствующего проекта. Хотя хакеры его и «опознают», некоторые из продвинутых пользователей могут, по крайней мере, дать вам подсказку.
Не поддавайтесь соблазну завершить свой вопрос бессмысленными фразами типа: «Не поможет ли мне кто-нибудь?» или «Есть ли вообще ответ?» Во-первых, если вы хоть сколько-нибудь компетентно описали свою проблему, подобные вопросы, как минимум, излишни. Во-вторых, поскольку они излишни, хакерам они кажутся надоедливыми — и в ответ их так и подбивает написать логически безукоризненную отписку типа: «Да, помочь вам можно» или «Нет, вам уже ничем не поможешь».
В общем случае, если вы не хотите получить ответ в духе да-или-нет, лучше не задавать вопросы в духе да-или-нет.
Это ваша проблема, а не наша. Упоминание о срочности зачастую контрпродуктивно: большинство хакеров просто удаляют такие сообщения как грубые и эгоистические попытки срочно привлечь к себе особое внимание.
В этом правиле есть одно небольшое исключение. Упоминание о срочности может иметь смысл, если вы используете программу в серьёзной и известной компании, которая может заинтересовать хакеров. В таком случае, если вам не хватает времени и вы сообщите об этом вежливо, люди могут оказаться достаточно заинтересованы, чтобы ответить быстрее.
Так делать, однако, крайне рискованно, потому что точка зрения хакера на серьезность и его интересы, вероятно, отличаются от ваших. Вопрос о международной космической станции, например, вызовет интерес, а вот вопрос от имени преуспевающего фонда или политической партии, почти наверняка, — нет. Фактически, вопрос с темой «Срочно: Помогите мне спасти пушистых тюленят!» будет проигнорирован или злобно прокомментирован даже теми хакерами, которые считают, что жизнь пушистых тюленят имеет для них значение.
Если вас это удивляет, перечитайте весь этот документ до тех пор, пока не поймёте, а до того воздержитесь от отправки вопросов вообще.
Будьте вежливы. Используйте фразы «Спасибо», «Заранее благодарен» или «Спасибо за Ваше понимание». Дайте понять, что вы благодарны людям, бесплатно посвящающим вам своё время.
Если честно, это не так важно, как отсутствие ошибок в тексте вопроса, ясность, точность и детальность описания, использование открытых форматов и т.п. (и не заменяет всё перечисленное). Хакеры, в общем случае, предпочли бы получать грубые, но технически точные сообщения об ошибках, чем вежливое словоблудие. (Если вас это удивляет, вспомните, что мы ценим вопрос за то, чему он нас учит).
Однако, при нормальном техническом уровне вопроса вежливость действительно повышает вероятность получить полезный ответ.
(Необходимо отметить, что единственное серьезное возражение, полученное на этот документ от ветеранов хакерского движения, связано с рекомендацией использовать фразу «Заранее благодарен». Некоторые хакеры усматривают в ней нежелание благодарить кого бы то ни было после того, как проблема будет решена. Мы рекомендуем благодарить и заранее, и после получения ответа, или выразить свою благодарность по-другому, скажем, фразой «Спасибо за внимание» или «Спасибо за ваше рассмотрение».)
После того, как ваша проблема решена, пошлите сообщение всем, кто вам помог, дайте им знать, чем всё закончилось, и поблагодарите ещё раз за помощь. Если проблема вызвала общий интерес в списке рассылки или дискуссионной группе, имеет смысл подобное сообщение отправить и туда.
Оптимальным решение будет ответить в нити обсуждения, начатой с исходного вопроса, добавив к теме сообщения пометку «FIXED», «RESOLVED», «РЕШЕНО» или другой не менее очевидный признак решения. В списках рассылки с большим количеством сообщений, потенциальный отвечающий при взгляде на нить обсуждения «Проблема Х», завершающуюся сообщением «Проблема Х - РЕШЕНИЕ» понимает, что ему не нужно тратить своё время даже на чтение сообщений (если он лично не считает Проблему Х интересной), и поэтому может потратить своё время на решение другой проблемы.
Такое сообщение не обязательно должно быть длинным и подробным. Простое: «Привет! Проблема была связана с разрывом в сетевом кабеле! Спасибо всем. Билл», - уже лучше, чем ничего. Фактически, краткое и вежливое резюме лучше, чем длинная диссертация, если только решение не затрагивает серьёзные технические аспекты. Напишите, какие действия позволили решить проблему, но всю последовательность поиска решения повторно описывать не надо.
Для достаточно серьёзных проблем можно послать резюме с историей поиска причин. Опишите окончательную постановку проблемы. Опишите, каким оказалось решение, и укажите тупиковые пути, которых стоит избегать. Назовите всех, кто помог вам: так вы найдёте себе друзей.
Помимо проявления вежливости и информирования, такого рода резюмирующее сообщение поможет другим при поиске в архиве списка рассылки/дискуссионной группы/форума точно узнать, какое решение помогло вам, и, значит, может помочь и им.
Последнее, но немаловажное, — такого рода сообщение помогает всем участвовавшим в обсуждении получить чувство удовлетворения от того факта, что проблема закрыта. Если вы сами не технический специалист и не хакер, просто поверьте нам, что это чувство очень важно для гуру и экспертов, к которым вы обращались за помощью. Описания проблем, так в итоге и не решённых — это сплошное разочарование, хакеры жаждут увидеть их решёнными. Хорошая карма, возникающая, когда вы удовлетворяете эту жажду, очень поможет вам при составлении вопроса в следующий раз.
Подумайте, как вы можете предотвратить возникновение такой проблемы у других пользователей в будущем. Спросите себя, поможет ли изменение документации или списка ЧаВО, и если да — пошлите соответствующее изменение тем, кто поддерживает эти документы.
Среди хакеров такое поведение, на самом деле, считается важнее обычной вежливости. Именно так зарабатывают репутацию хорошего командного игрока, которая является очень ценным качеством.
Есть древняя и священная традиция: если вы получаете ответ «RTFM», значит, отвечающий думает, что вам стоит почитать руководство (Read The Fucking Manual). Он почти наверняка прав. Идите читать.
У ответа RTFM есть более молодой аналог. Если вы получаете в ответ «STFW», значит, отвечающий думает, что вам стоит поискать ответ в сети (Search The Fucking Web). Он почти наверняка прав. Идите искать. (Более мягким вариантом этого выражения может быть фраза: «Гугл ваш друг!»)
В Web-форумах вам ещё могут предложить поискать в архивах форума. Нередко отвечающий может оказаться настолько любезен, что даст ссылку на предыдущее обсуждение, в котором эта проблема была решена. Однако надеяться на это не стоит. Лучше поискать в архивах форума, прежде чем спрашивать.
Часто тот, кто вам отвечает подобными фразами, имеет под рукой руководство или web-страницу с необходимой вам информацией, и смотрит на неё, когда набирает ответ. Эти ответы означают, что, по его мнению, во-первых, необходимую информацию легко найти и, во-вторых, вы большему научитесь при поиске информации, чем если вам её преподнесут под нос на тарелочке.
Вас это не должно возмущать, т.к. по хакерским стандартам, он оказал вам достаточное уважение уже тем, что не проигнорировал вопрос. Вы должны поблагодарить ответившего за его отеческую доброту.
Если вы не поняли ответа, не спешите тут же требовать его объяснить. Попробуйте воспользоваться теми же источниками информации, что и при поиске ответа на исходный вопрос (руководства, ЧаВО (FAQ), Web, опытные коллеги), чтобы понять ответ. Если и после этого вам необходимы разъяснения, попросите ответившего разъяснить свой ответ, показав, что вам самим удалось узнать.
Например, предположим, я вам ответил: «Похоже, у вас завис zentry. Надо проверить.» Тогда плохим уточняющим вопросом будет: «А что такое zentry?» А хорошим: «Ок, я прочитал страницу справочного руководства, и про zentry там упомянуто только в опциях -z и -p. Ни в одной из них не сказано, как сбросить зависший zentry. Надо ли использовать одну из этих опций, или я что-то неправильно понял?»
Большая часть того, что может показаться грубостью, в хакерских кругах используется не для оскорбления. Это, скорее, следствие непосредственного, без обиняков, стиля общения, естественного для людей, старающихся решать проблемы, а не казаться другим мягкими и пушистыми.
Если вы все же встретитесь с грубостью, постарайтесь реагировать спокойно. Если кто-то действительно выходит за рамки допустимого, вполне вероятно, что ведущий списка рассылки, дискуссионной группы или форума поставит его на место. Если этого не произошло и вы выйдете из себя, вполне вероятно, что ставшее причиной этого лицо ведёт себя в рамках норм хакерского сообщества, и все будут считать, что именно вы не правы. Это существенно снизит ваши шансы на получение необходимой информации или помощи.
С другой стороны, иногда можно встретиться с грубостью и вызовом, не имеющими никаких видимых оснований. Обратная сторона этой медали в том, что такая реакция является вполне приемлемой формой постановки на место действительных грубиянов, — мы отсекаем их недостойное поведение остро отточенным словесным скальпелем. Однако, вы должны быть очень уверены в своей позиции, прежде чем пытаться заняться этим. Грань между указанием на невежливость и началом бессмысленного «базара» (в оригинале — flamewar — прим. переводчика В.К.) настолько тонка, что и сами хакеры нередко её переходят. Если вы новичок или просто случайный читатель, шансов избежать такой грубой ошибки немного. Если вас интересует информация, а не развлечение, лучше уберите руки с клавиатуры и не рискуйте вступать в подобные дискуссии.
(Некоторые люди утверждают, что многие хакеры страдают мягкой формой аутизма или синдрома Аспергера, и у них просто не хватает той части мозга, которая отвечает за «нормальное» социальное взаимодействие между людьми. Возможно, это правда, а может и нет. Если вы не хакер, представление о хакерах как о больных на голову людях, может помочь вам смириться с нашими странностями. Думайте, что хотите. Нас это не волнует. Нам нравится быть именно такими, и к подобным медицинским ярлыкам мы относимся со здоровым скептицизмом.)
В следующем разделе мы поговорим о другой проблеме; о своего рода «грубости», с которой можно встретиться, когда именно вы не правы.
Вполне вероятно, что вы уже облажались несколько раз в хакерских форумах — так, как описано в этой статье или аналогично. И вам уже объяснили, как именно вы облажались, возможно в красках. При всём честном народе.
Когда такое происходит, самая неудачная реакция — жаловаться на случившееся, считать себя оскорблённым словесно, требовать извинений, вопить, задыхаться от гнева, подавать иски в суд, жаловаться работодателям обидчиков, не опускать за собой сидения унитаза и т.п. Вместо всего этого надо сделать следующее:
Смириться. Это — нормально. На самом деле, это хорошо и целесообразно.
Общественные нормы не поддерживают себя сами — их поддерживают люди, активно, в открытую, публично эти нормы применяющие. Не думайте, что критиковать должны только в личной переписке — это не так. Не имеет смысла принимать как личное оскорбление чей-то комментарий, что одно из ваших утверждений ошибочно, или что у него есть другое мнение. Так действуют только неудачники.
Были хакерские форумы, где, исходя из неправильно понятой гипертрофированной вежливости, участникам форума запрещалось отправлять сообщения об ошибках в чужие сообщения. Им было сказано: «Если не хотите помочь пользователю, молчите». Отток знающих участников в другие форумы привёл к вырождению форума в бессмысленную болтовню и к полной бесполезности с технической точки зрения.
Выбирайте: преувеличенная «дружественность» (такого рода) или полезность.
Помните: когда хакер пишет, что вы облажались, и (не важно насколько грубо) просит вас больше так не делать, он делает это, заботясь, во-первых, о вас, а во-вторых, о своём сообществе. Ему было бы намного проще вас проигнорировать и вычеркнуть из своей жизни. Если вас не хватает на благодарность, сохраните достоинство, — не жалуйтесь, и не думайте, что с вами будут обращаться как с хрупкой куклой лишь потому, что вы — новичок с театрально гиперчувствительной душой и иллюзиями о собственной значимости.
Иногда люди переходят на личности, вступая в грязную полемику без видимой причины и т.д., даже если вы и не облажались (или облажались только в их воображении). Возмущаться в таком случае, самый верный способ облажаться.
Эти «скандалисты» либо ламеры, которые ничего не понимают, но считают себя экспертами, либо потенциальные психологи, проверяющие облажаетесь вы или нет. Другие читатели их либо проигнорируют, либо найдут способы самостоятельно с ними разобраться. Поведение скандалистов создаёт проблемы для них самих, что не в кой мере не должно беспокоить вас.
Не позволяйте также втянуть себя в бесполезный «базар» (флейм). Такие обсуждения лучше сразу игнорировать, предварительно разобравшись, что это действительно пустой и бесполезный «базар», а не намёки на то, почему вы действительно облажались, и не тонко зашифрованные ответы на ваши фактические вопросы (так тоже иногда бывает).
Вот несколько классических глупых вопросов и о чём думают хакеры, когда на них не отвечают.
Где можно найти программу или ресурс X?
Там же, где и я её взял, придурок, — найти в Интернете. Боже, неужели ещё не все знают, как пользоваться Google.
Как можно с помощью X сделать Y?
Если вы хотите сделать Y, надо так и спрашивать, не предполагая заранее использование метода, который может вовсе не подходить. Вопросы такого вида часто задают те, кто не просто ничего не знает об X, но и сбит с толку решаемой проблемой Y и слишком сконцентрирован на деталях своей конкретной ситуации. Обычно лучше игнорировать таких людей, пока они не сформулируют свою проблему лучше.
Как сконфигурировать приглашение командного интерпретатора?
Если вы достаточно умны, чтобы этим заинтересоваться, вам хватит ума воспользоваться поиском и найти ответ самостоятельно.
Можно ли преобразовать AcmeCorp-документ в Tex-файл с помощью программы преобразования файлов Bass-o-matic?
Попробуйте и узнаете. Так, во-первых, узнаете ответ, а, во-вторых, перестанете тратить моё время.
Моя {программа, конфигурация, мой оператор SQL} не работает.
Это вообще не вопрос, и я не собираюсь задавать ещё десяток наводящих вопросов, чтобы выяснить, в чём на самом деле состоит ваша проблема — у меня есть дела и поинтереснее. Когда я вижу подобные вопросы, то обычно посылаю один из следующих ответов:
У меня проблемы с Windows-машиной. Не могли бы вы мне помочь?
Да. Выкиньте этот Microsoft-овский мусор и поставьте себе операционную систему с откртыми исходными кодами, например, Linux или BSD.
Примечание: вы можете задавать вопросы, связанные с Windows-машинами, если они относятся к программе имеющей официальную версию для Windows, или взаимодействующей с машинами под Windows (например, Samba). Просто не удивляйтесь ответу, что проблема в Windows, а не в самой программе, потому что Windows настолько «крива» в целом, что зачастую именно так и бывает.
Моя программа не работает. Я думаю, проблема в системном компоненте X.
Хотя и возможно, что именно вы первым обнаружили очевидную ошибку в системных вызовах и библиотеках, интенсивно используемых сотнями или даже тысячами разработчиков, но намного вероятнее, что вы просто не разобрались. Серьёзные утверждения требуют серьёзных доказательств. Если вы делаете подобные утверждения, их надо подкреплять ясным и исчерпывающим описанием ситуации, в которой возникает сбой.
У меня возникли проблемы с установкой Linux (или X). Не могли бы вы помочь мне?
Нет. Чтобы решить эту проблему, мне нужен непосредственный доступ к вашему компьютеру. Лучше задайте свой вопрос местной группе пользователей Linux (LUG — Linux User Group), которые смогут помочь вам лично. (Список групп пользователей можно найти здесь.)
Примечание: вопросы об установке Linux могут быть уместными в форуме или списке рассылки, посвящённому конкретному дистрибутиву, если проблема связана с этим дистрибутивом, или в форумах локальных групп пользователей. В этом случае, не забудьте точно описать подробности сбоя. Но сначала тщательно поищите в Web, указав ключевые слова «linux» и все подозрительные компоненты оборудования.
Как взломать пароль пользователя root/получить расширенные привилегии/прочитать чужую электронную почту?
Да ты просто жалок, раз хочешь такое сделать, и идиот, раз просишь хакера тебе помочь.
А сейчас я собираюсь показать на конкретных примерах, как надо правильно задавать вопросы. Я представлю пару вопросов об одной и той же проблеме, один — заданный не правильно, а второй — правильно.
Тупой: Где мне найти информацию о Foonly Flurbamatic
Этот вопрос просто напрашивается на ответ «STFW».
Правильно: Я попытался поискать информацию в Web с помощью Google по запросу «Foonly Flurbamatic 2600», но полезных ссылок не получил. Не знает ли кто-нибудь, где найти информацию о программировании этого устройства?
Этот вопрошающий уже поискал в Web, и похоже, у него реальная проблема.
Тупой: Я не могу скомпилировать код проекта foo. Почему он некорректен?
Он думает, что кто-то другой облажался. Самоуверенный тип.
Правильно: Код проекта foo не компилируетя в ОС Nulix версии 6.2. Я прочитал ЧаВО (FAQ), но там нет ничего о проблемах с Nulix. Вот запись сеанса компиляции. Что я сделал неправильно?
Он указал среду, прочитал часто задаваемые вопросы, показал сообщение об ошибке, и он не думает, что причина его проблемы в ошибке кого-то другого. Этому парню можно уделить немного внимания.
Тупой: У меня проблемы с материнской платой. Не может ли кто-нибудь мне помочь?
Любой хакер на такой вопрос в уме ответит скорее всего так: «Хорошо. Может, тебе ещё помочь срыгнуть и пелёнку поменять?», и нажмёт на клавишу Delete.
Правильно: Я пробовал X, Y и Z на материской плате S2464. Когда это не сработало, я попробовал A, B и C. Обратите внимание на странный симптом при попытке сделать C. Очевидно, что эта фигня не фурычит, но результаты получаются непредсказуемые. Что обычно приводит к тому, что не фурычат многопроцессорные материнские платы с Athlon? Нет ли у кого идей для дополнительных тестов, которые помогут изолировать проблему?
Этот товарищ, напротив, кажется достоин ответа. Он продемонстрировал способность решать проблемы, а не просто ждёт, пока ответ упадёт ему с неба.
В последнем вопросе обратите внимание на небольшую, но важную разницу между «Дайте мне ответ» и «Пожалуйста, помогите разобраться, какие дополнительные диагностические действия можно выполнить, чтобы прояснить ситуацию».
Фактически, пример последнего вопроса очень похож на вопрос из реальной жизни в августе 2001 года в списке рассылки linux-kernel (lkml). Я (Эрик) задал тогда этот вопрос. Я наблюдал странные зависания на материнской плате Tyan S2462. Участники списка рассылки предоставили ценную информацию, позволившую мне от этих зависаний избавиться.
Задавая вопрос так, как это сделал я, вы даёте людям пищу для размышлений. Я сделал для них участие в решении проблемы простым и привлекательным. Я продемонстрировал уважение способностей коллег и пригласил их к обсуждению на равных. Я также продемонсрировал, что ценю их время, описав по каким тупиковым ветвям я уже прошёл.
В конечном итоге, когда я поблагодарил всех и подчеркнул, насколько хорошо прошёл процесс решения проблемы, один из участников списка рассылки обратил внимание на то, что, по его мнению, всё получилось не потому, что я «известный человек» в этом списке рассылки, а из-за правильной формы постановки вопроса.
Хакеры, в определённом отношении, очень жестокая интеллектуальная элита (в оригинале — meritocracy. Прим. переводчика В.К.). Я уверен, что прав, и если бы я облажался, то был бы раскритикован или проигнорирован, независимо от прежних заслуг. Его предложение описать ситуацию в качестве инструкции для всех остальных стало непосредственной причиной составления этого руководства.
Если вы не получили ответа, не принимайте это на свой счёт, как наш отказ помочь лично вам. Иногда участники форума просто не знают ответ. Отсутствие ответа не равносильно игнорированию, хотя извне разницу заметить сложно.
В общем случае, повторная отправка вопроса будет не самой лучшей идей. Это будет расценено как бессмысленная надоедливость. Имейте терпение, отвечающий вам человек может находиться в другом часовом поясе и в это время спать. Или может оказаться, что ваш вопрос не был хорошо сформулирован, чтобы было с чего начать.
Есть и другие источники помощи, к которым можно обратиться, причём часто более приспособленные к нуждам начинающих.
Существует множество групп пользователей в сети и на местах, с энтузиазмом занимающихся программным обеспечением, хотя многие их участники в жизни не написали ни одной серьёзной программы. Эти группы часто формируются для того, чтобы участники помогали друг другу и новым пользователям.
Есть также масса коммерческих компаний, с которыми можно заключить контракт на поддержку, как крупных, так и маленьких (одни из наиболее известных — RedHat и SpikeSource). Пусть вас не пугает идея платить за поддержку. В конце концов, если необходим капремонт двигателя автомобиля, вы ведь отдадите его в мастерскую и заплатите за ремонт. Даже если программное обеспечение ничего не стоило, нельзя рассчитывать, что его всегда будут бесплатно поддерживать.
У популярного программного обеспечения, вроде Linux, на одного разработчика приходится, по крайней мере, 10000 пользователей. Один человек просто не может справиться с поддержкой 10000 пользователей. Помните, что даже если за поддержку приходиться платить, это всё равно обходится намного дешевле, чем когда приходиться покупать ещё и само программное обеспечение (да и поддержка закрытого программного обеспечения обычно стоит дороже и выполняется менее компетентными специалистами, чем в случае программного обеспечения с открытым исходным кодом).
Будьте великодушны. Связанный с проблемой стресс может делать невежливыми или глупыми людей, которые таковыми не являются.
На первую ошибку укажите в частном порядке. Нет необходимости публично унижать человека, который возможно, честно ошибается. Начинающий пользователь может не знать, как искать в архивах или где находится или публикуется список часто задаваемых вопросов (FAQ).
Если вы не уверены, так и говорите! Ошибочный, но авторитетно звучащий ответ хуже, чем отсутствие ответа. Не направляйте людей по ложному пути просто потому, что вам приятно быть в роли эксперта. Будьте скромны и честны. Показывайте хороший пример для спрашивающих коллег.
Если вы не можете помочь, не мешайте. Не шутите по поводу процедур, которые могут разрушить среду пользователя — этот болван может принять ваши шутки как руководство к действию.
Задавайте дополнительны вопросы, чтобы получить больше информации. Если это делать правильно, спрашивающий кое-чему научится, — да и вы тоже. Попытайтесь превратить плохой вопрос в хороший, и помните, все мы были когда-то начинающими.
Хотя простой ответ RTFM бывает оправдан, когда даётся просто лентяю, ссылка на документацию (даже если это набор ключевых слов для поиска в Google) всё же лучше.
Если уж вы отвечаете на вопрос, давайте ответ по сути. Не предлагайте наспех придуманные обходные пути, если используется в принципе не то средство или неверный подход. Предлагайте хорошие средства. Переформулируйте вопрос.
Помогите сообществу извлечь пользу из вопроса. Когда встречаетесь с хорошим вопросом, спросите себя: «Как надо изменить соответствующую документацию или список ЧаВО, чтобы больше этот вопрос никто не задавал?» Затем отправьте соответствующее дополнение тому, кто поддерживает эти документы.
Если для ответа на вопрос пришлось провести исследование, поделитесь своим опытом, а не пишите так, как будто ответ свалился на вас с неба. Ответить на один хороший вопрос — это как накормить голодного один раз, а вот изложить методику исследования на примере, — значит научить добывать еду на всю жизнь.
Если вам необходима информация по основам работы персональных компьютеров, ОС UNIX и сети Интернет, см. руководство The Unix and Internet Fundamentals HOWTO.
При создании программного обеспечения или выпуске исправлений для программ, постарайтесь следовать принципам, изложенным в руководстве Software Release Practice HOWTO.
Эвелин Митчел (Evelyn Mitchell) предложила прокомментировать ряд глупых вопросов и вдохновила на написание раздела «Как давать хорошие ответы». Михаил Рамендик дал ряд ценных предложений по улучшению документа.
За основу данного перевода я взял уже существующий перевод Валерия Кравчука. К сожалению, находившееся здесь однажды стал недоступен, да и версия самого перевода устарела. Поэтому я немного «причесал» текст (перестроил некоторые фразы, которые на мой взгляд стали лучше звучать), перевёл появившиеся дополнения. Насколько получилось, не мне судить, но буду рад любым отзывам как на своём блоге, так и по электронной почте.
Хочу выразить искреннюю признательность и благодарность Igor'ю Yakimchuk'у <i.yakimchuk at gmail.com> за указанные ошибки и «очепятки» в данном руководстве; Aleksey Batitskiy за указанную опечатку и уточнение перевода; Михаилу Ульянич <ulianich_mihail at ukr.net> за большое и информативное письмо с указанием ошибок в переводе и очепяток в тексте.