Linux-HELP, Спрашивайте - ответим Опции

[ChapaySergey]

Если есть проблемы с Linux спрашивайте постараюсь ответит

[LInfo]

Если ответ не получен

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

В общем случае, повторная посылка вопроса - не лучшая идея. Это будет воспринято как бессмысленная надоедливость. Имейте терпение: тот, кто способен ответить, может быть в другом часовом поясе и спать. А может быть, ваш вопрос просто не достаточно хорошо сформулирован.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оригинал статьи взят отсюда. Ваши замечания и предложения по данному переводу шлите мне.

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