Глава 6. Общение

Содержание

Вы то, что вы пишете
Структура и форматирование
Содержание
Тон
Как отличить грубость?
Лицо
Как избежать распространенных ошибок?
Не посылайте сообщения без цели
Продуктивные и непродуктивные темы
Чем шире вопрос, тем длиннее споры
Как избежать религиозных войн?
Эффект "шумящего меньшинства"
Тяжёлые люди
Как управляться с тяжёлыми людьми
Пример: трудные люди
Управление ростом
Широко используйте архивы
Трактуйте все ресурсы как архивы
Кодификация традиций
Нет разговорам в трекере ошибок
Публичность
Объявление о дырах в безопасности
Получите отчёт
Негласно разработайте исправление
Номера CAN/CVE
Пред-объявление
Публичное распространение исправления

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

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

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

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

Вы то, что вы пишете

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

Внимательное отношение к стилю вашего письма вернётся сторицей. Старый хакер свободного ПО Джим Блэнди (Jim Blandy) рассказывает такую историю:

В далёком 1993 году я работал на Free Software Foundation, и мы занимались бета-тестированием версии 19 GNU Emacs. Мы выпускали бета-версию каждую неделю или около того, а люди испытывали её и присылали нам отчёты об ошибках. Был один парень, которого никто из нас не встречал в жизни, но который делал огромную работу: его отчёты об ошибках всегда были понятными и прямо наводили нас на проблему, а когда он сам представлял решение, оно почти всегда было правильным. Он был превосходен.

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

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

Он прислал мне в ответ: "У меня нет работодателя."

Тогда я сказал: "Ладно, хорошо, пусть подпишет ваш университет и присылайте обратно."

Через некоторое время он ответил мне снова: "Ну, на самом деле... мне тринадцать лет и я живу с родителями."

Так как этот парень не писал как тринадцатилетний, никто и не знал, сколько ему. Далее изложено несколько способов, как сделать, чтобы ваши документы также производили хорошее впечатление.

Структура и форматирование

Не загоняйте себя в ловушку, излагая всё так, будто пишете смс. Пишите полными предложениями, каждое предложение с большой буквы, используйте где нужно разрывы параграфов.Это наиболее важно для электронной почты и других составных документов. В IRC и других непостоянных форумах обычно допустимо забывать про заглавные буквы, использовать сжатые формы общеупотребительных выражений и т.д. Только не переносите эти привычки в более формальные, постоянные форумы. Электронная почта, документация, сообщения об ошибках и другие виды документов, которым предназначена долгая жизнь, должны быть написаны с использованием стандартной грамматики и орфографии и иметь структуру связного рассказа. И это не потому, что следовать набору чудаковатых правил правильно, а потому, что эти правила не случайны: они эволюционировали в свои настоящие формы, потому что их использование делает текст более читаемым, и вы должны придерживаться их по этой причине. Читабельность важна не только потому, что она способствует понимаю текста большим числом людей, но и потому, что вы при это смотритесь как человек, уделяющий время ясности написанного, то есть как человек стоящий.

В частности, для электронной почты опытные разработчики ПО с открытым кодом выработали следующие соглашения:

Посылайте сообщения только в формате простого текста, не в HTML, RichText, или других форматах, которые могут не увидеть почтовые программы, работающие только с простым текстом. Форматируйте строки так, чтобы они были примерно 72 символа в длину. Не заходите за 80-ю колонку, которая стала стандартом де-факто для ширины терминала (некоторые люди могут использовать более широкие терминалы, но никто не использует более узкие). Делая свои строки немногоменьше 80 символов, вы оставляете место для нескольких уровней символов цитирования, которые добавятся в ответах других людей, без необходимости переформатирования вашего текста.

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

При включении экранных выводов, кусков кода или другого превдарительно форматированного текста явно выделите его, так чтобы даже уставшие глаза могли легко увидеть границы между вашей прозой и данными, которые вы цитируете. (Я не собирался приводить этот совет, когда начинал писать книгу, но позже во множестве списков рассылки ПО с открытым кодом я встретил людей, которые смешивали текст из разных источников, не разделяя чётко что есть что. Эффект весьма печален. Их сообщения становятся трудны для понимания и, если честно, такие люди выглядят несколько неорганизованными.)

Когда цитируете чьё-либо письмо, вставляйте свои ответы там, где они наиболее уместны, в нескольких разных местах, если нужно, и вырежьте те части исходного сообщения, на которые которые вы не отвечали. Если вы пишите короткий комментарий, который относится к сообщению в целом, можно поместить его выше всего (то есть, выше цитируемого текста исходного сообщения); в противном случае вы сначала должны процитировать соответствующую часть исходного текста, а затем вставить свой ответ.

