-------------------------------------------------------------------------------
Пожалуйста, прочтите все эти ответы перед отправкой письма. Я знаю, что это довольно долго, но вы можете выставить себя дураком перед 50 000 людей и отнять у них сотни часов личного времени. Не кажется ли вам, что стоит потратить немного вашего времени, чтобы прочесть и последовать этим инструкциям?
Если вы полагаете, что ответ не полный или не точный, пожалуйста, сообщите об этом Роберту Кислингу (Robert Kiesling) на kiesling@terracom.net.
Прочтите соответствующие документы Linux Documentation Project - см. "Где я могу найти HOWTO и другую документацию?"
Если вы новичок в Unix, прочтите FAQ в comp.unix.questions и в любых других группах comp.unix.*, которые могут иметь отношение к вашему вопросу.
Linux имеет так много общего с другими коммерческими версиями Unix, что почти всё, что вы прочли для последних, вы можете смело применять к Linux. Файлы с FAQ, как и все FAQ, основываются файлах с rtfm.mit.edu в /pub/usenet/news.answers (сервер mail-server@rtfm.mit.edu может выслать вам эти файлы, если у вас нет доступа к FTP). На различных сайтах существуют зеркала архивов rtfm с FAQ - проверьте Introduction к рассылке *.answers или загляните в news-answers/introduction из директории верхнего уровня.
Проверьте документы HOWTO, имеющие отношение к теме вашего вопроса, если таковые существуют, или подходящие документы sub-FAQ старого образца. Проверьте сайты FTP.
Попробуйте поэкспериментировать - это наилучший способ изучить Unix и Linux.
Прочтите документацию. Просмотрите manual pages (наберите "man man", если вы не знаете, как пользоваться manual pages). Попробуйте набрать "man -k subject" - довольно часто это позволяет получить список полезных и нужных вам manual pages.
Просмотрите документацию Info (наберите C-h i, т.е. Control H заменяется I в Emacs). Это применимо не только для Emacs. Например, там также находится документация по GCC.
Также часто с пакетом установки программ поставляется файл README и/или инструкции по использованию.
Убедитесь, что у вас не испорченная или устаревшая копия программы, по которой возник вопрос. Если это возможно, скачайте её заново или переустановите её - возможно произошел сбой при скачивании или вы совершили ошибку при первой установке.
Прочтите документ comp.os.linux.announce - он часто содержит очень важную информацию для всех пользователей Linux.
Основные вопросы по системе X Window сосредоточены в comp.windows.x.i386unix, а не в comp.os.linux.x. Но сначала прочтите содержание группы (включая FAQ), перед отправкой сообщения.
И только если проделали все выше описанные операции и всё-таки застряли на своём вопросе, вы должны отправить сообщение в подходящую группу новостей comp.os.linux.*. Убедитесь, что вы сначала прочитали следующий вопрос ("Что дожен содержать запрос для получения помощи.").
-------------------------------------------------------------------------------
Пожалуйста, внимательно прочтите следующий совет о том, как написать e-mail или сообщение на usenet. Составление полного отчёта значительно увеличит шансы того, что эксперт или опытный пользователь, прочитавший его, будет иметь достаточно информации и повод для ответа.
Этот совет относится к составлению как сообщения на usenet, так и личного email эксперту или опытному пользователю.
Убедитесь, что вы указали полную информацию о проблеме, включая:
-version.Вы можете оказаться в затруднительном положении, если ваш отчёт будет слишком длинным, за исключением больших кусков кода или Unix-Unix-кодированных файлов, поэтому представление слишком большого количества информации является ошибочным мнением.
Используйте чёткую и подробную тему. Не используйте в ней фразы типа "не работает", "Linux", "нужна помощь" или "вопрос" - мы и так уже об этом знаем. Оставьте место для названия программы, фрагмента сообщения об ошибке или краткого изложения необычного поведения программы.
Если в вашем отчёте будет следующая строка: "unable to handle kernel paging request", следуйте инструкциям файла README к исходникам ядра Linux для преобразования цифр во что-либо более понятное. Если вы не сделаете этого, никто из тех, кто прочтёт ваш отчёт, не сможет сделать этого за вас. Соответствие номеров функций их именам изменяется от одной версии ядра к другой.
Разместите параграф с summary (кратким изложением проблемы) в начале отчёта.
В конце вашего отчёта укажите свой email и скажите, что вы отправите summary. Подтвердите это, используя службу Followup-To: poster. Затем на самом деле оправьте summary в течение нескольких дней или недель. Не сваливайте присланные ответы в общую кучу - анализируйте и подводите итоги. Также неплохо было бы поместить слово SUMMARY в строке Subject вашего summary. Подумайте над отправкой summary в comp.os.linux.announce.
Убедитесь, что ваше сообщение не содержит ненужного пункта: заголовка. Это сделает вашу статью частью потока связанных статей, что часто становится причиной того, что сообщение будет проигнорировано читателями вместе со статьями скучного потока.
Вы можете привлечь к себе внимание, написав в вашем сообщении, что вы уже прочитали эти FAQ и соответствующие документы HOWTO - это может убедить людей не пропускать вашего сообщения.
Помните, что вы не должны публиковать электронные письма, присланные вам лично, без разрешения отправителя.
-------------------------------------------------------------------------------
Попробуйте найти автора или разработчика какой-либо программы или компонента, вызывающего у вас затруднения. Если у вас есть связь с распространителем вашего Linux, вы должны воспользоваться ею.
Пожалуйста, поместите всё необходимое в ваше сообщение e-mail, которое вы размещаете на конференции за помощью.
Наконец, запомните, что не смотря на факты, большинство пользователей сообщества Linux очень помогают и отвечают на присланные по e-mail вопросы. Вы просите помощи у добровольцев, не получающих за это ни копейки, поэтому у вас нет гарантии, что вы получите ответ.