Цена успеха в мире ПО с открытым кодом высока. По мере роста популярности вашего ПО, число людей, которые ищут информацию растет стремительно, тогда как число людей, способных поделиться информацией растёт намного медленнее. Более того, даже если бы они увеличивались сбалансировано, оставалась бы фундаментальная проблема масштабируемости средств коммуникации для большинства проектов открытого ПО. Рассмотрим, например, списки рассылки. В большинстве проектов есть список для общих вопросов пользователей - иногда он называется "users", "discuss", "help", или как-то ещё. Каково бы ни было его имя, цель списка всегда одна и та же: предоставить место, где одни люди могут получить ответы на свои вопросы, а другие ищут и (предполагается) накапливают знания, наблюдая за этим обменом.
Такие списки рассылки работают очень хорошо если в них участвуют до нескольких тысяч участников или/и в них рассылается до сотен сообщений в день. Но примерно после этого система начинает давать сбои, потому что каждый подписчик видит каждое сообщение; если число сообщений в списке начинает превышать то, которое отдельный читатель способен переработать за день, список начинает тяготить участников. Представим, например, что Microsoft имеет такой список для Windows XP. Windows XP имеет сотни миллионов пользователей; если даже одна десятая процента из них зададут вопрос в течение заданного 24-часового интервала, то в этом гипотетическом списке будут появляться сотни тысяч сообщений в день! Подобный список, конечно, никогда не смог бы существовать, потому что ни один человек не оставался бы его подписчиком. Эта проблема не ограничивается списками рассылки; та же логика применима к каналам IRC, форумам, и вообще к любым системам, в которых группа выслушивает вопросы индивидуумов. Последствия угрожающи: обычная для открытого ПО модель массовой параллельной поддержки просто не масштабируется на уровни, требующиеся для всемирного распространения.
Когда форумы достигнут своих критических точек, взрыва не будет. Просто возникнет неощутимый отрицательный обратный эффект: люди отписываются от списков, или покидают каналы IRC, или на каком-то этапе перестают задавать вопросы, потому что видят, что их могут не услышать в этом шуме. По мере того, как всё больше и больше людей делают этот в высшей степени рациональный выбор, будет казаться, что активность в форуме остаётся на управляемом уровне. Но она остаётся управляемой в точности потому, что рациональные (или, по крайней мере, опытные) люди начали искать информацию где-то в других местах - тогда как неопытные люди остались и продолжают писать. Другими словами, один из побочных эффектов от продолжения использования, по мере роста проекта, немасштабируемой коммуникационной модели заключается в том, что среднее качество как вопросов, так и ответов снижается, и всё выглядит так, как будто новые пользователи глупее, чем прежде, хотя фактически они, вероятно, не такие. На самом же деле отношение пользы к затратам при использовании таких высоко-популярных форумов падает, и естественно, более опытные люди начинают сначала искать ответы в других местах. Поэтому, настройка механизмов коммуникации при росте проекта состоит из двух связанных стратегий:
Определение момента, когда определённые части форума перестают справляться с безграничным ростом, даже если форум в целом справляется, и выделение таких частей в новые, более специализированные форумы (то есть, не позволяйте плохому разрушать хорошее).
Отслеживание того, что доступно много автоматических источников информации, и что они организованы, актуальны, и в них легко искать.
Первой стратегии обычно не сложное следовать. Большинство проектов начинаются с одного главного форума: списка рассылки по всем вопросам, в котором перемешивается всё от функциональных идей и вопросов дизайна до проблем кодирования. Каждый, участвующий в проекте, - в этом списке. Через некоторое время обычно становится ясно, что список эволюционировал в несколько самостоятельных подсписков со своими темами. Например, какие-то темы очевидно касаются разработки и дизайна; другие - вопросов пользователей типа "Как мне сделать X?"; возможно, есть третье семейство вопросов, сконцентрированных вокруг обработки отчётов об ошибках и запросов на доработку; и так далее. Конкретный индивид, конечно, может участвовать в нескольких различных ветках форума, но важно то, что сами ветки не сильно перекрываются. Их можно разделить на отдельные списки рассылки, не вызывая пагубной балканизации, поскольку вопросы редко пересекают границы тем.
Деление представляет собой двухшаговый процесс. Вы создаёте новый список (или канал IRC, или что-то, что требуется), и затем проводите столько времени, сколько потребуется, вежливо занудствуя и напоминая людям, чтобы они использовали соответствующие новые форумы. Этот последний шаг может занять несколько недель, но в итоге люди воспримут идею. Вы просто должны напоминать всякий раз, когда отправитель посылает сообщение не туда, и делать это явно, так, чтобы поощрить и других людей к переходу. Полезно также иметь web-страницу с инструкцией по всем имеющимся спискам рассылки; ваши ответы могут просто ссылаться на эту страницу, и, как бонус, получатель может что-то узнать, изучая правила перед отправкой сообщений.
Стратегия (2) - непрерывный процесс, продолжающийся всё время жизни проекта и вовлекающий много участников. Конечно, частично этот вопрос перекликается с вопросом наличия актуальной документации (смотрите «Документация» в Глава 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 должны быть доступны удобным способом (смотрите «Version everything» в Глава 3, Техническое обеспечение), в формате, который легко редактировать.
Форматирование FAQ подобным образом - только один из примеров того, как сделать ресурс презентабельным. Те же свойства - возможность непосредственного поиска, доступность для основных поисковых машин Интернет, возможность просматривать браузером, постоянство ссылок и (где применимо) возможность редактирования - применимы к другим web-страницам, дереву исходных кодов, трекеру ошибок, и т.д. Просто так случилось, что ПО для архивов электронной почты в большинстве своём осознало важность этих свойств давным давно, вот почему списки рассылки как правило поддерживают эту функциональность естественным образом, тогда как другие форматы могут потребовать специальных усилий от поддерживающей стороны В (Глава 8, Managing Volunteers обсуждается, как разделить груз такой поддержки между многими добровольцами
По мере того, как проект накапливает историю и сложность, возрастает объём данных, который должен усваивать каждый новый участник. Те, кто находится в проекте долгое время, могли изучать и создавать соглашения по мере развития проекта. Они часто не отдают себе отчёта, какую массу традиций они аккумулировали, и могут удивляться тому, как много неверных шагов делают новички. Конечно, проблема не в том, что новички менее квалифицированы, чем те кто приходил раньше, а в том, что они сталкиваются с большим ассимиляционным грузом, чем раньше.
Традиции, которые аккумулирует проект, связаны как с правилами коммуникации и хранением информации, так и со стандартами кодирования и другими техническими моментами. Мы уже рассмотрели оба вида стандартов в «Документация разработчика» в Глава 2, Начало работы и «Writing It All Down» в Глава 4, Социальная и политическая инфраструктура соответственно, и примеры приведены там. О чём говорится в данном разделе, так это о том, как сохранить эти принципы актуальными по мере развития проекта, особенно принципы коммуникаций и управления, потому что именно они больше всего изменяются по мере роста размера и сложности проекта.
Во-первых, следите за появлением шаблонности в ситуациях, когда люди не понимают как вести себя. Если вы видите, что одна и та же ситуация повторяется снова и снова, особенно с новичками, то скорее всего существует какой-то принцип, который должен был быть документирован, но этого не произошло. Во-вторых, не уставайте повторять снова и снова одни и те же вещи, и не показывайте виду, что устали их говорить. Вы и другие ветераны проекта должны будете часто повторяться; это незбежный побочный эффект притока новичков.
Каждая web-страница, каждое сообщение в списке рассылки и каждый IRC-канал должны рассматриваться как место для рекламы - не для коммерческих объявлений, но для рекламирования собственных ресурсов вашего проекта. Что именно вы сюда помещаете, зависит от демографии предполагаемых читателей. Например, IRC-канал для вопросов пользователей скорее предназначен для людей, которые раньше никогда не сталкивались с проектом - часто для тех, кто просто установил ПО и хочет немедленно получить ответ на возникший вопрос (в конце концов, если бы он мог ждать, то послал бы вопрос в список рассылки, что, возможно, в итоге отняло бы у него меньше времени, хотя ответа пришлось бы ждать дольше). Люди обычно не уделяют постоянного внимания IRC-каналу; они показываются, задают свой вопрос и исчезают.
Поэтому тема канала должна быть направлена на тех людей, которые ищут ответы на технические вопросы прямо сейчас, а не на людей, которые, скажем, вовлечены в проект на долгосрочной основе и для кого принципы взаимодействия сообщества более приемлемы. Вот как реальный нагруженный канал справляется с этим (сравните с более ранним примером в разделе «IRC / Real-Time Chat Systems» в Глава 3, Техническое обеспечение):
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 мы добились только частичного успеха от использования техники фильтрации ошибок, описанной в разделе «Pre-Filtering the Bug Tracker» в Глава 3, Техническое обеспечение. Множество сообщений о фиктивных ошибках всё ещё регистрировались неопытными пользователями, и каждый раз, когда это случалось, регистратора приходилось обучать точно так же, как 500 человек до этого. Однажды, после того, как один из наших разработчиков окончательно потерял терпение и оскорбил одного бедного пользователя, который недостаточно внимательно прочитал правила использования трекера проблем, другой разработчик решил, что этот шаблон уже достаточно "созрел". Он предложил нам переформатировать начальную страницу трекера проблем так, чтобы наиболее важная часть - предписание обсудить ошибку в списках рассылки или IRC-каналах до регистрации, было бы набрано огромными, жирными красными буквами на ярком жёлтом фоне и оставалось бы выше всего остального на странице. Мы так и сделали (вы можете видеть результат на http://subversion.tigris.org/project_issues.html), в результате доля фиктивных ошибок при регистрации заметно упала . Мы всё ещё их получаем, конечно, - так будет всегда, - но доля упала значительно, даже когда возрасло число пользователей. Польза не только в том, что база данных ошибок содержит меньше хлама, но и в том, что те, кто отвечает на регистрацию проблем, остаются в лучшем расположении духа, и с большей вероятностью останутся доброжелательными, отвечая на теперь уже редкие ошибочные регистрации. Это улучшает как имидж проекта, так и психическое здоровье его добровольцев.
Урок для нас состоял в том, что просто прописать принципы было недостаточно. Мы также должны были поместить их там, где бы их увидели те, кто в них больше всего нуждается, и подать их так, чтобы людям, незнакомым с проектом, было сразу понятно, что с ними необходимо ознакомится перед работой.
Статические web-страницы - не единственное место для рекламы обычаев проекта. Надзор (в смысле дружеского напоминания, а не в смысле в наручники-и-в тюрьму) тоже необходим. Все инспекции, даже инспекции commit'ов, описанные в «Практикуйте Открытое Рецензирование Кода» в Глава 2, Начало работы должны включать обзор соблюдения или несоблюдения человеком норм проекта, особенно в отношении соглашений о коммуникациях.
Ещё один пример из проекта 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 с именованным якорем, как описано во врезке Именованные якоря и атрибуты ID), и т.д.
Людей надо стимулировать представлять блоки информации одинаково даже тогда, когда речь идет о сущностях, для которых трудно придумать компактную форму именования. Например, при ссылке на сообщение списка рассылки, давать не только отправителя и тему, а также давать URL в архиве и Message-ID заголовка. Последний позволяет людям, имеющим свою собственную копию списка рассылки (люди иногда сохраняют offline-копии, например, для использования в ноутбуке во время путешествий), однозначно идентифицировать нужное сообщение, даже если они не имеют доступа к архивам. Только указания отправителя и темы будет не достаточно, потому что один и тот же человек может послать несколько сообщений в одну и ту же ветку, и даже в один и тот же день.
Чем больше растёт проект, тем более важным становится этот вид постоянства. Постоянство означает, что куда бы люди не посмотрели, они видят одни и те же шаблоны, которым следуют, так что они знают, что и они должны им следовать. Это, в свою очередь, уменьшает количество вопросов, которые они вынуждены задавать. Бремя иметь миллион читателей не больше, чем бремя иметь одного; проблемы масштаба начинаются только тогда, когда какой-то процент этих читателей задаёт вопросы. Поэтому с ростом проекта надо уменьшать этот процент путём повышения плотности и доступности информации так, чтобы любой отдельный человек с большей вероятностью мог найти то, что ему надо, не задавая вопросов.