Хорошо подумайте над темой нового сообщения. Это наиболее важная строка в вашем почтовом сообщении, потому что она позволяет любому другому человеку в проекте решить, читать его дальше или нет. Современные программы чтения почты собирают группы связанных сообщений в ветки, которые могут определяться не только общей темой, но и другими заголовками (которые иногда не отображаются). Отсюда следует, что если в ветке всплывает новая тема, вы можете—и должны —установить соответствующую тему при ответе. Целостность ветки будет сохранена, благодаря другим заголовкам, но новая тема поможет людям, просматривающим ветку, понять, что вопрос стал шире. И наоборот, если вы действительно хотите поднять новый вопрос, делайте это с помощью нового сообщения, а не отвечайте на существующее, изменив тему. В противном случае ваша почта всё ещё будет сгруппирована в ту же ветку, что и сообщение, на которое вы отвечаете, и тогда люди будут ошибочно полагать, что ваша почта относится к той теме а это не так. И в этом случае они не только потеряют свое время, но и доверие к вам, как к человеку который свободно владеет инструментами общения, будет подорвано.

Содержание

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

Упрощайте доступ к информации своим читателям. Вокруг любого активного проекта ПО с открытым кодом витает масса информации, и нельзя полагаться на то, что читатели хорошо знают большую её часть,—вообще, нельзя полагаться, что они знают как её узнать. Вне зависимости от метода коммуникации ваше сообщение должно предоставлять информацию в форме, наиболее удобной для читателей. Если вы потратите две лишних минуты, чтобы откопать URL на конкретную ветку в архивах списка рассылки и тем самым избавите читателей от этого поиска,— оно того стоит! Если вам нужно потратить 5-10 минут на то чтобы подвести итоги, накопившиеся в разросшейся ветке, только для того, чтобы дать людям контекст, в рамках которого надо рассматривать ваше сообщение, сделайте это. Думайте об этом так: чем более успешен проект, тем большее количество читателей приходится на одного писателя на любом из форумов. Если каждое ваше сообщение видят N людей, то при росте Nценность затрат на дополнительные усилия, экономящие время этих людей, также растёт. И если люди видят, что вы сами следуете такому стандарту, они будут работать над тем, чтобы соответствовать ему в своих коммуникациях. В идеале, результатом является рост общей эффективности проекта: когда появляется выбор—тратить ли время всем или одному человеку, проекту выгоднее последнее.

Не увлекайтесь гиперболами. Преувеличение в сетевых сообщениях - это классическая гонка вооружений. Например, человек, сообщающий об ошибке, может беспокоиться, что разработчики не уделят достаточно внимания, поэтому он описывает ошибку как серьёзную, не дающую работать проблему, которая не позволяет ему (и всем его друзьям/коллегам/родственникам) продуктивно использовать ПО, хотя на самом деле это всего лишь мелкое неудобство. Но преувеличение не ограничивается пользователями. Программисты часто занимаются такими же вещами во время технических дебатов, особенно когда не могут сойтись во вкусах больше, чем в правильности технического решения:

"Поступив так, мы можем сделать код совершенно нечитаемым. Это будет кошмаром при сопровождении, по сравнению с предложением J.Random'а..."

То же мнение на самом деле становится сильнее, если выражено менее агрессивно:

"Это работает, но далеко не идеально в терминах читаемости и сопровождения, я так думаю. Предложение J.Random'а обходит эти проблемы, потому что оно..."

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

Редактируйте дважды. Любое сообщение длиннее параграфа среднего размера перечитайте целиком перед отправкой после того, как решили что оно закончено. Это совет знают те, кто посещал уроки писательства, но для сетевых дискуссий он особенно важен. Поскольку написание сообщений в сети зачастую связано с прерыванием на другие дела (во время составления сообщения может возникнуть надобность вернуться назад и проверить другие почтовые сообщения, посетить какие-то сайты, выполнить команды для получения их отладочных выводов, и т.д.), очень легко потерять нить рассказа. Сообщения, которые появились в результате такого несвязного процесса и не были проверены перед отправкой, часто и выглядят несвязными, к огорчению (по крайней мере так хотелось бы думать) их авторов. Потратьте время на пересмотр того, что вы посылаете. Чем более структурированы ваши сообщения, тем больше их будут читать.

Тон

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

Не могли бы вы более детально описать, с какой проблемой вы столкнулись,
	и т.п.?
	
	А также:
	
	Какую версию Slash вы используете? Я не смог понять из вашего первого
	сообщения.
	
	Как в точности вы собрали apache/mod_perl из исходников?
	
	Пробовали ли вы патч для Apache 2.0, о котором шла речь на 
	slashcode.com?
	
	Шейн

