В своей известной работе «Собор и Базар» Эрик Рэймонд сформулировал «закон Линуса», согласно которому при достаточном числе глаз любая ошибка всплывёт на поверхность. Поэтому одна из основных задач каждого руководителя свободного проекта заключается в том, чтобы привлечь и сохранить это самое «достаточное число глаз».
Участник проекта Mozilla Джошуа Мэттью предлагает использовать для этой цели план из пяти шагов.
Приоритет полезной информации
Потенциальный участник разработки должен как можно скорее получить все ответы на возникающие у него вопросы. Лидер должен убедиться в том, что на стартовой странице вики содержится информация о том, для чего создан проект, что полезного для него можно сделать, что планируется изменить и где оперативно получить какую-либо помощь. Подробные технические сведения лучше разместить «под ссылками».
Для более продвинутых разработчиков следует составить подробную дорожную карту — документ, в котором изложены в том числе и требования к участию в проекте. Возможно, тут не стоит придумывать ничего нового, а воспользоваться готовым шаблоном, найти который не очень трудно.
Экспертам же лучше предложить такие документы, как списки изменений, ЧаВо, примечания к выпускам и т. д. Вводная информация, рассчитанная на новичков, им не особенно интересна и не стоит заставлять их тратить на ознакомление с ней какое-то продолжительное время.
Также есть одна вещь, которую не стоит делать никогда — прямо или опосредованно отправлять новичка на баг-трекер. Это самый быстрый способ потерять участника навсегда, поскольку он вряд ли сразу разберётся в техническом жаргоне, на котором принято общаться у опытных разработчиков проекта.
Решений у этой проблемы много. Одно из них — помечать некоторые вопросы как подходящие для новичков. И, разумеется, следить за тем, чтобы они оставались такими же довольно продолжительное время.
Уменьшение трудностей
Если участие в проекте предполагает выполнение какой-то длинной инструкции по установке приложения, то это увеличивает вероятность ошибки на самой ранней стадии и только оттолкнёт разработчиков. Правильней будет написать специальный скрипт инсталляции и указать некую стандартную для проекта среду кодирования. Желающие использовать нестандартные среды должны трезво оценивать свои силы, а большинство наверняка решит пойти по простому пути.
И, конечно, следует применять автоматическую систему уведомлений. Она позволит новым участникам быстрее получать ответы на свои вопросы и работать более интенсивно.
Ясность ожиданий
Каждый участник проекта должен абсолютно точно понимать, чего именно ему следует ожидать, если он примет решение присоединиться к разработке. На какие этапы разбит проект и какие сроки назначены каждому этапу? Насколько сложные задачи ему предстоит решать? Ответы на эти вопросы следует разместить в документации.
Второй немаловажный фактор — принятые в проекте нормы поведения. Тут тоже не должно быть никаких сюрпризов. Если лидер затрудняется составить некий кодекс поведения, то лучше воспользоваться готовыми примерами и шаблонами.
Минимизация простоев
Лидеру проекта следует убедиться в том, что время, необходимое на осуществление обратной связи, сведено к минимуму. Начинающий участник всегда испытывает дискомфорт, если слишком долго не получает ответа на свой вопрос.
Также необходимо объяснить опытным разработчикам, что в ответах новичкам необходимо избегать слов «просто», «легко», «очевидно» и т. п. Простое для них может оказаться сложным для других, что вовсе не умаляет стараний людей, пока ещё не имеющих высокой квалификации. Все когда-то с чего-то начинали — ветеранам нужно помнить эту истину.
Приём участников
Всегда следует публично признавать новых участников. Метод тут не важен — это может быть сообщение в рассылку, объявление на IRC, добавление в список проектной документации... Подобная мера поощряет разработчиков остаться в команде. Лидеру нельзя забывать, что релиз-менеджеры и майнтейнеры когда-то тоже были новичками.
Важно делать это с самого начала цикла, даже если подобные действия требуют времени. Если установить хорошие правила в небольшой группе, то они будут сохраняться, когда число участников заметно вырастет.
