Форум StopLinux

Этикет при обсуждении ПО

Предлагается перевод статьи из Rolling Release.

Читая обсуждения программного обеспечения, я нахожу, что существует немало людей, которые не понимают, как правильно себя вести, что приводит к тому, что дискуссии превращаются в жаркие споры, переходящие на личности участников. В качестве помощи по уменьшению потенциального ущерба, наносимого ходом этих дискуссий, я пишу этот пост для Rolling Release об этикете при обсуждении программного обеспечения, как духовный последователь блога Allan McRae, "Как отправить Bug Report (Отчет об ошибке)". В своем блоге Allan перечисляет несколько вещей, которые необходимо иметь в виду, и эти вещи применимы и здесь. Несмотря на то, что я не претендую быть экспертом по этикету, я знаю из первых уст, что разработчики и дизайнеры хотят видеть взаимодействующиих с ними пользователей настолько милыми и простыми (в общении), насколько это возможно. И, следуя (по крайней мере) данными общим указаниям, вы можете помочь вашему любимому проекту тем, что не будете тупицей и грубияном в одном лице :-).

1. Будьте ясным и кратким
Как и при сообщении об ошибке, все дискуссии должны иметь соответствующий контекст. Фраза "Помогите, мой компьютер не загружается" очень расплывчата, в то время как "Мой рабочий стол не загружается, вот лог ошибки:" -- намного более точная формулировка. Если вы спрашиваете о решениях дизайнеров-разработчиков или о возвращении ПО к более ранней версии (регрессии), приведите список примеров того, какой могла бы быть подобная регрессия, а не просто справшивайте о том, что это такое и не говорите, что надо оставить все как есть. Ничто так не раздражает разработчиков, чем толпы людей, говорящих о регрессии без доказательства, что это так, особенно, если ответ на их требования были уже многократно услышаны ранее (подробнее см. пункт 3 ниже).

2. Будьте готовы сказать, что вы ошибаетесь; оставайтесь спокойным, вежливым и скромным
Когда вы делаете научную публикацию, эта публикация подвергается большой критике и попыткам опровергнуть ваши выводы. Это вполне ожидаемо. В мире программного обеспечения идет много интенсивных дискуссий о "правильном" пути создания интерфейса пользователя (UI) и многие предложения отклоняются. Никто не любит ударов по своей гордости, но если вы подадите предложение и дизайнеры не согласятся с вами, ваша гневная реакция не станет конструктивным поступком и только уменьшит вероятность принятия вашего предложения. Переход к необоснованным оскорблениям и обвинениям, гласящим, что разработчики и дизайнеры не знают, что они делают, является вредным, грубым и, во многих случаях, крайне неправильным. Например, Списки рассылки программного обеспечения, как правило, имеют весьма формальный тон. Вы можете получить ответ, гласящий, что ваши утверждения "неверные", "неправильные" или "ненужные". Разработчики и дизайнеры обычно стараются не быть грубыми, и они обычно полагают, что этот ответ не звучит так (грубо). Если разработчик или дизайнер отвергает ваши предложения, вы должны либо постараться понять их видение проблемы, либо вежливо отклонить возражение.
Один общий пример не следует этому правилу, когда пользователи вешают на группу разработчиков ярлык синдрома "Придумано не здесь (Not Invented Here)" (что-то отвергается только потому, что это не было создано внутри группы), что, как правило, не соответствует действительности. Когда разработчики не принимают исправления, предложения, или что-либо из этого, это не обязательно происходит потому, что предлагаемое "придумали не здесь", но скорее потому, что у них имеется, по крайней мере, одна причина, по которой они считают, что предлагаемое не должно быть включено. Если Вы уверены, что ваше предложение или дополнение будет полезным для проекта, поговорите с ним об этом как можно скорее на стадии планирования, а не после того как данная стадия завершена. Не ведите работу над этим усовершенствованием, представьте его и ожидайте от них санкционирования независимо ни от чего. Иногда когда вы предлагаете дополнение к проекту, разработчики могут помочь вам внести свой вклад в дизайн, и если они не участвуют в этом процессе, то гораздо больше шансов, что ваше дополнение будет отклонены по причине, что проект слишком поздно менять. Например, GNOME отклонил libappindicator по различным причинам (хронология этой драматической истории представлена здесь), а недавно там прошло обсуждение LightDM в качестве предполагаемой замены для GDM, весьма близкое к отказу от рассмотрения данного проекта в качестве адекватной замены GDM.

3. Произведите исследование прежде, чем задавать вопросы
"Почему нет вездесущего списка окон в GNOME 3?" Этот вопрос закольцевался в головах людей, использующих список рассылки GNOME Shell, он возникает по крайней мере два раза в месяц (как кажется). Очень легко объяснить, почему нет списка окон, и это объяснение уже было дано несколько раз прежде, во многих различных сообщениях (тредах) и на различных страницах разработчиков. Достаточно поднять один или два из этих тредов, читать страницы разработчиков или воспользоваться поисковой системой Google, чтобы узнать ответ. Лучше было бы дизайнерам и разработчикам заниматься своими разработками и проектированием, чем отвечать на одни и те же вопросы снова и снова, так что сделайте им одолжение и тщательно исследуйте свой вопрос прежде, чем задать его. Это относится и к IRC, а также и к другим средствам информации и коммуникации.

4. Не говорите "у меня тоже"
Как и в случае сообщения об ошибке, не давайте ответы, содержащие только "+1", "Я согласен" или "у меня тоже" без какой-либо дополнительной информации. Если вы так говорите, не забудьте добавить что-то после своего ответа, например, что вы считате это важным или же озабочены этой проблемой.

5. NcnoJIb3yNTe соответствующую грамматику и орфографию
Всегда выполняйте проверку орфографии (просто быть на всякий случай) и перечитывать ваши сообщения перед отправкой. Даже если вам не нужно исправить орфографию и грамматику, вы всегда можете перефразировать предложения, чтобы сделать сообщение звучащим более профессионально. Старайтесь во всяком случае избегать 1337sp34k (интернет-жаргонизмов и мемов, таких, как "LOL" или "noob"), хотя иногда сокращения наподобие  "btw", "atm", "IIRC" или "AFAIK" могут считаться приемлемыми в зависимости от того, где имеет место ваше обсуждение. Если английский не является вашим родным языком, не забудьте упомянуть этом, если вы чувствуете, что вашу грамматику или структуру предложения трудно могут быть поняты теми людьми, для кого английский является родным языком.
Таким образом, всякий раз, когда участвуете в обсуждении программного обеспечения, будь то список рассылки, IRC, BBS, или трекер ошибок, убедитесь, что вы выступаете терпеливым, знающим и открытым человеком. Чем приятнее ваше участие в работе, тем больше работы может быть сделано в проекте ПО, о котором идет речь. Помните это и старайтесь соблюдать :-)!
Кроме того, помните, что вы можете присылать свои статьи в Rolling Release! Нам необходимо как можно больше сообщений! Просто войдите на сайт или зарегистрируйтесь для участия.

Источник: https://archlinux.org.ru/node/284

//от себя:// думается, что и некоторым критЕГам Линуха не мешало бы ознакомиться с этой статьёй и принять её к сведению.