Вот это краткость! Ни приветствия, ни подписи, кроме имени, и само сообщение - это просто серия вопросов, выраженных настолько сжато, насколько возможно. Единственное повествовательное предложение представляло собой неявную критику моего первого сообщения. И всё-таки, я был счастлив увидеть почту Шейна, и не воспринял его краткость как что-то большее, чем признак занятости. Тот факт, что он задавал вопросы, а не проигнорировал моё сообщение, означал, что он был готов потратить время на мою проблему.

Будут ли все читатели позитивно реагировать на такой стиль? Не обязательно; это зависит от человека и от контекста. Например, если кто-то, скажем некая девушка, просто послала уведомление о том, что сделала ошибку в коде (которая приводит к багу), а вы знаете из предыдущего опыта, что она - человек эмоциональный, то, хотя вы по прежнему можете написать краткий ответ, вы должны позаботиться о её чувствах. Основная часть ответа, анализ ситуации глазами инженера, может быть короткой, как пожелаете. Но в конце напишите что-то, показывающее, что ваша краткость не означает холодности. Например, если вы просто даёте массу советов, как человек должен исправить ошибку, то подпишитесь "Удачи, <добавьте его имя>, чтобы показать, что вы желаете ему хорошего и не сердитесь. Удачно размещенный смайл или другие эмотиконы также часто помогают умиротворить собеседника.

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

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

Как отличить грубость?

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

Давайте начнём с вещей, которые не являются грубостью:

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

Прямые, без прикрас вопросы, такие, как вопросы Шейна ко мне в процитированном выше сообщении, также не являются грубостью. Вопросы, которые в другом контексте могут казаться холодными, риторическими, и даже насмешкой, часто задаются серьёзно и не имеют скрытых намерений, кроме получения информации как можно быстрее. Классический пример - вопрос службы технической поддержки "Ваш компьютер включен в розетку?" Сотрудник службы поддержки действительно должен знать, включен ли компьютер в розетку, и, после первых нескольких дней работы, устаёт предварять свой вопрос вежливыми уговорами ("Я очень извиняюсь, но только хочу задать вам несколько простых вопросов, чтобы исключить некоторые возможные ситуации. Некоторые из них могут показаться весьма несущественными, но давайте их пройдём..."). Теперь он больше не беспокоится об этих "подстилках" и просто спрашивает прямо: включен ли компьютер или нет? В почтовых списках рассылки свободного ПО постоянно задаются одинаковые вопросы. Целью является не оскорбление адресата, а быстрое исключение наиболее очевидных (и, возможно, наиболее общих) объяснений. Адресаты, которые понимают это и реагируют соответственно, набирают очки, получая широкий отклик без дополнительных запросов. Но те, кто реагирует неправильно, также не должны страдать. Это просто коллизия культур, а не чей-то проступок. Дружелюбно объясните, что ваш вопрос (или критика) не имеет скрытых смыслов; он просто предназначен для получения (или передачи) информации наиболее эффективным способом, ничего больше.

Тогда что есть грубость?

Согласно тому же принципу, по которому детальная техническая критика есть форма лести, отказ предоставить качественную критику может быть видом оскорбления. Я не имею в виду простое игнорирование чьей-то работы, будь это положим, изменения в коде, регистрация новой проблемы, или ещё что-то. Если только вы заранее не обещали подробного анализа, обычное поведение - никак не реагировать. Люди будут полагать, что у вас просто нет времени, чтобы хоть что-то сказать. Но если вы реагируете, не скупитесь: найдите время для реального анализа проблемы, приведите конкретные примеры там, где это уместно, покопайтесь в архивах, чтобы найти связанные сообщения в прошлом и т.д. Либо, если у вас нет времени на такие усилия, но всё же надо написать что-то короткое в ответ, обозначьте это открыто в своём сообщении ("Я думаю, что для этого случая уже зарегистрирована проблема, но, к сожалению, не имею времени, чтобы её найти. Извините."). Главное - осознать наличие культурной нормы, либо следуя ей, либо открыто извещая, что кто-то краток в этот раз. В любом случае, норма подкрепляется. Но, отказываясь от нормы, в то же время не объясняя, почему вы отказываетесь от неё, это как сказать, что предмет обсуждения (и те, кто в этом участвует) недостойны вашего времени. Лучше продемонстрировать ценность вашего времени, будучи кратким, чем ленивым.

Конечно, существует много других форм грубости, но большинство из них не являются специфичными для разработки свободного ПО, и здравого смысла достаточно, чтобы их избежать. Смотрите также «Пресекайте грубость на корню» в Глава 2, Начало работы, если вы ещё этого не сделали.

