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

nobus	# 13 лет, 6 месяцев назад (отредактировано 13 лет, 6 месяцев назад)
Темы: 67 Сообщения: 1067 Участник с: 01 января 2010	Предлагается перевод статьи из 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! Нам необходимо как можно больше сообщений! Просто войдите на сайт или зарегистрируйтесь для участия. Оригинал: Software Discussion Etiquette Автор: Sloshy Дата публикации оригинала: 19.05.2011 Говорила мама: "RTFM, сынок!"

# 13 лет, 6 месяцев назад (отредактировано 13 лет, 6 месяцев назад)

Сообщения: 1067

Участник с: 01 января 2010

Предлагается перевод статьи из 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! Нам необходимо как можно больше сообщений! Просто войдите на сайт или зарегистрируйтесь для участия.

Оригинал: Software Discussion Etiquette
Автор: Sloshy
Дата публикации оригинала: 19.05.2011

Говорила мама: "RTFM, сынок!"

jnarical	# 13 лет, 4 месяца назад
Темы: 3 Сообщения: 11 Участник с: 30 сентября 2010	Нередко обсуждение различных ошибок в программе скатывается в личную перепалку. Поверьте - разработчикам хочется, чтобы пользователь был вежливым и внятно объяснял проблему. Следуя указаниям ниже, вы сможете принести любимому проекту максимальную пользу вместо того, чтобы выглядеть уродом. Заманчиво? 1. Выражайтесь максимально ясно и кратко Как и при отправке баг-репорта, высказывания должны нести в себе достаточно информации. Фраза “Помогите комп не грузится!” слишком общая, в противовес “Рабочий стол не грузится, вот лог ошибки”. (Тут кусок про regressions, я не специалист и не понимаю смысла, так что перевести не смог - а в “оригинальном” переводе нутром чувствую смысловые косяки) 2. Будьте готовы признать свою неправоту, ведите себя вежливо и скромно В мире науки, на каждую публикацию обрушиваются горы критики - это нормально. При разработке программ нередко ведутся жаркие споры о том, каким должен быть интерфейс пользователя, и многие идеи отвергаются разработчиками. Неприятно, когда страдает гордость, но если именно ваше предложение было отвергнуто - не стоит писать гневные тексты, шансы на его принятие от этого не увеличатся. Одним словом, переходить на личности или утверждать, что разработчики не знают, как им надо работать - значит вести себя грубо. Списки рассылки часто имеют формальный тон. Вы можете получить ответ, что ваше предложение “неверно”, “неверно” или “не нужно”. Хотя разработчики стараются быть вежливыми, краткость и “формальность” ответа могут выглядеть грубовато. Получив такой ответ, нужно либо попытаться понять видение разработчика, либо иметь веские аргументы, чтобы продолжить настаивать - напомню - в максимально вежливой форме! Нередки подобные ситуации, которые пользователи окрестили “Придумано не нами” - когда предложение извне отвергается группой разработчиков, хотя для этого нет видимых причин. На самом же деле, когда они отвергают какое-то предложение или патч - у них скорее всего есть на то причины. Если вы уверены в важности вашего вклада в проект - свяжитесть с ними, и сделайте это на стадии планирования! Не стоит втихую писать патч, отправлять его и ожидать, что он непременно будет включен в проект. Иногда, когда вы работаете над своим вкладом в проект, разработчики могут помогать и способствовать - если этого не происходит, шансы на принятие вашего вклада в проект сильно уменьшаются. Например, разработчики GNOME отклонили libappindicator, и близок к этому LightDM, потому что пока не является адекватной заменой GDM. 3. Перед тем, как задать вопрос, поищите ответ самостоятельно! “Куда делся список окон, присутствующих на всех рабочих столах одновременно?” - этот вопрос не дает покоя людям, и как минимум дважды в месяц его задают в списке рассылки GNOME Shell. Легко объяснить, почему нет списка окон - ответ дан многократно, на сотне различных форумов. Достоточно вбить пару слов в Google или пролистать пару страниц на форумах. Позвольте разработчикам заниматься своей прямой работой над проектом, вместо того чтобы отвечать раз за разом на одни и те же, пусть и простые, вопросы - пользуйтесь поиском. Это относится также и к таким средствам общения, как IRC и веб-чаты. 4. Откажитесь от сообщений в стиле “+1” Как и в случае баг-репортов, не давайте ответы, содержащие только “+1”, “Я согласен” или “у меня тоже” без какой-либо дополнительной информации. Пишите подобное, если этот факт важен для разработчика. Основной критерий тут - помогает ли ваш текст исправить проблему. 5. NcnoJIb3yNTe соответствующую грамматику и орфографию Используйте проверку орфографии. Перечитывайте свое сообщение перед отправкой. Даже если с грамматикой все в порядке - возможно, стоит перефразировать предложения, чтобы текст был более кратким, емким и ясным. ВСЕГДА избегайте 1337-speak'а, за исключением общеупотребительных нейтральных сокращений, если они уместны (IMHO, afaik, btw) - но и ими не стоит злоупотреблять. Если вы чувствуете, что ваш английский язык не столь хорош и может быть неправильно понят - укажите это в сообщении. Чем приятнее с вами работать - тем больше будет ваш вклад в проект. Не забывайте этого.

