Общение Способность писать так, чтобы быть понятым,—является, возможно, самым важным умением в мире свободного ПО. В долгосрочной перспективе она значит гораздо больше, чем талант программиста. Отличный программист с плохими коммуникативными навыками может реализовывать только одну часть проекта одновременно. А плохой программист с хорошими коммуникативными навыками может координировать и убеждать многих людей делать множество разных вещей, и, таким образом, иметь значительное влияние на направление и скорость реализации проекта. Между способностью писать хороший код и способностью общаться с другими нет ощутимой корреляции, ни положительной, ни отрицательной. Существует небольшая корреляция между хорошим программированием и хорошим описанием технических вопросов, но описание технических вопросов это только малая толика всех коммуникаций в проекте. Гораздо более важна способность подстраиваться к аудитории, видеть чьи-то сообщения, понимать, как их видят другие, и побуждать других смотреть на свои сообщения так же объективно. Равно важно замечать, когда используемые средства или способы общения перестают работать как механизм эффективного взаимодействия, в силу того что они не справляются с возросшим числом участников, и уделять время для исправления этой ситуации. Всё это очевидно в теории, на трудноосуществимо на практике, в силу того, что среда разработки свободного ПО неоднородна ни по аудитории, ни по используемым механизмам коммуникации. Что стоит сделать с возникшей мыслью — разослать как сообщение в список рассылки, написать примечание к ошибке, или комментарий в исходном коде? Отвечая на вопрос в открытом форуме, какой уровень знаний вы можете предполагать у читателей, полагая, что "читатель" — это не только тот, кто первый задал вопрос, но все, кто может видеть ваш ответ? Что нужно сделать разработчикам, чтобы одновременно оставаться в созидательном контакте с пользователями, и не быть заваленными заявками на разработку дополнительного функционала, отчётами о ложных ошибках, и болтовнёй ни о чём? Как понять, что механизм взаимодействия исчерпал себя и что с этим делать? Эти проблемы обычно не удается решить полностью, потому что любое конкретное решение со временем устаревает из-за роста или изменения структуры проекта. Они также часто бывают уникальными, поскольку представляют собой импровизированные ответы на динамические ситуации. Все участники должны следить за тем, когда и как коммуникации могут увязнуть в болоте, и должны участвовать в решении проблемы. Помощь людям в достижении этой цели - одна из огромных управленческих задач при ведении проекта открытого ПО. В следующих разделах обсуждается и как построить своё собственное общение, и как сделать управление механизмами взаимодействия приоритетом для каждого участника проекта.Существует несколько интересных академических исследований по этому вопросу; например, смотритеGroup Awareness in Distributed Software Development авторы Gutwin, Penner, and Schneider. Эта работа была какое-то время доступна в сети, затем нет, потом опять доступна по адресу . Так что, попробуйте эту ссылку, но будьте готовы использовать поисковые механизмы, если она снова изменилась. Вы то, что вы пишете Подумайте над следующим: единственным источником информации о вас в интернете является то, что вы написали, или то, что кто-то написал о вас. Вы можете быть яркой, восприимчивой и харизматической личностью, но если ваши письма бессвязны и не структурированы, люди будут считать вас таким. Или, предположим, вы в жизни несобранный, беспорядочный человек, но никто об этом даже не задумается, если ваши сообщения понятны и информативны. Внимательное отношение к стилю вашего письма вернётся сторицей. Старый хакер свободного ПО Джим Блэнди (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? Шейн Вот это краткость! Ни приветствия, ни подписи, кроме имени, и само сообщение - это просто серия вопросов, выраженных настолько сжато, насколько возможно. Единственное повествовательное предложение представляло собой неявную критику моего первого сообщения. И всё-таки, я был счастлив увидеть почту Шейна, и не воспринял его краткость как что-то большее, чем признак занятости. Тот факт, что он задавал вопросы, а не проигнорировал моё сообщение, означал, что он был готов потратить время на мою проблему. Будут ли все читатели позитивно реагировать на такой стиль? Не обязательно; это зависит от человека и от контекста. Например, если кто-то, скажем некая девушка, просто послала уведомление о том, что сделала ошибку в коде (которая приводит к багу), а вы знаете из предыдущего опыта, что она - человек эмоциональный, то, хотя вы по прежнему можете написать краткий ответ, вы должны позаботиться о её чувствах. Основная часть ответа, анализ ситуации глазами инженера, может быть короткой, как пожелаете. Но в конце напишите что-то, показывающее, что ваша краткость не означает холодности. Например, если вы просто даёте массу советов, как человек должен исправить ошибку, то подпишитесь "Удачи, <добавьте его имя>, чтобы показать, что вы желаете ему хорошего и не сердитесь. Удачно размещенный смайл или другие эмотиконы также часто помогают умиротворить собеседника. Необходимость уделять такое внимание чувствам собеседников и форме диалога может показаться необычной, но, без обиняков, эмоции влияют на производительность. Они важны и по другим причинам, но даже ограничиваясь чисто утилитарными мотивами, мы можем отметить, что несчастные люди пишут самое плохое ПО, и пишут меньше всего. Учитывая ограниченность присущую большинству электронных средств общения, признаки истинных эмоций будут проявлять себя не часто. Вам придётся делать догадки по опыту, основываясь на том, а) как большинство людей должны чувствовать себя в такой ситуации, и б) что вы знаете о данном конкретном человеке из предыдущего общения. Некоторые люди предпочитают более отстранённое отношение, и просто рассматривают каждого как есть, полагая что если участник не говорит прямо, что он чувствует в данном случае, то никто не должен делать предположений о его чувствах. Я не разделяю этот подход по многим причинам. Первая, люди не ведут себя подобным образом в реальной жизни,так почему они должны делать это в сети? Вторая, поскольку большинство взаимодействий происходит в открытых форумах, люди стараются сдерживать эмоции больше чем в обычной жизни. Уточню, они часто стараются выразить направленные на других эмоции, такие как благодарность или оскорбление, но не направленные внутрь эмоции, такие как неуверенность или гордость. Кроме того, большинство людей работают лучше, когда они знают, что другие осведомлены об их состоянии. Уделяя внимание мелочам, вы сможете угадывать состояние правильно в большинстве случаев и мотивировать людей к большей вовлечённости. Я, конечно, не имею в виду, что вы должны выполнять роль группового терапевта, постоянно помогая каждому справиться со своими чувствами. Но, уделяя внимание повторяющимся шаблонам поведения людей, вы начнёте понимать их личности, даже если никогда не встречаетесь с ними лицом к лицу. А будучи чувствительным к тону собственных сообщений, вы сможете получить неожиданно большое влияние на самочувствие других, способствующее максимальной выгоде проекта. Как отличить грубость? Одной из отличительных характеристик культуры производства открытого ПО является её особое представление о том, что есть грубость, а что нет. Хотя соглашения, описанные ниже, не уникальны для разработки свободного ПО, и даже для ПО вообще - они хорошо знакомы каждому, кто работает в математике, точных науках или в инженерных областях. Разработка свободного ПО, с её пористыми границами и постоянным притоком новых людей, —именно та среда, в которой эти соглашения с большей вероятностью попадутся тем, кто не знаком с ними. Давайте начнём с вещей, которые не являются грубостью: Техническая критика, даже прямая и неприкрытая, не является грубостью. Напротив, она может быть формой лести: критика говорит, в подтексте, что критикуемый заслуживает серьёзного отношения и некоторого, потраченного на него времени. То есть, чем больше времени и сил занимает ответ на сообщение, тем более похвально становится потратить время для его критики (конечно, если только критика не переходит на личность или не перерастает в другую очевидную грубость). Прямые, без прикрас вопросы, такие, как вопросы Шейна ко мне в процитированном выше сообщении, также не являются грубостью. Вопросы, которые в другом контексте могут казаться холодными, риторическими, и даже насмешкой, часто задаются серьёзно и не имеют скрытых намерений, кроме получения информации как можно быстрее. Классический пример - вопрос службы технической поддержки "Ваш компьютер включен в розетку?" Сотрудник службы поддержки действительно должен знать, включен ли компьютер в розетку, и, после первых нескольких дней работы, устаёт предварять свой вопрос вежливыми уговорами ("Я очень извиняюсь, но только хочу задать вам несколько простых вопросов, чтобы исключить некоторые возможные ситуации. Некоторые из них могут показаться весьма несущественными, но давайте их пройдём..."). Теперь он больше не беспокоится об этих "подстилках" и просто спрашивает прямо: включен ли компьютер или нет? В почтовых списках рассылки свободного ПО постоянно задаются одинаковые вопросы. Целью является не оскорбление адресата, а быстрое исключение наиболее очевидных (и, возможно, наиболее общих) объяснений. Адресаты, которые понимают это и реагируют соответственно, набирают очки, получая широкий отклик без дополнительных запросов. Но те, кто реагирует неправильно, также не должны страдать. Это просто коллизия культур, а не чей-то проступок. Дружелюбно объясните, что ваш вопрос (или критика) не имеет скрытых смыслов; он просто предназначен для получения (или передачи) информации наиболее эффективным способом, ничего больше. Тогда что есть грубость? Согласно тому же принципу, по которому детальная техническая критика есть форма лести, отказ предоставить качественную критику может быть видом оскорбления. Я не имею в виду простое игнорирование чьей-то работы, будь это положим, изменения в коде, регистрация новой проблемы, или ещё что-то. Если только вы заранее не обещали подробного анализа, обычное поведение - никак не реагировать. Люди будут полагать, что у вас просто нет времени, чтобы хоть что-то сказать. Но если вы реагируете, не скупитесь: найдите время для реального анализа проблемы, приведите конкретные примеры там, где это уместно, покопайтесь в архивах, чтобы найти связанные сообщения в прошлом и т.д. Либо, если у вас нет времени на такие усилия, но всё же надо написать что-то короткое в ответ, обозначьте это открыто в своём сообщении ("Я думаю, что для этого случая уже зарегистрирована проблема, но, к сожалению, не имею времени, чтобы её найти. Извините."). Главное - осознать наличие культурной нормы, либо следуя ей, либо открыто извещая, что кто-то краток в этот раз. В любом случае, норма подкрепляется. Но, отказываясь от нормы, в то же время не объясняя, почему вы отказываетесь от неё, это как сказать, что предмет обсуждения (и те, кто в этом участвует) недостойны вашего времени. Лучше продемонстрировать ценность вашего времени, будучи кратким, чем ленивым. Конечно, существует много других форм грубости, но большинство из них не являются специфичными для разработки свободного ПО, и здравого смысла достаточно, чтобы их избежать. Смотрите также в , если вы ещё этого не сделали. Лицо В человеческом мозге есть область, отвечающая только за распознавание лиц. Обычно ее так и называют - "область распознавания лиц", и её способность по большей части врождённая, а не приобретённая. Похоже, что распознавание людей настолько критично для выживания, что у нас в ходе эволюции появилось специализированное "устройство" для этого. Поэтому с психологической точки зрения интернет-сотрудничество необычно, поскольку оно подразумевает тесную кооперацию между людьми, которые почти никогда не идентифицируют друг друга наиболее естественными, интуитивными методами: прежде всего по лицам, по голосу, позе и т.д.Для компенсации этого эффекта старайтесь использовать один псевдоним повсюду. Он должен быть начальной частью вашего 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, и используйте её в качестве своего адреса в проекте. Как избежать распространенных ошибок? Не посылайте сообщения без цели Одна из самых распространенных ошибок при участии в сетевом проекте - полагать, что вы обязаны реагировать на всё. Не должны. Прежде всего, обычно будет возникать больше тем, чем вы можете отслеживать, по крайней мере после того, как проекту исполнится несколько месяцев. Во-вторых, даже в темах, которыми вы решили заниматься, многое из того, что говорят люди, не будет требовать ответа. В форумах разработчиков в частности есть тенденция к преобладанию трёх видов сообщений: Сообщения, предлагающие нечто нетривиальное. Сообщения, выражающие поддержку или несогласие с чем-то, что сказал кто-то ещё. Обобщающие сообщения. Ничто из этого по природе своей не требует ответа, особенно если вы достаточно уверены, основываясь на предыдущем наблюдении за темой, что в любом случае кто-нибудь ещё готов сказать то же, что и вы. (Если вы обеспокоены тем, что попадёте в цикл ожидание-ожидание по причине того, что все остальные используют ту же тактику, не переживайте; почти всегда есть кто-нибудь , кто готов ввязаться в драку.) Ответ должен быть продиктован совершенно определённой целью. Сначала спросите себя: знаете ли вы, чего хотите добиться? А затем: можно ли этого достичь не продолжив разговор? Два хороших повода добавить свой голос в тему это а) когда вы видите недостаток в предложении и полагаете, что вы единственный, кто видит это, и б) когда вы видите, что между другими возникает недопонимание, и знаете, что можете восстановить его разъясняющим сообщением. Также, нет ничего плохого в том, чтобы послать сообщение, просто поблагодарив кого-то за что-то, или сказать "Я тоже", поскольку получатель может чётко определить, что такое сообщение не требует ответа или дальнейших действий и, следовательно, не будет размышлять о нем больше чем надо. Но даже в этих случаях подумайте дважды, прежде чем что-то сказать; всегда лучше, чтобы у людей оставалось желание, чтобы вы писали больше, чем желание, чтобы вы писали меньше. (Смотрите вторую часть . Там есть несколько мыслей, о том как вести себя в оживлённом списке рассылки. Продуктивные и непродуктивные темы В оживлённом списке рассылки вы должны придерживаться двух постулатов. Первый, очевидный, определить, чему вы должны уделять внимание, а что можете игнорировать. Второй - вести себя так, чтобы шуметь как можно меньше. Ваши сообщения не только должны иметь высокое отношение сигнал/шум, но и стимулировать других людей писать с таким же высоким отношением сигнал/шум, либо не писать вовсе. Чтобы понять, как это делается, давайте рассмотрим контекст, в котором это происходит. Каковы отличительные признаки непродуктивной темы? Аргументы, уже звучавшие ранее, начинают повторяться, как будто пишущий думает, что никто не услышал их в первый раз. Люди начинают говорить чаще и используя все большие преувеличения, обсуждая все меньшую и меньшую пользу для проекта. Большинство комментариев приходят от людей, которые делают мало или ничего,в то время как люди, старающиеся доводить дела до конца, молчат. Обсуждается много идей, при этом не предлагается и не обсуждается их реализация. (Конечно, любая идея начинается со смутного видения, главный вопрос заключается в том - во что она дальше превратиться. Разовьется ли это видение во что-то конкретное, или так и будет порождать другие идеи, похожие идеи и онтологические споры.) Если тема поначалу непродуктивна, это не значит, что участие в ней будет потерей времени. В ней может обсуждаться важный вопрос, и в этом случае большее беспокойство вызывает то, что тема не движется в нужном направлении. Направить ветку в полезную сторону, не проявляя назойливости, это искусство. Обычные увещевания прекратить тратить время и просьбы не писать, если нечего сказать по существу - не работают. Вы можете,конечно, подумать так про себя, но если вы скажете людям это открыто, то оскорбите их. Вместо этого вы должны создать основу для движения вперёд - дать людям выход, путь, ведущий к результату, которого вы хотите, но так чтобы это не звучало, как будто вы говорите им что делать. Разница по большей части в тоне. Например, вот это плохо:
Эта дискуссия никуда не ведёт. Не могли бы мы закрыть этот вопрос, пока у кого-нибудь не появится патч, реализующий одно из этих предложений? Нет оснований ходить по кругу, повторяя одно и то же. Народ, код громче слов.
А вот это хорошо:
В этой теме всплыло несколько идей, но ни одна не обросла достаточным количеством деталей, по крайней мере, не достаточным для принятия решения о дальнейшей судьбе решения. Мы также не говорим сейчас ничего нового; мы просто повторяем то, что уже было сказано ранее. Так что, вероятно, наилучшим в такой ситуации будет, если следующие сообщения либо будут содержать полную спецификацию предложенного поведения программы, либо патч. Тогда, по крайней мере, мы сможем предпринять конкретные действия (например, достигнуть соглашения по спецификации, или применить и протестировать патч).
Почувствуйте разницу между первым и вторым подходом. Во втором случае не проводится линия между вами и остальными, и они не обвиняются в том, что они ходят кругами. Говорится "мы", и это важно независимо от того, принимали вы участие в теме до этого или нет, поскольку это напоминает каждому, что даже те, кто до сих пор молчал, вносят вклад в результат темы. Здесь описывается, почему тема идёт в никуда, но это делается без уничижения и осуждения - просто беспристрастно констатируются некоторые факты. Наиболее важно то, что предложено позитивное направление действий, так что люди чувствуют себя не так, будто дискуссию закрывают (ограничение, которое может только подтолкнуть к сопротивлению), а так, будто им предлагают способ перевести разговор на более конструктивный уровень. Это - то поведение, которого и ждут люди. Перевод темы в более конструктивное русло не всегда будет вашей задачей. Иногда вам будет хотеться, чтобы тема заглохла. Тогда подобное сообщение приведет либо к одному, либо к другому. Если из обсуждения понятно, что никто не будет воплощать ваши предложения в жизнь, то сообщение поставит точку в теме, так, что никто и не догадается. Конечно же, не существует безотказного способа закрыть тему, и даже если бы он существовал, вы бы не захотели его использовать. Но просьба к участникам перейти к ощутимым действиям или перестать писать оправдана, если делается дипломатично. Однако, остерегайтесь постоянного "глушения" тем. Умозрительная болтовня в умеренных количествах может оказаться продуктивной в зависимости от вопроса, и требование решить его слишком быстро будет душить креативный процесс, и вы будете выглядеть нетерпеливым. Не ждите, что запросто остановите любую тему. Возможно, будет ещё несколько сообщений после вашего, потому что почтовые сообщения наложились во времени, или потому что люди хотят, чтобы последнее слово было за ними. Об этом не надо беспокоиться, и вы не должны писать ещё раз. Просто позвольте теме иссякнуть, или нет, как получится. Вам не дано получить полный контроль; с другой стороны, вы можете рассчитывать на статистически значимый эффект по множеству тем. Чем шире вопрос, тем длиннее споры Хотя дискуссия может развернуться по любому вопросу, вероятность её появления возрастает при снижении технической сложности. И наоборот, чем больше техническая сложность, тем меньше участников могут понять о чем идет речь. Те же, кто способен, вероятно наиболее опытные разработчики, которые уже принимали участие в таких дискуссиях тысячу раз и знают, какое поведение способно привести к консенсусу, устраивающему всех. Таким образом, консенсус труднее всего достижим в простых для понимания технических вопросах, по которым любой может принять собственное мнение, а также в расплывчатых вопросах организации, рекламы, финансирования и т.п. Люди могут участвовать в подобных дискуссиях бесконечно, потому что для вхождения в дискуссию не нужно обладать специальной подготовкой, потому что не существует однозначных способов для определения (даже задним числом) было ли решение правильным или нет, и потому что выжидательная тактика иногда приносит плоды. Принцип обратной пропорциональности объёма дискуссии сложности вопроса открыт давно и известен неформально как Эффект навеса. Вот его описание, данное Полом-Хеннингом Кэмпом, из уже ставшего знаменитым сообщения для разработчиков BSD:
Это длинная история, или, скорее, старая история, но на самом деле достаточно короткая. В середине 1960-х Сирил Норткот Паркинсон написал книгу под названием "Законы Паркинсона", которая рассматривает многие движущие силы управления. [...] В конкретном примере с навесом для велосипедов второй существенный компонент - атомная электростанция, я полагаю, это подчёркивает возраст книги. Паркинсон показывает, как вы могли бы прийти на совет директоров и получить одобрение многомиллионного или даже миллиардного проекта строительства атомной станции, но если вы хотите построить навес для стоянки велосипедов, вас запутают в бесконечных дискуссиях. Паркинсон объясняет это тем, что атомная станция настолько громадна, так дорога и сложна, что люди не могут этого охватить, и вместо того, чтобы попытаться, они полагаются на то, что кто-то другой уже проверил все детали. Ричард Фейнман в своих книгах даёт массу интересных, и очень подходящих, примеров, связанных с Лос-Аламосом. С другой стороны, навес для велосипедов. Каждый может построить какой-нибудь навес за выходные и при этом ещё останется время посмотреть матч по телевизору. Так что не имеет значения, ни насколько вы подготовлены, ни насколько убедительны будут ваши предложения, кто-нибудь воспользуется шансом продемонстрировать, что он выполняет свою работу, что он уделяет внимание, что он здесь. В Дании мы называем это "оставить свой след". Так говорят о человеческой гордости и авторитете, о том, что можно показать на что-то и сказать "Вот! Это сделал я." Это особенно характерно для политиков, но проявляется при случае у большинства людей. Просто вспомните следы в незастывшем цементе.
(Его полное сообщение также очень полезно почитать. Смотрите ; и .) Каждый, кто регулярно участвовал в групповом принятии решений, поймёт, о чём говорит Кэмп. Однако, обычно невозможно отговорить всех от покраски навесов. Лучшее, что вы можете сделать, — рассказать о том, что такая ситуация случилась и убедить главных разработчиков (людей чьи сообщения наиболее важны) быстрее отложить "кисти", чтобы они не способствовали нарастанию шума. Компании маляров заборов никогда не исчезнут полностью, но вы можете сделать так, чтобы их было меньше и появлялись они реже, распространяя знания об этом феномене в культуре проекта. Как избежать религиозных войн? Религиозная война—это диспут, возникший вокруг как правило малозначимой проблемы, который не разрешим на основе аргументов, но при этом люди настолько вовлечены, что продолжают спорить в надежде, что их сторона одержит победу. Религиозные войны не похожи на покраску навесов. Люди, красящие навесы, обычно быстро принимают решение (потому что это так просто), но они не всегда строго придерживаются этого решения, наоборот, иногда будут выражать противоположные, несовместимые с изначальным мнения, чтобы показать, что они понимают все стороны проблемы. В религиозных войнах, напротив, понимание другой стороны является признаком слабости. В религиозных войнах каждый знает, что существует Единственно Правильный Ответ; они не соглашаются о том, каков он. Если религиозная война началась, то ее, как правило, невозможно закончить так, чтобы все были довольны. Бесполезно указывать участникам на то, что война началась, когда она уже разгорелась.Каждый это уже знает. К сожалению, общей особенностью религиозных войн является несогласие по основному вопросу о том, разрешима ли полемика путём продолжения дискуссии. Если смотреть со стороны, то заметно что ни одна из сторон не может убедить другую изменить мнение. Если смотреть глазами участника, противоположная сторона кажется тупой и не мыслящей ясно, но она может исправиться если её достаточно застращать. Да, я не говорю, что в религиозной войне никогда нет правой стороны. Иногда есть - в религиозных войнах, в которых я принимал участие, это, конечно, всегда была моя сторона. Но это не имеет значения, потому что не существует алгоритма для убедительной демонстрации правоты одной из сторон. Обычный, но неудовлетворительный, способ, которым люди пытаются прекратить религиозную войну - сказать "Мы уже потратили намного больше времени и энергии, обсуждая это, чем следовало! Не могли бы мы просто прекратить это?" Здесь есть две проблемы. Первая в том, что время и энергия уже потрачены и их не вернуть - теперь единственный вопрос, сколько будет истрачено ещё? Если некоторые люди видят, что ещё немного споров и проблема решится, то всё ещё имеет смысл (с их точки зрения) продолжать. Вторая проблема с просьбой закрыть вопрос состоит в том, что часто это эквивалентно тому, что одной из сторон, дозволяется объявить победу по неучастию, закрепив статус-кво. А в некоторых случаях статус-кво, как известно, всё равно неприемлем: каждый согласен, что какое-то решение надо принять, какие-то действия сделать. Закрытие вопроса будет наихудшим вариантом для всех, тогда как просто прекращение аргументации будет худшим только для кого-то. Но, поскольку эта дилемма равно применима ко всем, возможно вообще прекращение дискуссии о том, что делать. Но тогда как же ыы должны управлять религиозными войнами? Первый совет такой - постарайтесь устраивать всё так, чтобы они не возникали. Это не так безнадёжно, как кажется: Вы можете предвидеть некоторые стандартные религиозные войны: они имеют тенденцию возникать вокруг языков программирования, лицензирования (смотрите in ), reply-to munging (see в )и некоторых других вопросов. В каждом проекте обычно есть одна-две собственные религиозные войны, с которыми постоянные разработчики очень быстро осваиваются. Техники для остановки религиозных войн или, по крайней мере, снижения ущерба от них везде одни и те же. Даже если вы уверены, что правда на вашей стороне, попытайтесь найти какой-то способ выразить сочувствие и понимание утверждений противоположной стороны. Часто проблема в религиозной войне состоит в том, что каждая сторона строит свои стенки такими высокими, как только может, и даёт ясно понять, что любое другое мнение это явная глупость, поэтому акт уступки или изменения чьих-либо представлений становится психологически непереносимым: это было бы не просто признанием своей неправоты, но того, что ты выражал уверенность, будучи неправ. Вы можете сделать такое признание приемлемым для противоположной стороны, выказав некоторую собственную неуверенность - особенно показывая, что вы понимаете приведённые ими аргументы и находите их по крайней мере разумными, если и не до конца убедительными. Сделайте жест, который оставляет место для ответного жеста, и обычно ситуация улучшится. Это ни больше и не меньше продвигает к техническому результату, которого вы ожидаете, но, по меньшей мере, вы можете избежать ненужных второстепенных опасностей для боевого духа проекта. Если религиозной войны не избежать, решите сразу, сильно ли вас это затрагивает и затем будьте готовы к публичному выходу из войны. Когда вы поступаете таким образом, вы можете сказать, что отступаете, потому что религиозная война это не умно, но не выражайте сожаления и не используйте это как возможность для нанесения последнего удара по аргументам противника. Выход из войны эффективен, только когда делается изящно. Религиозные войны вокруг языков программирования несколько специфичный случай, поскольку они часто высоко техничны, достаточно много людей чувствуют себя подготовленными для участия в них, и ставки очень высоки, поскольку результат может определить, на каком языке будет написана приличная часть кода проекта. Наилучшим решением является выбрать язык пораньше, заручившись поддержкой влиятельных первоначальных разработчиков, и затем защищать его с тех позиций, что вам всем на нём удобно писать, а не с позиций того, что он лучше какого-то другого языка, который мог бы использоваться. Никогда не позволяйте разговору скатываться на академическое сравнение языков программирования (кажется, это наиболее часто происходит, когда кто-нибудь вытаскивает Perl, по какой то причине); это мёртвые вопросы, от вовлечения в которые ыы просто должны отказаться. Более подробную историю религиозных войн смотрите на , а работа Дэнни Коэна (Danny Cohen) ввела термин в упортребление, . Эффект "шумящего меньшинства" В любой дискуссии в списке рассылки небольшая группа людей может с легкостью создать впечатление того, что существует большой раскол, наводнив список многочисленными длинными сообщениями. Это похоже на обструкционизм, но иллюзия большого раскола еще более сильна, потому что сообщения раскиданы по произвольному числу отдельных сообщений, а большинство людей не хотят нагружать себя тем, чтобы следить, кто, что и когда сказал. Они инстинктивно решат, что вопрос очень спорный и будут ждать, чтобы суета улеглась. Лучший способ противодействовать этому эффекту - указать на него совершенно открыто и привести доказательства, показывающие как мало на самом деле число несогласных по сравнению с людьми пришедшими к согласию. Чтобы усилить меры, вы можете приватно опросить людей, по большей части молчавших во время обсуждения, но по вашему разумению, согласных с большинством. Не намекайте им на то, что люди раздувающие несогласие, делают это умышленно. Всегда есть вероятность, что это не так, а даже если это так, то разговоры об этом не дают никакого стратегического преимущества. Всё, что вам надо сделать - показать реальное количество в сравнении, и люди поймут, что их интуитивное представление о ситуации не соответствует действительности. Этот совет применим не только к проблемам с четко обозначенными позициями за и против. Он применим к любой дискуссии, в которой происходит некое обсуждение, но не понятно, считает ли большинство людей обсуждаемый вопрос реальной проблемой. Немного погодя, если вы придете к понимаю, что вопрос не стоит того, чтобы его решать, и при этом видите, что вопрос не двигается с места (даже если породил множество сообщений), вы говорит о об этом. Если имел место эффект "шумящего меньшинства", то ваше сообщение будет подобно дуновению свежего ветра. Впечатление большинства людей о дискуссии по данному вопросу к этому времени должно было стать несколько мрачным: "Хе, сразу чувствуется, что здесь что-то важное, так много почты, но я не вижу, чтобы был видимый прогресс." Объяснив, что форма ведения дискуссии привела к тому, что обсуждение оказалось более бурным, чем оно того заслуживало, вы заставляете людей по новому оценить произошедшее. Тяжёлые люди С тяжёлыми людьми одинаково сложно иметь дело как в электронных форумах так и лично. Под "тяжёлыми" я не имею в виду "грубых". Грубые люди раздражают, но с ними не обязательно тяжело общаться. В этой книге уже обсуждалось, как управляться с ними: прокомментируйте грубость в первый раз, а далее либо игнорируйте их, либо обращайтесь как со всеми остальными. Если они продолжают грубить, то обычно становятся так непопулярны, что не имеют влияния на остальных участников проекта, так что проблема грубости сама себя изживает. Действительно трудные люди - люди, которые не грубят открыто, но манипулируют или злоупотребляют ходом проекта так, что в конечном итоге это стоит времени и сил других людей и не приносит никакой пользы проекту. Такие люди обычно выискивают в процедурах проекта слабые места, и пользуются ими для получения большего влияния, чем они могли бы получить обычным образом. Это намного более коварно, чем простая грубость, потому что ни поведение, ни приносимый вред не очевидны для рядовых наблюдателей. Классический пример - обструкционизм, когда кто-то (всегда говорящий, конечно, так рассудительно, как только можно) продолжает утверждать, что предмет обсуждения не готов для вынесения решения, и предлагает возможные решения или новые трактовки старых решений, тогда как на самом деле он чувствует, что консенсус скоро будет достигнут или пройдет голосование, а ему не нравится в какую сторону будет развиваться проект после этого. Другой пример, когда люди не соглашаются по вопросу, но группа пытается по крайней мере найти точки разногласия и прописать их в документе, на который каждый отныне мог бы ссылаться. Обструкционист, зная что такой документ может привести к результату, которого он не хочет, часто будет пытаться затягивать его производство, безжалостно запутывая вопрос о том, что в нём должно быть, либо протестуя против разумных предложений, либо вводя неожиданные новые пункты. Как управляться с тяжёлыми людьми Чтобы нейтрализовать такое поведение полезно понимать мышление таких людей. Люди как правило не поступают так сознательно. Никто не встаёт утром и не говорит себе: "Сегодня я собираюсь цинично манипулировать формальными процедурами и буду раздражающим обструкционистом." Напротив, таким действиям часто предшествует полу-параноидальное ощущение того, что человека не допускают до взаимодействия с группой и принятия решений. Человек ощущает, как будто его не воспринимают всерьёз или (в более тяжёлых случаях) что против него существует чуть ли не заговор - что остальные участники проекта решили сформировать закрытый клуб, в котором он не состоит. Такая позиция оправдывает, в его глазах, буквальную трактовку правил и манипулирование процедурами проекта, как средство заставить других принимать его серьезно. В крайних случаях человек даже может полагать, что он в одиночку выходит на бой, чтобы защитить проект. Природа такого поведения такова, что не каждый сразу его заметит, а некоторые люди не видят его вообще, пока пока им не предоставят весомых доказательств. Это означает, что нейтрализация может потребовать немало работы. Не достаточно убедиться самому, что это происходит; вы должны собрать достаточно данных, чтобы ещё и убедить других, а затем должны распространить эти данные разумным путём. Так как требуется так много работы, зачастую лучше потерпеть некоторое время. Посмотрите на это как на заражение невредным паразитом. Если оно не истощает проект сверх меры, проект может остаться инфицированным, а лечение может привести к болезненным побочным эффектам. Однако, если оно приносит слишком много неудобств, то настаёт время действовать. Начните собирать заметки о случаях, которые замечаете. Позаботьтесь включить ссылки на общедоступные архивы - это одна из причин, ради которой хранятся протоколы проекта, поэтому используйте их. Как только вы соберете достаточно примеров, начните приватные переговоры с другими участниками проекта. Не говорите им, что вы обнаружили; вместо этого спросите, что увидели они. Это может быть вашим последним шансом получить нефильтрованную оценку того, как другие смотрят на поведение нарушителя спокойствия; как только вы начнёте говорить об этом открыто, мнения поляризуются, и никто не сможет вспомнить, что он думал об этом раньше. Если приватное обсуждение показывает, что по крайней мере ещё кто-то видит проблему, то наступило время что-то делать. И вот здесь вы должны быть действительно осторожны, потому что такие люди легко могут попытаться представить дело так, будто вы придираетесь к ним несправедливо. Что бы вы ни делали, никогда не обвиняйте их в злоупотреблении процедурами проекта, или в параноидальности, вообще ни в чём, даже если подозреваете, что это так. Вам следует выглядеть одновременно более рассудительным и более обеспокоенным общим состоянием проекта, чтобы либо изменить поведение человека, либо вынудить его уйти навсегда. В зависимости от других разработчиков и от ваших связей с ними, может оказаться полезным сначала собрать единомышленников приватно. А может и нет; это может породить недобрую обстановку, если люди подумают, что вы начинаете неприличную закулисную кампанию. Помните, что хотя другой человек может быть тем, кто ведёт себя деструктивно, вы становитесь тем, кто кажется деструктивным, когда делаете ни чем не подкрепленное публичное обвинение. Убедитесь, что имеете достаточно примеров, чтобы подтвердить свои слова, и произносите их как можно вежливее, не теряя при этом сути. Вы можете не убедить человека, о котором идёт речь, но это не страшно, если вы убедили всех остальных. Пример: трудные люди Я могу припомнить только одну ситуацию за 10 с лишним лет работы в открытом ПО, когда всё сложилось так плохо, что нам действительно пришлось попросить человека прекратить писать навсегда. Как это часто бывает, он не грубил, и только хотел искренне помочь. Он просто не знал, когда надо писать, а когда нет. Наши списки были открытыми, и он писал настолько часто и задавал вопросы по столь различным вопросам, что это начало становиться проблемой шума для сообщества. Мы уже пытались вежливо просить его более тщательно искать ответы на вопросы перед тем как задавать вопросы, но это не имело эффекта. Стратегия, которая в итоге сработала, - прекрасный пример того, как построить веское дело на независимых, количественных данных. Один из наших разработчиков покопался в архивах и затем послал следующее сообщение приватно нескольким другим. Правонарушитель (третье имя в списке ниже, показанное здесь как "J.Random") имел очень маленькую историю в проекте и не внёс вклад ни в код, ни в документацию. При этом он был третьим наиболее активным писателем в почтовой рассылке: From: "Brian W. Fitzpatrick" <fitz@collab.net> To: [... список получателей опущен в целях соблюдения анонимности ...] Subject: The Subversion Energy Sink Date: Wed, 12 Nov 2003 23:37:47 -0600 За последние 25 дней 6-ю наиболее активными писателями в список svn [dev|users] были: 294 kfogel@collab.net 236 "C. Michael Pilato" <cmpilato@collab.net> 220 "J. Random" <jrandom@problematic-poster.com> 176 Branko Čibej <brane@xbc.nu> 130 Philip Martin <philip@codematters.co.uk> 126 Ben Collins-Sussman <sussman@collab.net> Должен сказать, что пятеро из этих людей содействовали тому, чтобы Subversion 1.0 появилась в ближайшем будущем. Должен также сказать, что один из этих людей постоянно отнимает энергию у остальных пяти, не говоря о списке рассылки в целом, тормозя этим (хотя и непреднамеренно) разработку Subversion. Я не делал анализа по темам, но анализ моего почтового архива Subversion говорит, что каждое письмо этого человека потребовал ответа по крайней мере один раз от по крайней мере 2-х человек из 5-ти. Я думаю, требуется какое-то радикальное вмешательство, даже если мы отпугнём вышеупомянутого человека от участия в проекте. Щепетильность и доброта уже испробованы безрезультатно. dev@subversion - это список рассылки, содействующий разработке системы контроля версий, а не сеанс групповой терапии. -Fitz, пытающийся продраться через почту, которую он нагородил за три дня Поведение J.Random'а было классическим случаем злоупотребления процедурами проекта, хотя это может показаться не столь явным. Он не пытался делать делать чего-то очевидного, типа попыток обструкции голосования, но он получил преимущество от политики списка рассылки, построенной на саморегуляции участниками. Мы оставили на усмотрение каждого, когда писать и по какому вопросу. Таким образом, у нас не было процедурного ресурса для управления теми, кто не следовал, либо не собирался изучить это соглашение. Не было правила, на которое можно было указать и сказать, что парень нарушил его, хотя все знали, что его частые сообщения грозили стать серьёзной проблемой. Стратегия Фитца (Fitz) была, оглядываясь назад, мастерской. Он собрал дискредитирующие количественные данные, но затем распространил их избирательно, послав их сначала нескольким людям, чья поддержка могла стать ключевой в случае решительных действий. Они согласились, что необходимо что-то делать, и в конце концов мы позвонили J.Random'у по телефону, прямо описали ему проблему и попросили его просто перестать писать. Он так и не понял, почему; если бы он был способен понять, он, наверное, для начала изучил бы соответствующее соглашение. Но он согласился не писать, и списками рассылки снова стало можно пользоваться. Одна из причин, по которой эта стратегия сработала, была, возможно, в безусловной угрозе того, что мы можем начать отсекать его почту с помощью регулирующего ПО, которое обычно используют для защиты от спама (смотрите в ). Но мы располагали этой запасной возможностью, потому что Фитц сначала заручился поддержкой ключевых людей. Управление ростом Цена успеха в мире ПО с открытым кодом высока. По мере роста популярности вашего ПО, число людей, которые ищут информацию растет стремительно, тогда как число людей, способных поделиться информацией растёт намного медленнее. Более того, даже если бы они увеличивались сбалансировано, оставалась бы фундаментальная проблема масштабируемости средств коммуникации для большинства проектов открытого ПО. Рассмотрим, например, списки рассылки. В большинстве проектов есть список для общих вопросов пользователей - иногда он называется "users", "discuss", "help", или как-то ещё. Каково бы ни было его имя, цель списка всегда одна и та же: предоставить место, где одни люди могут получить ответы на свои вопросы, а другие ищут и (предполагается) накапливают знания, наблюдая за этим обменом. Такие списки рассылки работают очень хорошо если в них участвуют до нескольких тысяч участников или/и в них рассылается до сотен сообщений в день. Но примерно после этого система начинает давать сбои, потому что каждый подписчик видит каждое сообщение; если число сообщений в списке начинает превышать то, которое отдельный читатель способен переработать за день, список начинает тяготить участников. Представим, например, что Microsoft имеет такой список для Windows XP. Windows XP имеет сотни миллионов пользователей; если даже одна десятая процента из них зададут вопрос в течение заданного 24-часового интервала, то в этом гипотетическом списке будут появляться сотни тысяч сообщений в день! Подобный список, конечно, никогда не смог бы существовать, потому что ни один человек не оставался бы его подписчиком. Эта проблема не ограничивается списками рассылки; та же логика применима к каналам IRC, форумам, и вообще к любым системам, в которых группа выслушивает вопросы индивидуумов. Последствия угрожающи: обычная для открытого ПО модель массовой параллельной поддержки просто не масштабируется на уровни, требующиеся для всемирного распространения. Когда форумы достигнут своих критических точек, взрыва не будет. Просто возникнет неощутимый отрицательный обратный эффект: люди отписываются от списков, или покидают каналы IRC, или на каком-то этапе перестают задавать вопросы, потому что видят, что их могут не услышать в этом шуме. По мере того, как всё больше и больше людей делают этот в высшей степени рациональный выбор, будет казаться, что активность в форуме остаётся на управляемом уровне. Но она остаётся управляемой в точности потому, что рациональные (или, по крайней мере, опытные) люди начали искать информацию где-то в других местах - тогда как неопытные люди остались и продолжают писать. Другими словами, один из побочных эффектов от продолжения использования, по мере роста проекта, немасштабируемой коммуникационной модели заключается в том, что среднее качество как вопросов, так и ответов снижается, и всё выглядит так, как будто новые пользователи глупее, чем прежде, хотя фактически они, вероятно, не такие. На самом же деле отношение пользы к затратам при использовании таких высоко-популярных форумов падает, и естественно, более опытные люди начинают сначала искать ответы в других местах. Поэтому, настройка механизмов коммуникации при росте проекта состоит из двух связанных стратегий: Определение момента, когда определённые части форума перестают справляться с безграничным ростом, даже если форум в целом справляется, и выделение таких частей в новые, более специализированные форумы (то есть, не позволяйте плохому разрушать хорошее). Отслеживание того, что доступно много автоматических источников информации, и что они организованы, актуальны, и в них легко искать. Первой стратегии обычно не сложное следовать. Большинство проектов начинаются с одного главного форума: списка рассылки по всем вопросам, в котором перемешивается всё от функциональных идей и вопросов дизайна до проблем кодирования. Каждый, участвующий в проекте, - в этом списке. Через некоторое время обычно становится ясно, что список эволюционировал в несколько самостоятельных подсписков со своими темами. Например, какие-то темы очевидно касаются разработки и дизайна; другие - вопросов пользователей типа "Как мне сделать X?"; возможно, есть третье семейство вопросов, сконцентрированных вокруг обработки отчётов об ошибках и запросов на доработку; и так далее. Конкретный индивид, конечно, может участвовать в нескольких различных ветках форума, но важно то, что сами ветки не сильно перекрываются. Их можно разделить на отдельные списки рассылки, не вызывая пагубной балканизации, поскольку вопросы редко пересекают границы тем. Деление представляет собой двухшаговый процесс. Вы создаёте новый список (или канал IRC, или что-то, что требуется), и затем проводите столько времени, сколько потребуется, вежливо занудствуя и напоминая людям, чтобы они использовали соответствующие новые форумы. Этот последний шаг может занять несколько недель, но в итоге люди воспримут идею. Вы просто должны напоминать всякий раз, когда отправитель посылает сообщение не туда, и делать это явно, так, чтобы поощрить и других людей к переходу. Полезно также иметь web-страницу с инструкцией по всем имеющимся спискам рассылки; ваши ответы могут просто ссылаться на эту страницу, и, как бонус, получатель может что-то узнать, изучая правила перед отправкой сообщений. Стратегия (2) - непрерывный процесс, продолжающийся всё время жизни проекта и вовлекающий много участников. Конечно, частично этот вопрос перекликается с вопросом наличия актуальной документации (смотрите в ) и направления людей к ней. Но он включает в себя гораздо больше; следующие разделы обсуждают эту стратегию в деталях Широко используйте архивы Как правило, все сообщения в проекте ПО с открытым кодом (иногда за исключением IRC-разговоров) архивируются. Архивы общедоступны, в них можно искать, и они относительно стабильны: то есть, будучи однажды записанной по определённому адресу, порция информации остаётся по этому адресу всегда. Используйте эти архивы так часто, как только можно, и так широко, как только можно. Даже когда ответ на некоторый вопрос лежит для вас на поверхности, если вы думаете, что в архивах есть ссылка с ответом на этот вопрос, потратьте время, чтобы откопать и представить её. Каждый раз, когда вы делаете это публично явным образом, некоторые люди впервые узнают, что существуют архивы, и поиск в них может давать ответы. Кроме того, ссылаясь на архивы вместо повторения совета, вы подкрепляете социальную норму в противовес дублированию информации. Зачем дублировать ответ на один вопрос в двух разных местах? Когда число мест, в которых его можно найти, сохраняется минимальным, люди, которые нашли его однажды, с большей вероятностью вспомнят, где искать его снова. Правильно размещённые ссылки также влияют на качество результатов поиска в целом, потому что они увеличивают ранг искомого ресурса в поисковых механизмах Интернет. Однако, существуют случаи, когда дублирование информации имеет смысл. Например, предположим в архивах уже есть ответ, не ваш, в котором сказано: Такое впечатление, что у вас заклинило индексы Scanley. Чтобы расклинить их, сделайте так: 1. Остановите сервер Scanley. 2. Выполните программу 'defrobnicate', которая идёт в поставке вместе со Scanley. 3. Запустите сервер. Затем, несколько месяцев спустя, вы видите другое сообщение, указывающее на то, что у кого-то опять заклинило индексы. вы ищете в архивах и находите вышеприведённый ответ, но вы понимаете, что в нём отсутствует несколько шагов (то ли по ошибке, то ли потому, что ПО изменилось с тех пор, как был написан ответ). Самый стильный способ разрешить это - послать новое сообщение, с более полным набором инструкций, и явно указать на устаревшее старое сообщение: Такое впечатление, что у вас заклинило индексы Scanley. Мы уже встречались с этой проблемой в Июле, и J.Random посылал решение на http://blahblahblah/blah. Ниже приведено более полное описание, как восстановить ваши индексы, основанное на инструкциях J.Random'а, но несколько расширяющее их: 1. Остановите сервер Scanley. 2. Войдите пользователем, от имени которого обычно работает сервер Scanley. 3. От имени этого пользователя выполните программу 'defrobnicate' для индексов. 4. Запустите Scanley "руками", чтобы убедиться, что индексы теперь работают. 5. Перезапустите сервер. (В идеальном мире было бы возможно присоединить замечание к старому сообщению, говорящее, что есть более свежая информация, и указать на новое сообщение. Однако, я не знаю никакого ПО для работы с архивами, которое предлагало бы функцию "устарело по причине", возможно потому, что это достаточно сложно реализовать так, чтобы не нарушалась целостность архива как стенограммы. Это вторая причина, по которой создание выделенной web-страницы с ответами на общие вопросы является хорошей идеей.) Возможно, в архивах чаще всего ищут ответы на технические вопросы, но их важность для проекта выходит далеко за эти рамки. Если формальные принципы проекта - это его провозглашённые законы, то архивы - это его неписанные законы: запись всех принятых решений и того, как к ним пришли. В любой возобновляемой дискуссии нынче непременно надо начинать с поиска в архиве. Это позволяет вам начать разговор с обзора текущего состояния вещей, предвидеть возражения, подготовить опровержения и, возможно, обнаружить углы зрения, о которых вы не думали. Также и другие участники ожидают, что вы поискали в архивах. Даже если предыдущие дискуссии никуда не привели, вы должны включить указания на них, когда поднимаете тему снова, чтобы люди сами могли увидеть, что а) что они никуда не привели и б) что вы подготовились и поэтому, наверное, говорите сейчас что-то, что не было сказано раньше. Трактуйте все ресурсы как архивы Все предыдущие советы применимы не только к архивам списков рассылки. Размещение определённых блоков информации по постоянным, удобно находимым адресам должно быть принципом организации для всей информации проекта. Давайте возьмём FAQ проекта как иллюстрирующий пример. Как люди используют FAQ? Они хотят искать в нём определённые слова и фразы. Они хотят листать его, впитывая информацию, не обязательно ища ответы на конкретные вопросы. Они ожидают, что поисковые механизмы типа Google знают о содержимом данного FAQ'а, и поиск может выдать статью из него. Они хотят, чтобы других людей можно было прямо отсылать к конкретным пунктам FAQ'а. Они хотят, чтобы в FAQ можно было добавлять новые материалы, но заметим, что это происходит намного реже, чем поиск ответов - FAQ'и гораздо чаще читают, чем пишут в них. Пункт 1 означает, что FAQ должен быть доступен в некотором текстовом формате. Пункты 2 и 3 означают, что FAQ должен быть доступен в виде HTML-страницы, а пункт 2 дополнительно указывает, что этот HTML должен иметь читаемый вид (то есть, вам придется настроить его внешний вид) и таблицу содержания. Пункт 4 значит, что каждой конкретной статье в FAQ'е должен быть присвоен именованный якорь HTML, тег, который позволяет человеку перейти в конкретное место на странице. Пункт 5 значит, что исходные файлы FAQ должны быть доступны удобным способом (смотрите в ), в формате, который легко редактировать. Именованные якоря и атрибуты ID Есть два способа заставить браузер переходить на конкретное место внутри web-страницы: именованные якоря и атрибуты id. Именованный якорь - просто обычный элемент HTML "якорь" (<a>...</a>), но с атрибутом "name": <a name="mylabel">...</a> Более свежие версии HTML поддерживают общий атрибут id, который можно присоединить к любому элементу HTML, не только к <a>. Например: <p id="mylabel">...</p> И именованные якоря, и атрибуты id используются одинаково. Добавьте решётку и метку к URL, чтобы заставить браузер перейти прямо на то место страницы: http://myproject.example.com/faq.html#mylabel Фактически все браузеры поддерживают именованные якоря; большинство современных браузеров поддерживают атрибуты id. Чтобы подстраховаться, я рекомендую использовать либо только именованные якоря, либо именованные якоря и атрибуты id совместно (конечно, с одной и той же меткой для обоих в данной паре). Именованные якоря не могут быть самозакрывающимися - даже если внутри элемента нет текста, вы обязаны всё равно использовать полную (двухстороннюю) форму: <a name="mylabel"></a> ...хотя обычно там должен быть какой-то текст, типа названия раздела. Используете ли вы именованный якорь, или атрибут id, или оба, помните, что метка не будет видна тем, кто пришёл в данное место, не используя метку. Но они возможно захотят узнать метку для конкретного места для того, чтобы послать URL на FAQ, например, отвечая другу. Чтобы помочь им в такой ситуации, добавьте атрибут "title" к тому же самому элементу, к которому вы добавили атрибут "name" и/или "id", например: <a name="mylabel" title="#mylabel">...</a> Когда указатель мыши останавливается над текстом, находящимся внутри элемента с атрибутом "title", большинство браузеров показывают маленькую всплывающую рамку, отображающую заголовок (title). Я обычно добавляю символ решётки, чтобы напомнить пользователю, что это он должен поместить в конец URL для прямого перехода на данное место. Форматирование FAQ подобным образом - только один из примеров того, как сделать ресурс презентабельным. Те же свойства - возможность непосредственного поиска, доступность для основных поисковых машин Интернет, возможность просматривать браузером, постоянство ссылок и (где применимо) возможность редактирования - применимы к другим web-страницам, дереву исходных кодов, трекеру ошибок, и т.д. Просто так случилось, что ПО для архивов электронной почты в большинстве своём осознало важность этих свойств давным давно, вот почему списки рассылки как правило поддерживают эту функциональность естественным образом, тогда как другие форматы могут потребовать специальных усилий от поддерживающей стороны В ( обсуждается, как разделить груз такой поддержки между многими добровольцами Кодификация традиций По мере того, как проект накапливает историю и сложность, возрастает объём данных, который должен усваивать каждый новый участник. Те, кто находится в проекте долгое время, могли изучать и создавать соглашения по мере развития проекта. Они часто не отдают себе отчёта, какую массу традиций они аккумулировали, и могут удивляться тому, как много неверных шагов делают новички. Конечно, проблема не в том, что новички менее квалифицированы, чем те кто приходил раньше, а в том, что они сталкиваются с большим ассимиляционным грузом, чем раньше. Традиции, которые аккумулирует проект, связаны как с правилами коммуникации и хранением информации, так и со стандартами кодирования и другими техническими моментами. Мы уже рассмотрели оба вида стандартов в в и в соответственно, и примеры приведены там. О чём говорится в данном разделе, так это о том, как сохранить эти принципы актуальными по мере развития проекта, особенно принципы коммуникаций и управления, потому что именно они больше всего изменяются по мере роста размера и сложности проекта. Во-первых, следите за появлением шаблонности в ситуациях, когда люди не понимают как вести себя. Если вы видите, что одна и та же ситуация повторяется снова и снова, особенно с новичками, то скорее всего существует какой-то принцип, который должен был быть документирован, но этого не произошло. Во-вторых, не уставайте повторять снова и снова одни и те же вещи, и не показывайте виду, что устали их говорить. Вы и другие ветераны проекта должны будете часто повторяться; это незбежный побочный эффект притока новичков. Каждая web-страница, каждое сообщение в списке рассылки и каждый IRC-канал должны рассматриваться как место для рекламы - не для коммерческих объявлений, но для рекламирования собственных ресурсов вашего проекта. Что именно вы сюда помещаете, зависит от демографии предполагаемых читателей. Например, IRC-канал для вопросов пользователей скорее предназначен для людей, которые раньше никогда не сталкивались с проектом - часто для тех, кто просто установил ПО и хочет немедленно получить ответ на возникший вопрос (в конце концов, если бы он мог ждать, то послал бы вопрос в список рассылки, что, возможно, в итоге отняло бы у него меньше времени, хотя ответа пришлось бы ждать дольше). Люди обычно не уделяют постоянного внимания IRC-каналу; они показываются, задают свой вопрос и исчезают. Поэтому тема канала должна быть направлена на тех людей, которые ищут ответы на технические вопросы прямо сейчас, а не на людей, которые, скажем, вовлечены в проект на долгосрочной основе и для кого принципы взаимодействия сообщества более приемлемы. Вот как реальный нагруженный канал справляется с этим (сравните с более ранним примером в разделе в ): You are now talking on #linuxhelp Topic for #linuxhelp is Please READ http://www.catb.org/~esr/faqs/smart-questions.html && http://www.tldp.org/docs.html#howto BEFORE asking questions | Channel rules are at http://www.nerdfest.org/lh_rules.html | Please consult http://kerneltrap.org/node/view/799 before asking about upgrading to a 2.6.x kernel | memory read possible: http://tinyurl.com/4s6mc -> update to 2.6.8.1 or 2.4.27 | hash algo disaster: http://tinyurl.com/6w8rf | reiser4 out В списках рассылки "рекламное пространство" - это маленький "подвал", добавляемый к каждому сообщению. Большинство проектов помещают туда инструкции по подписке/отказу и, возможно, ссылку на домашнюю страницу проекта или страницу FAQ. Вы можете подумать, что каждый подписчик знает, где найти такие вещи, и, возможно, так и есть - но сообщения списка рассылки видят намного больше людей, чем только подписчики. На архивированную почту можно ссылаться из многих разных мест; и действительно, некоторые почтовые сообщения становятся настолько широко известными, что со временем имеют гораздо больше читателей вне списка рассылки, чем в нём. Форматирование может иметь большое значение. Например, в проекте Subversion мы добились только частичного успеха от использования техники фильтрации ошибок, описанной в разделе в . Множество сообщений о фиктивных ошибках всё ещё регистрировались неопытными пользователями, и каждый раз, когда это случалось, регистратора приходилось обучать точно так же, как 500 человек до этого. Однажды, после того, как один из наших разработчиков окончательно потерял терпение и оскорбил одного бедного пользователя, который недостаточно внимательно прочитал правила использования трекера проблем, другой разработчик решил, что этот шаблон уже достаточно "созрел". Он предложил нам переформатировать начальную страницу трекера проблем так, чтобы наиболее важная часть - предписание обсудить ошибку в списках рассылки или IRC-каналах до регистрации, было бы набрано огромными, жирными красными буквами на ярком жёлтом фоне и оставалось бы выше всего остального на странице. Мы так и сделали (вы можете видеть результат на ), в результате доля фиктивных ошибок при регистрации заметно упала . Мы всё ещё их получаем, конечно, - так будет всегда, - но доля упала значительно, даже когда возрасло число пользователей. Польза не только в том, что база данных ошибок содержит меньше хлама, но и в том, что те, кто отвечает на регистрацию проблем, остаются в лучшем расположении духа, и с большей вероятностью останутся доброжелательными, отвечая на теперь уже редкие ошибочные регистрации. Это улучшает как имидж проекта, так и психическое здоровье его добровольцев. Урок для нас состоял в том, что просто прописать принципы было недостаточно. Мы также должны были поместить их там, где бы их увидели те, кто в них больше всего нуждается, и подать их так, чтобы людям, незнакомым с проектом, было сразу понятно, что с ними необходимо ознакомится перед работой. Статические web-страницы - не единственное место для рекламы обычаев проекта. Надзор (в смысле дружеского напоминания, а не в смысле в наручники-и-в тюрьму) тоже необходим. Все инспекции, даже инспекции commit'ов, описанные в в должны включать обзор соблюдения или несоблюдения человеком норм проекта, особенно в отношении соглашений о коммуникациях. Ещё один пример из проекта Subversion: мы пришли к соглашению о том, что "r12908" обозначает "ревизия 12908 в репозитории контроля версий". Префикс "r" в нижнем регистре легко набирается, а поскольку он вполовину меньше высоты цифр, то представляет собой легко распознаваемый блок текста по сравнению с ними. Конечно, принятие соглашения не означает, что все начнут использовать его единообразно и сразу. Если приходит почта с commit'ом и следующим log-message'ем: ------------------------------------------------------------------------ r12908 | qsimon | 2005-02-02 14:15:06 -0600 (Wed, 02 Feb 2005) | 4 lines Patch from J. Random Contributor <jrcontrib@gmail.com> * trunk/contrib/client-side/psvn/psvn.el: Fixed some typos from revision 12828. ------------------------------------------------------------------------ ..., то часть инспекции этого commit'а должна быть посвящена тому, чтобы сказать: "Кстати, пожалуйста, используйте 'r12828', а не 'revision 12828', когда ссылаетесь на предыдущие изменения." Это не просто педантизм; это важно как для возможности автоматического разбора (парсинга), так и для чтения людьми. Если проект придерживается принципа, что для распространенных сущностей должны существовать предписания по их именованию, и этим предписаниям следуют неуклонно, то в результате рождаются определённые стандарты. Эти стандарты позволяют людям писать утилиты, которые позволяют упростить коммуникации в проекте - например, ревизию, отформатированную как "r12828", можно трансформировать в действующую ссылку в системе просмотра репозитория. Это было бы труднее сделать, если бы ревизия была записана как "revision 12828", как потому, что эта форма может делиться символом перевода строки, так и потому, что она менее точная (слово "revision" будет часто встречаться само по себе, и группа цифр будет часто встречаться сама по себе, тогда как комбинация "r12828" может означать только номер ревизии). Аналогичные соображения применимы к номерам проблем, пунктам FAQ (совет: используйте URL с именованным якорем, как описано во врезке ), и т.д. Людей надо стимулировать представлять блоки информации одинаково даже тогда, когда речь идет о сущностях, для которых трудно придумать компактную форму именования. Например, при ссылке на сообщение списка рассылки, давать не только отправителя и тему, а также давать URL в архиве и Message-ID заголовка. Последний позволяет людям, имеющим свою собственную копию списка рассылки (люди иногда сохраняют offline-копии, например, для использования в ноутбуке во время путешествий), однозначно идентифицировать нужное сообщение, даже если они не имеют доступа к архивам. Только указания отправителя и темы будет не достаточно, потому что один и тот же человек может послать несколько сообщений в одну и ту же ветку, и даже в один и тот же день. Чем больше растёт проект, тем более важным становится этот вид постоянства. Постоянство означает, что куда бы люди не посмотрели, они видят одни и те же шаблоны, которым следуют, так что они знают, что и они должны им следовать. Это, в свою очередь, уменьшает количество вопросов, которые они вынуждены задавать. Бремя иметь миллион читателей не больше, чем бремя иметь одного; проблемы масштаба начинаются только тогда, когда какой-то процент этих читателей задаёт вопросы. Поэтому с ростом проекта надо уменьшать этот процент путём повышения плотности и доступности информации так, чтобы любой отдельный человек с большей вероятностью мог найти то, что ему надо, не задавая вопросов. Нет разговорам в трекере ошибок В любом проекте, который активно использует трекер ошибок, всегда существует опасность превращения трекера в самостоятельный дискуссионный форум, несмотря на то, что списки рассылки действительно лучше. Обычно это начинается вполне невинно: кто-нибудь комментирует проблему, скажем, возможным решением или частичным патчем. Кто-нибудь другой видит это, понимает, что с решением есть проблема, и присоединяет другое примечание, указывающее на проблему. Первый отвечает, снова комментируя проблему... и так далее. Проблема заключается, во-первых, в том, что трекер ошибок - очень нескладное место для дискуссий, а во-вторых, в том, что это может пройти мимо внимания других людей - в конце концов, они ожидают, что дискуссии по разработке происходят в соответствующем списке рассылки, и там они их и ищут. Они могут быть вообще не подписаны на список, связанный с изменением проблем, а если и подписаны, могут не следить за ним слишком внимательно. Но когда точно процесс дал сбой? Случилось ли это тогда, когда первый участник присоединил своё решение к проблеме - должен ли он был вместо этого послать сообщение в список рассылки? Или это случилось, когда второй участник ответил в трекере, а не в списке? Не существует единственно правильного ответа, но существует общий принцип: если вы просто добавляете данные к проблеме, делайте это в трекере, но если вы начинаете разговор, то делайте это в списке рассылки. Иногда непросто отличить одно от другого, просто доверьтесь вашему чутью. Например, когда присоединяете патч, содержащий противоречивое решение, ожидайте, что у людей появятся вопросы по этому поводу. Так что даже если вы в обычной ситуации присоединили бы патч к проблеме (предположим, что вы не хотите или не имеете права делать прямые commit'ы), в данном случае вы возможно захотите опубликовать сообщение в список рассылки. В любом случае, настанет момент, когда одна из сторон может сказать, что надо перейти от простого добавления данных к настоящему разговору - в примере, которым начинался данный раздел, это мог быть второй респондент, который, найдя проблему в патче, мог предвидеть, что готов начаться реальный разговор, и поэтому его надо вести соответствующим способом. Пользуясь математической аналогией, если информация выглядит так, что она будет быстро сходиться, помещайте её прямо в трекер ошибок; если будет расходиться, то список рассылки или IRC-канал будут более подходящим местом. Это не означает, что в трекере никогда не должно быть никаких переговоров. Запрос у первого респондента подробностей о том как воспроизвести проблему, например, представляется быстро сходящимся процессом. Ответ вряд ли породит новые проблемы; он просто должен конкретизировать информацию, которая уже выложена. Нет необходимости обременять список рассылки этим процессом, решите это серией комментариев в трекере. Аналогично, если вы точно уверены, что ошибка зарегистрирована неверно (например, не является ошибкой), то можете сказать об этом прямо в трекере. Можно даже указывать на небольшие проблемы в предложенном решении возможно, если они не блокируют решение в целом. С другой стороны, если вы поднимаете философские проблемы, связанные с областью распространения ошибки или желаемым поведением, можете быть уверены, что другие разработчики захотят присоединиться. Дискуссия наверное будет расходиться до того, как сойтись, так что делайте это в списке рассылки. Всегда указывайте ссылку на трекере, если вы решили написать в список рассылки. Для кого-то, кто следит за проблемой, важно не потерять дискуссию, даже если сам трекер не место для неё. Для человека, который открывает тему, это может казаться утомительным, но ПО с открытым кодом - это в своей основе культура ответственного письма: гораздо более важно сделать вещь понятной для десятков сотен людей, которые могут прочитать об ошибке, чем для трёх или пяти человек, которые пишут в связи ней. Хорошо взять важные выводы или резюме из дискуссии в списке рассылки и вставить их в трекер, если это будет удобно для читающих. Общая идиома такова: откройте дискуссию в списке, поместите в трекер ссылку на открытую тему, а по окончании обсуждения вставьте полученное резюме в трекер (вместе со ссылкой на сообщение, содержащее это резюме), чтобы любой, просматривающий проблему мог легко понять, к какому выводу пришли, не кликая больше никуда. Отметим, что обычной проблемы дублирования данных здесь нет, потому что и архивы, и комментарии в трекере обычно всё равно статические, неизменяемые данные. Публичность В свободном ПО существует очень тонкая грань между чисто внутренними дискуссиями и публичными заявлениями. Отчасти это так, потому что целевая аудитория всегда размыта: учитывая, что большинство или все сообщения доступны публично, проект не имеет полного контроля над образом, который получает окружающий мир. Кто-то - скажем, редактор slashdot.org может привлечь внимание миллионов читателей к сообщению, которое никто не ожидал увидеть вне границ проекта. Это факт, с которым приходится мирится всем проектам свободного ПО, но на практике такой риск обычно мал. Как правило, объявления, которые проект хочет сделать наиболее публичным, и будут наиболее публичными, предполагая, что вы используете правильные средства для того, чтобы показать внешнему миру какие из сообщений стоят того, чтобы сделать из них новости. Для важных объявлений, в общем, есть четыре или пять основных каналов распространения, в которых надо сделать эти объявления по возможности одновременно: Главную страницу вашего проекта, возможно, просматривает большее число людей, чем любую другую часть проекта. Если сообщение действительно важно, поместите здесь рекламу. Реклама должна представлять собой короткое резюме, отсылающее к пресс-релизу (смотрите ниже) за более подробной информацией. В то же время, у вас должно быть место на web-сайте для "Новостей" или "Пресс-релизов", где объявление может быть расписано в деталях. Отчасти, цель пресс-релиза - это представить простой, базовый "объект объявления", на который могли бы ссылаться другие сайты, так что позаботьтесь, чтобы он был соответственно структурирован: либо одна web-страница на один релиз, как отдельная статья блога, либо в виде какой-то другой сущности, на которую можно ссылаться, и которая оставалась бы отличной от других релизов в том же месте. Если в вашем проекте имеется лента RSS (см. ), позаботьтесь, чтобы объявление попало и туда. Это может происходить автоматически при создании пресс-релиза, в зависимости от того, как устроен ваш сайт. Если объявление касается нового выпуска ПО, то обновите запись о вашем проекте на (см. о создании записи в первый раз). Каждый раз, когда вы обновляете запись на Freshmeat, эта запись попадает в список дневных изменений Freshmeat. Список изменений обновляется не только на самом Freshmeat, но и на различных порталах (включая ) которые просматривают огромные толпы людей. Freshmeat также предлагает эту информацию через ленту RSS, так что люди, которые не подписаны на RSS-ленту вашего проекта, тем не менее, смогут увидеть объявление через ленту Freshmeat. Пошлите сообщение в новостной список рассылки вашего проекта. Название этого списка должно быть действительно "announce", то есть, announce@yourprojectdomain.org, поскольку сейчас это уже очевидное стандартное соглашение, и устав списка должен утверждать, что это очень ненагруженный список, зарезервированный для важных объявлений проекта. Большинство из таких объявлений будут о новых выпусках ПО, но иногда могут быть сообщения и о других событиях, таких как кампания по сбору средств, обнаружение брешей в безопасности (смотрите ) ниже в этой главе, или важные сдвиги в направлении проекта. Поскольку трафик мал и используется только для важных вещей, список announce обычно имеет наибольшее число подписчиков среди списков рассылки проекта (конечно, это означает, что вы не должны злоупотреблять этим - подумайте хорошенько перед тем, как писать). Чтобы оградить список от объявлений случайных людей или, ещё хуже, спама, список announce должен, конечно, модерироваться. Постарайтесь сделать объявления во всех этих местах одновременно, насколько возможно. Людей может ввести в заблуждение объявление в списке рассылки, если они не видят его подтверждения на главной странице проекта или в пресс-релизах. Если вы поставили различные изменения (почту, изменение web-страницы и т.д.) в ожидание и затем послали их все одновременно, вы можете сделать окно несоответствия очень маленьким. Для менее важных событий вы можете пропустить какие-то или все из приведённых каналов. Событие всё равно будет замечено во внешнем мире в зависимости от его важности. Например, новый выпуск ПО - это важное событие, тогда как просто объявление даты следующего выпуска - хотя и нечто интересное, но совсем не такое важное, как сам выпуск. Установка даты - подходящее сообщение для ежедневных списков рассылки (а не для списка announce), для обновления графика проекта и web-страницы текущего состояния, но не более. Несмотря на это, вы всё же увидите, что дата релиза появляется в дискуссиях в разных местах в Интернете, где есть люди, заинтересованные в проекте. Люди-невидимки в ваших списках рассылки, которые просто слушают и никогда ничего не говорят, не обязательно молчат где-то ещё. Народная молва - очень широкий канал распространения; вы должны считаться с этим и строить даже второстепенные объявления таким образом, чтобы поддерживать точную передачу информации. В особенности, сообщения, которые предположительно будут цитироваться, должны иметь очевидную предназначенную-для-цитирования часть, как будто вы пишите официальный пресс-релиз. Например:
Уточнение планов: мы планируем выпустить версию 2.0 Scanley в середине Августа 2005 года. Вы всегда можете проверить наличие обновлений на http://www.scanley.org/status.html. Основной новой функцией будет поиск по регулярным выражениям. Другие новые функции включают: ... Также будут исправлены различные ошибки, включая: ...
Первый параграф - короткий, выдаёт две наиболее важные порции информации (дата выпуска и главная новая функция), а также URL для просмотра будущих новостей. Если этот параграф - единственное, что пройдёт через чьё-то сито, - это тоже нормально. Остаток сообщения можно опустить, не искажая сущность содержимого. Конечно, некоторые люди всё равно дадут ссылку на полное сообщение, но часто они будут цитировать только небольшую часть. Учитывая вероятность последнего, вы можете облегчить им это занятие и получить свою выгоду о того, что контролируете, что именно будет процитировано. Объявление о дырах в безопасности Управление отчётом об уязвимости в безопасности отличается от управления отчётом о любой другой ошибке. В открытом ПО делать всё открыто и понятно - это обычно почти религиозное кредо. Каждый шаг стандартного процесса исправления ошибки виден всем, кто хочет видеть: появление первоначального отчёта, подтверждающая дискуссия и окончательное исправление. Ошибки безопасности не такие. Они могут скомпрометировать данные пользователей или компьютеры пользователей в целом. Открытое обсуждение такой проблемы было бы рекламой во всем мире - включая всех тех, кто может злонамеренно использовать ошибку. Даже простой commit исправления в действительности анонсирует существование ошибки (есть потенциальные нападающие, которые просматривают журналы commit'ов открытых проектов, систематически выискивая изменения, которые указывают на проблемы безопасности в коде до изменения). Большинство проектов открытого ПО принимают примерно одинаковый набор шагов для урегулирования конфликта между открытостью и секретностью, основанный на следующих базовых положениях: Не говорите об ошибке публично, пока не готово исправление; затем предоставьте исправление одновременно с объявлением об ошибке. Поторопитесь с таким исправлением, как только можете - особенно, если об ошибке сообщил кто-то снаружи проекта, потому что вы знаете, что есть по крайней мере один человек вне проекта, который способен использовать уязвимость. На практике такие принципы приводят к достаточно стандартизованной серии шагов, которые описаны в следующих разделах. Получите отчёт Очевидно, проекту нужна возможность получать от кого угодно отчёты об ошибках в безопасности. Но это не может быть адрес списка рассылки для отчётов об обычных ошибках, поскольку этот адрес открыт для всех. Поэтому заведите отдельный список рассылки для приёма отчётов об ошибках безопасности. У этого списка не должно быть общедоступного архива и подписчики на него должны строго контролироваться - только проверенные разработчики, участвующие длительное время, могут ими быть. Если вам нужно формальное определение слова "проверенный", можете использовать "любой, у кого был доступ на commit два и более года" или что-нибудь в этом роде, чтобы избежать фаворитизма. Это группа, которая будет разбираться с ошибками безопасности. В идеале список безопасности не должен модерироваться и защищаться от спама, поскольку вы не захотите, чтобы важный отчёт был отфильтрован или задержан, потому что в эти выходные ни один модератор не был в сети. Если вы вынуждены использовать ПО для защиты от спама, попробуйте настроить его с очень мягкими установками; лучше пусть будет какой-то спам, чем потеряется отчёт. Чтобы список был эффективным, вы должны, конечно, отрекламировать его адрес; но, учитывая, что он будет немодерированным, более того, слабо защищённым от спама, постарайтесь никогда не посылать этот адрес без какого-либо преобразования для скрытия адреса, как описано в разделе в . К счастью, скрытие адреса не обязательно делает его нечитаемым; посмотрите , и её HTML-исходник для примера. Негласно разработайте исправление Что же должна делать группа безопасности, когда она получает отчёт? Первая задача - исследовать серьёзность и срочность проблемы: Насколько серьёзна уязвимость? Позволяет ли она злоумышленнику получить контроль над компьютером того, кто использует ваше ПО? Или, скажем, просто подсмотреть информацию о размерах некоторых файлов пользователей? Насколько просто использовать уязвимость? Достаточно написать скрипт для атаки или для этого требуются обстоятельные знания, догадки, основанные на опыте, и удача? Кто сообщил вам о проблеме? Ответ на этот вопрос, конечно, не изменяет природы уязвимости, но он даёт вам представление о том, сколько народу может о ней знать. Если отчёт пришёл от одного из собственных разработчиков проекта, вы можете вздохнуть несколько свободнее (но только чуть-чуть), потому что вы можете надеяться, что они не рассказали об этом кому-то ещё. С другой стороны, если он пришёл от anonymous14@globalhackerz.net то будет лучше, если вы начнёте действовать как можно быстрее. Человек, в конце концов, оказал вам услугу, сообщив о проблеме, но вы не имеете представления, скольким ещё людям он это сказал, или как долго он будет ждать перед тем, как воспользоваться уязвимостью на живых инсталляциях. Отметьте, что разница, о которой мы говорим, часто лежит между срочно и чрезвычайно срочно. Даже когда отчёт поступает из известного, дружественного источника, могут существовать другие люди в Сети, которые давно нашли эту ошибку и просто не сообщают о ней. Единственный случай, когда всё не так срочно, это когда ошибка по своей природе не очень серьёзно влияет на безопасность. Пример с "anonymous14@globalhackerz.net" кстати, не шутка. Вы действительно можете получать отчёты об ошибках от скрывающих личность людей, которых, по их словам и поведению, никогда нельзя уверенно отнести ни на вашу сторону, ни на противоположную. Это не имеет значения: если они сообщили вам о дые в безопасности, они полагают, что сделали вам добро, и вы должны ответить тем же. Поблагодарите их за отчёт, сообщите дату, когда или до которой, вы планируете выпустить публичное исправление, и не распространяйтесь об этих людях. Иногда они могут назначить вам дату - то есть, недвусмысленно угрожать опубликовать ошибку в определённый день, будете вы готовы или нет. Это может выглядеть как попытка силой загнать вас в угол, но более вероятно, это упреждающее действие, являющееся результатом прошлых разочарований в безразличных производителях ПО, которые не воспринимали отчёты о безопасности достаточно серьёзно. В любом случае, вы не можете допустить, чтобы этот человек рассердился. В конце концов, если ошибка серьёзная, он обладает знаниями, которые могут вызвать большие неприятности у ваших пользователей. Относитесь к таким корреспондентам хорошо и надейтесь, что они будут относиться к вам также. Другой частый корреспондент, сообщающий о дырах безопасности, - профессионал по безопасности, некто, кто занимается аудитом кода по жизни и следит за последними новостями в сфере уязвимости ПО. Эти люди обычно имеют опыт по обе стороны забора - они и посылали и получали отчёты, возможно больше, чем большинство разработчиков вашего проекта. Они также обычно назначают крайний срок устранения уязвимости перед преданием её огласке. Крайний срок можно обговорить, но он остается на усмотрение корреспондента. Крайние сроки превратились среди профессионалов по безопасности в единственный надёжный рычаг контроля над организациями, заставляющий их реагировать на проблемы быстро. Так что не рассматривайте крайний срок как грубость; это освящённая веками традиция, и для этого есть основания. Как только вы выяснили серьёзность и срочность, вы можете начать работу над исправлением. Иногда существует компромисс между тем, сделать ли исправление элегантно, либо быстро; вот почему вы должны условиться о срочности перед тем как начнёте. Конечно, ограничивайте обсуждение исправления членами списка рассылки по безопасности, инициировавшим обсуждение корреспондентом (если он захочет) и разработчиками, которых необходимо включить по техническим причинам. Не добавляйте исправление в репозиторий. Оставьте его в виде патча до даты обнародования. Если вам пришлось выложить его, даже сопроводив выглядящим невинно комментарием, кто-нибудь может заметить и понять его. Вы никогда не знаете, кто просматривает ваши репозитории и почему ими интересуются. Не поможет отключение почтовых уведомлений о commit'ах; прежде всего, зазор в последовательности сам по себе выглядит подозрительно, и ведь всё равно данные в репозитории будут. Просто ведите всю разработку в виде патча и храните его в каком то секретном месте, возможно, в отдельном закрытом репозитории, известном только людям, которые уже осведомлены об ошибке. (Если вы используете децентрализованную систему контроля версий типа Arch или SVK, вы можете выполнять работу под полным контролем версий, просто сохраняя репозиторий недоступным извне.) Номера CAN/CVE Вы, возможно, встречали номера CAN или CVE, связанные с проблемами безопасности. Эти номера выглядят, например, как "CAN-2004-0397" или "CVE-2002-0092". Числа обоих видов представляют сущность одного типа: запись в списке "Общие уязвимости и опасности", который ведётся на . Цель списка - предоставить централизованные имена для всех известных проблем безопасности, чтобы каждый мог использовать уникальное каноническое имя при обсуждении проблемы, и центральное место, куда надо идти за дополнительной информацией. Единственное различие между CAN- и CVE-номером в том, что первый представляет запись-кандидат, ещё не проверенную для включения в официальный список Редакционной Коллегией CVE, а второй - проверенную запись. Однако, оба типа записей видны публично, и номер записи не изменяется после проверки - просто префикс "CAN" заменяется на "CVE". Сам записи CAN/CVE не содержат полного описания ошибки и защиты от неё. Вместо этого они содержат краткое резюме и список ссылок на внешние ресурсы (такие как архивы списков рассылки), на которых люди могут найти более подробную информацию. Реальная цель - предоставить хорошо организованное место, где каждая уязвимость могла бы иметь имя и простой доступ к дальнейшим данным. Смотрите Заметим, что ссылки могут быть очень сжатыми, в которых источники кажутся зашифрованными аббревиатурами. Ключ к таким аббревиатурам находится на . Если ваша уязвимость удовлетворяет критерию CVE, вы можете пожелать получить для неё номер CAN. Эта процедура намеренно защищена: в общем, вы должны знать кого-нибудь, или знать кого-то, кто знает кого-нибудь. Это не так безумно, как кажется. Чтобы оградить Редакционную Коллегию CVE от завала фальшивыми или плохо оформленными представлениями, они принимают представления только от источников, которые они уже знают и которым доверяют. Чтобы вставить вашу уязвимость в список, вы должны найти способ извещения Редакционной Коллегии CVE о вашем проекте. Опросите своих разработчиков; возможно кто-нибудь из них знает кого-то ещё, кто проходил процесс CAN раньше, или знает того, кто знает, и т.д. Преимущество такого подхода ещё и в том, что где-то в цепочке есть кто-то, кто знает достаточно, чтобы сказать вам, что а) это не может считаться уязвимостью или опасностью в соответствии с критерием MITRE, так что нет смысла представлять её, или что б) уязвимость уже имеет CAN- или CVE-номер. Последнее могло случиться, если ошибка уже была опубликована в другом консультативном списке безопасности, например, на или в списке BugTraq на . (Если это произошло, а в вашем проекте об этом неизвестно, то вы должны обеспокоиться тем, что ещё могло случиться, о чём вы не знаете.) Если вы вообще получаете номер CAN, вы обычно хотите сделать это на ранних стадиях изучения ошибки, чтобы все остальные обсуждения могли ссылаться на этот номер. На записи CAN накладывается эмбарго до даты оглашения; запись будет существовать в виде пустого зарезервированного места (чтобы вы не потеряли имя), но не будет показывать никакой информации об уязвимости до того дня, когда вы объявите об ошибке и исправите её. Больше о процессе CAN/CVE можно найти на , и особенно подробное описание конкретного использования в проекте открытого ПО номеров CAN/CVE - на . Пред-объявление Как только ваша команда безопасности (то есть, те разработчики, которые подписаны на список рассылки безопасности или те, кто добавился в связи с конкретным отчётом) получила готовое исправление, вы должны решить, как его распространить. Если вы просто выложите исправление в репозиторий или иным способом сообщите о нём миру, вы насильно заставляете каждого, кто пользуется вашим ПО, немедленно произвести обновление или подвергнуться риску быть атакованным. Поэтому, иногда уместно сделать пред-объявление для некоторых важных пользователей. Это особенно верно для клиент-серверного ПО, когда могут существовать хорошо известные серверы, которые являются соблазнительными целями для атакующих. Администраторы таких серверов оценят дополнительные день-два, которые они получат для установки обновлений, чтобы быть защищёнными в тот момент, когда угроза станет публичным достоянием. Пред-объявление просто означает посылку email-сообщений таким администраторам до даты опубликования, с описанием уязвимости и способа исправления. Вы должны послать пред-объявление только тем людям, которые, по вашему мненинию, будут осторожны с этой информацией. То есть, оснований для посылки пред-объявления должно быть два: получатель должен эксплуатировать большой важный сервер, для которого компрометация будет серьёзным делом, плюс получать должен быть известен как человек, который не будет болтать о проблеме безопасности до дня опубликования. Посылайте каждое пред-уведомляющее письмо по отдельности (по одному за раз) каждому получателю. Не посылайте всему списку получателей сразу, потому что тогда они увидят имена друг друга - что означает, что вы предупреждаете каждого получателя, что у других могут быть дырки в безопасности. Посылка с использованием скрытых CC (BCC) также нехорошее решение, потому что некоторые администраторы защищают свои входящие ящики при помощи спам-фильтров, которые либо блокируют, либо уменьшают приоритет почты, полученной через BCC, поскольку слишком много спама посылается в наши дни через BCC. Вот простое пред-уведомляющее письмо: From: Здесь ваше имя To: admin@large-famous-server.com Reply-to: Здесь ваше имя (но не адрес списка безопасности) Subject: Конфиденциальное уведомление о уязвимости Scanley. Это сообщение - конфиденциальное пред-уведомление об ошибке безопасности в сервере Scanley. Пожалуйста, *не делайте forward* никакой части этого сообщения кому бы то ни было. Публичное объявление будет только 19 мая, и мы бы хотели сохранить информацию закрытой до этой даты. Вы получили это сообщение, потому что (мы надеемся) вы используете сервер Scanley и захотите наложить патч до того, как эта дыра в безопасности станет достоянием гласности 19 мая. Ссылки: ======= CAN-2004-1771: Переполнение стека Scanley в запросах Уязвимость: =========== Сервер можно заставить выполнять любые команды, если локаль сервера сконфигурирована неудачно и клиент посылает неверный запрос. Серьёзность: ============ Очень серьёзно, может повлечь исполнение произвольного кода на сервере. Обходные пути: ============== Установка опции 'natural-language-processing' в 'off' в файле scanley.conf закрывает данную уязвимость. Патч: ===== Приведённый ниже патч применим к Scanley 3.0, 3.1, и 3.2. Новое публичное обновление (Scanley 3.2.1) будет выпущено 19 мая или накануне, так что оно станет доступно одновременно с публичным объявлением о данной уязвимости. Вы можете наложить патч сейчас, либо дождаться публичного обновления. Единственным различием между 3.2 и 3.2.1 будет данный патч. [...здесь следует патч...] Если у вас есть номер CAN, включите его в пред-уведомление (как показано выше), даже если информация всё ещё закрыта и, следовательно, страница MITRE ничего не покажет. Включение номера CAN позволяет получателю убедиться, что ошибка, о которой его предуведомили, та же самая, о которой он затем узнает по общедоступным каналам, так что он не должен беспокоиться о том, нужны или нет дальнейшие действия, что и составляет суть номеров CAN/CVE. Публичное распространение исправления Последним шагом в обработке ошибки безопасности стоит публичное распространение исправления. В единственном обстоятельном объявлении вы должны описать проблему, дать номера CAN/CVE, если они есть, описать способ временного обхода и способ полного устранения. Обычно "устранить" ("fix") означает провести обновление до новой версии ПО, хотя иногда это означает наложение патча, особенно, если ПО в нормальном состоянии всё равно выполняется из исходников. Если вы сделали новый выпуск, он должен отличаться от предыдущего выпуска только патчем безопасности. Тогда консервативные администраторы могут провести обновление, не беспокоясь о том, на что ещё оно может повлиять; они также не должны беспокоиться по поводу следующих обновлений, поскольку исправление, конечно, будет в них входить естественным образом. (Детали процедур выпуска описываются в в .) Даже если публичное исправление не ведет к появлению нового выпуска, сделайте объявление примерно с таким же приоритетом, как будто новый выпуск состоялся: пошлите сообщение в список announce проекта, создайте новый пресс-релиз, обновите запись Freshmeat, и т.д. Хотя вы никогда не должны пытаться преуменьшить наличие ошибок безопасности, заботясь о репутации проекта, вы можете, несомненно, сохранить тон и громкость объявления соответствующей действительной серьёзности проблемы. Если дыра в безопасности - просто возможность раскрытия несущественной информации, а не ошибка, которая позволяет получить управление всем компьютером пользователя, то она может не вызывать сильного беспокойства. Вы даже можете решить не беспокоить этим список announce. В конце концов, если проект каждый раз поднимает ложную тревогу, пользователи начинают думать, что ПО меньше защищено, чем это есть на самом деле, а также могут не поверить вам, когда вы анонсируете действительно большую проблему. Смотрите на хорошее введение в проблему установления серьёзности. В общем, если вы не уверены, как обращаться с проблемой безопасности, найдите кого-нибудь опытного и поговорите об этом с ним. Оценка и обработка уязвимостей очень сильно зависит от опыта, и первые несколько раз легко сделать неверные шаги.