Лицо

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

Поэтому с психологической точки зрения интернет-сотрудничество необычно, поскольку оно подразумевает тесную кооперацию между людьми, которые почти никогда не идентифицируют друг друга наиболее естественными, интуитивными методами: прежде всего по лицам, по голосу, позе и т.д.Для компенсации этого эффекта старайтесь использовать один псевдоним повсюду. Он должен быть начальной частью вашего email-адреса (часть перед знаком @), вашим именем в IRC, именем пользователя в репозитории и баг-трекере и т.д. Это имя - ваше "сетевое лицо": короткая идентификационная строка, которая выполняет часть функций вашего реального лица, хотя, к сожалению, и не возбуждает то же самое "устройство" в мозгу.

Псевдоним должен быть некоторой интуитивно понятной производной от вашего реального имени (мой, например, "kfogel"). В некоторых ситуациях он будет сопровождаться вашим полным именем, например, в заголовках почтовых сообщений:

From: "Karl Fogel" <kfogel@whateverdomain.com>

На самом деле, этот пример иллюстрирует две вещи. Как сказано выше, псевдоним интуитивно соответствует реальному имени, но и настоящее имя действительно реально. То есть, оно не является некоторым вымышленным именем, типа:

From: "Замечательный хакер" <wonderhacker@whateverdomain.com>

Известна знаменитая карикатура Поля Штейнера, появившаяся 5 июля 1993 вThe New Yorker, которая изображает собаку, зарегистрировавшуюся на компьютерном терминале, заговорщицки смотрящую и говорящую другой собаке: "В Интернете никто не знает, что ты собака." Такого рода рассуждения возможно и являются причиной существования большого числа самовозвышающих, задуманных-быть-крутыми сетевых идентификаторов, которые люди себе присваивают - как будто, если кто-то назовает себя "Изумительным Хакером, то люди сразу подумают, что так оно и есть. Однако, факт остаётся фактом: даже если никто не знает, что вы - собака, вы всё равно ей остаётесь. Фантастический сетевой идентификатор никогда не производит впечатления на читателей. Напротив, он заставляет их думать, что вы скорее воображаемое, чем реальное существо, или что вы просто ненадёжны. Используйте своё реальное имя для всех взаимодействий или, если по какой-то причине вы должны соблюдать анонимность, выдумайте имя, которое звучит как хорошее обычное реальное имя, и используйте его постоянно.

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

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

ВАЖНОЕ ЗАМЕЧАНИЕ

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

Данное сообщение послано из Deloitte & Touche LLP. Deloitte & Touche LLP
является товариществом с ограниченной ответственностью, зарегистрированным в
Англии и Уэльсе под регистрационным номером OC303675. Список членов для
ознакомления можно получить в Stonecutter Court, 1 Stonecutter Street, London
EC4A 4TR, United Kingdom, по месту регистрации и основной деятельности фирмы.
Deloitte & Touche LLP санкционировано и регулируется Financial Services
Authority.

Данное сообщение и любые приложения содержат информацию, которая является
конфиденциальной и также может быть привилегированной. Оно - для исключительного
использования получателем(ями), для которых предназначено. Если вы не являетесь
подразумеваемым получателем(ями), пожалуйста, обратите внимание, что любая форма
раскрытия, распространения, копирования или использования данного сообщения или
содержащейся в нём или в любых приложениях информации строго запрещена и может быть
незаконной. Если вы получили данное сообщение по ошибке, пожалуйста, верните его
с заголовком "получено по ошибке" по адресу IT.SECURITY.UK@deloitte.co.uk, а
затем удалите из почты и уничтожьте любые его копии.

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

Любые заключения или советы, содержащиеся в этом электронном сообщении или любых
приложениях, адресованные нашим клиентам, являются предметом условий и
обстоятельств, предусмотренных в основном письме обязательства Deloitte & Touche
LLP перед клиентом.

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

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

Если вы работаете в организации, которая настаивает на присоединении таких блоков подписи ко всем исходящим почтовым сообщениям, подумайте над получением бесплатной учётной записи, например, на gmail.google.com, www.hotmail.com, или www.yahoo.com, и используйте её в качестве своего адреса в проекте.



[22] Существует несколько интересных академических исследований по этому вопросу; например, смотритеGroup Awareness in Distributed Software Development авторы Gutwin, Penner, and Schneider. Эта работа была какое-то время доступна в сети, затем нет, потом опять доступна по адресу http://www.st.cs.uni-sb.de/edu/empirical-se/2006/PDFs/gutwin04.pdf. Так что, попробуйте эту ссылку, но будьте готовы использовать поисковые механизмы, если она снова изменилась.