jnarical

# 13 лет, 4 месяца назад

Темы: 3

Сообщения: 11

Участник с: 30 сентября 2010

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

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

1. Выражайтесь максимально ясно и кратко

Как и при отправке баг-репорта, высказывания должны нести в себе достаточно информации. Фраза “Помогите комп не грузится!” слишком общая, в противовес “Рабочий стол не грузится, вот лог ошибки”.
(Тут кусок про regressions, я не специалист и не понимаю смысла, так что перевести не смог - а в “оригинальном” переводе нутром чувствую смысловые косяки)

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

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

Списки рассылки часто имеют формальный тон. Вы можете получить ответ, что ваше предложение “неверно”, “неверно” или “не нужно”. Хотя разработчики стараются быть вежливыми, краткость и “формальность” ответа могут выглядеть грубовато. Получив такой ответ, нужно либо попытаться понять видение разработчика, либо иметь веские аргументы, чтобы продолжить настаивать - напомню - в максимально вежливой форме!

Нередки подобные ситуации, которые пользователи окрестили “Придумано не нами” - когда предложение извне отвергается группой разработчиков, хотя для этого нет видимых причин. На самом же деле, когда они отвергают какое-то предложение или патч - у них скорее всего есть на то причины. Если вы уверены в важности вашего вклада в проект - свяжитесть с ними, и сделайте это на стадии планирования! Не стоит втихую писать патч, отправлять его и ожидать, что он непременно будет включен в проект. Иногда, когда вы работаете над своим вкладом в проект, разработчики могут помогать и способствовать - если этого не происходит, шансы на принятие вашего вклада в проект сильно уменьшаются. Например, разработчики GNOME отклонили libappindicator, и близок к этому LightDM, потому что пока не является адекватной заменой GDM.

3. Перед тем, как задать вопрос, поищите ответ самостоятельно!

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

4. Откажитесь от сообщений в стиле “+1”

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

5. NcnoJIb3yNTe соответствующую грамматику и орфографию

Используйте проверку орфографии. Перечитывайте свое сообщение перед отправкой. Даже если с грамматикой все в порядке - возможно, стоит перефразировать предложения, чтобы текст был более кратким, емким и ясным. ВСЕГДА избегайте 1337-speak'а, за исключением общеупотребительных нейтральных сокращений, если они уместны (IMHO, afaik, btw) - но и ими не стоит злоупотреблять. Если вы чувствуете, что ваш английский язык не столь хорош и может быть неправильно понят - укажите это в сообщении.

Чем приятнее с вами работать - тем больше будет ваш вклад в проект. Не забывайте этого.