Январь 2010

«Когда вы попросите кого-нибудь создать руководство, быть уверены, они знают, кто и что это для. Будьте уверены, что они знают, что целью является не просто точно документировать вещь, но помочь пользователю удар осла».

Кэти Сьерра

Эта статья описывает важность поддержки пользователей для успеха проектов open source и ряд предложений по укреплению вклада сообщества для открытия источника помощи пользователя. Термин «пользователь помощь» охватывает все способы, что пользователи получают помощь в выяснение того, как использовать продукт, охватывающих традиционные категории документации и поддержки. Поддержка пользователей предоставляет возможности для участия членов сообщества, которые не являются разработчиками программного обеспечения. Это, в свою очередь, снимает нагрузку на разработчиков для заполнения этих ролей при расширении сообщества. Проекты должны поддерживать различные мотивы членов в этих ролях при обеспечении руководства и направления, устранение барьеров для вклада и участия в совместных усилий. Лицензирование для открытого источника документации также должны быть открыты, для поддержки пользователей свободы и развитию сотрудничества сообщества. Лидеры в открытым исходным кодом пользователя помощи должны делиться идеями между проектами для того, чтобы улучшить свои предложения.

Важность поддержки пользователей

В осени 2009 года плохое состояние документации для Linux и open source проектов в целом стал тенденции темы в блогах и онлайн журнальных статей. Писатели с сожалением отмечали отсутствие документации пользователя необходимости, избыток разрозненных и устаревшей информации, отсутствие ответов разработчиков проблем пользователей и плохое отношение разработчиков к документации. Однако лишь немногие предлагают много на пути конструктивных консультаций, с заметным исключением Брюса Byfield статьи об источниках информации для документирования свободного программного обеспечения в Linux Magazine.

Эта статья описывает важность поддержки пользователей для успеха проектов open source и ряд предложений по укреплению вклада сообщества для открытия источника помощи пользователя.

Создание пользователей помощь имеет важное значение для открытых проектов по нескольким причинам:

  • Это помогает пользователям эффективно использовать продукт, который стимулирует принятие программного обеспечения

  • люди, которые не могут быть в состоянии внести свой вклад проекта может помочь при поддержке пользователей, которая расширяет и стимулирует сообщество вокруг проекта

  • Он может освободить разработчиков, занимающихся вопросами поддержки

  • усилия по оказанию помощи пользователей может обеспечить отфильтрованной обратную связь по областям для улучшения продукта

Поддержка пользователей это больше, чем руководства

Термин «документация», как правило, ограничить мышления традиционных руководств и, возможно, по линии помощи.

Термин «пользователь помощь» охватывает все способы, что пользователи получают помощь в выяснение того, как использовать продукт. Помощь пользователю может включать:

  • текст, встроенные в программное обеспечение, включая метки полей, заголовков окон и сообщения об ошибках (для конечных пользователей) и комментарии в коде (для разработчиков)

  • Электронная документация, доступ из приложения

  • Официальные руководства или книги

  • меньшие автономные документы, такие как инструкции, часто задаваемые вопросы, страницы руководства и учебники

  • видео уроки или демо

  • почтовый список или на форуме вопросы и ответы

  • чат с экспертами или другими пользователями

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

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

Многие роли могут способствовать

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

В то время как программисты проекта имеют углубленные технические знания продукта, они часто не лучших людей, чтобы написать помощь пользователю. Это имеет мало общего с письменными навыками и многое сделать с точки зрения. Это может быть трудно для кого-то с глубоким знанием технических деталей продукта принять перспективу тех, кто никогда не видел его раньше. Это справедливо даже для библиотек программного обеспечения, чья аудитория — другие программисты. Программист, используя библиотеки приложений интерфейс программирования (API) может отсутствовать концептуальные рамки, что «как вода для рыбы» для программиста, который написал библиотеку. Это часто более полезно для кого-то кроме оригинального программиста, чтобы написать помощь пользователю, используя оригинальный программист как «эксперт предмета» для технических деталей.

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

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

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

Сообщества и личностного роста являются мотиваторы

В отличие от программистов писателей, смотря «почесать свои собственные зуд», как правило, найти более выразительной точек, чем техническая документация, например, романы или поэзии. В почему люди пишут свободной документации? Результаты опроса, Энди ОРАМ обнаружил, что два самых рейтинговых мотивации для написания документации открытого источника были укрепления общин и личностного роста. Репутация строительство и удовольствия письма были ранжированы относительно низким, как мотивация.

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

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

Помощь пользователю требуется руководство

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

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

Для проектов, которые имеют корпоративный спонсор сообщество может ожидать спонсора для создания документации. Возникает ли это ожидание может зависеть от динамики более крупного проекта. Это более вероятно, если продукт открытым исходным кодом был создан главным образом спонсором и выпущен с открытым исходным кодом и менее вероятно, если проект превратился в первую очередь. В первом случае спонсор может финансировать развитие первичной документации, признавая вклад сообщества. Такие взносы могут быть детализированы, такие, как определенная конфигурация инструкции или темы по устранению неполадок. Или ответственность за документацию могут быть распределены между спонсором и сообщества. По словам Жан Холлис Вебер, со-организатор документации OpenOffice.org, для корпоративного спонсора проекта, Sun Microsystems, поддерживает интерактивную справку, которая доступна в пределах продукта, в то время как общинный проект создает и поддерживает руководства пользователя. Проект документирования сообщества также обрабатывает документы, направленные на программистов и системных администраторов, но Вебер сообщает, что большая часть контента способствует Sun сотрудников.

Снижение барьеров включает вклад

Участие общин в помощи пользователей возрастает, если низкие барьеры для участия. Деятельность по оказанию помощи пользователей должна быть объявлена области для участия на сайте проекта, с четко серединами обращение лидеров и открывать необходимые задачи.

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

Технология, используемая в документации усилий может стать барьером, если инструменты требуют значительной подготовки для членов общин. Исторически сложилось так многие проекты с открытым кодом используют открытые, но загадочные документации форматы, такие как LaTeX или DocBook XML, которые незнакомо не программистов. Некоторые проекты, в настоящее время обращаются менее сложных форматов. Например документация для языка программирования Python теперь написан в текста с измененной структурой, wiki как обычный текст разметки синтаксис, вместо латекса. Проект документирования Gnome начинает использовать кряквы, очень упрощенный, ориентированной на тему альтернатива DocBook.

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

Проект, который предоставляет специально построенный на основе вики платформу для открытого источника документации является FLOSS Manuals. Сайт был настроен для поддержки совместного создания всеобъемлющих текстов с WYSIWYG HTML редактор, встроенный IRC виджет и документов, структурирование инструментов. Документы могут отображаться в виде HTML или PDF и могут быть внедрены в другом веб-сайте или загружен в службу печати по требованию. Хотя текущий сайт является одноразовый, предпринимаются повторно реализовать те же функции и больше как нового открыть исходное веб-приложение под названием «Booki» для «книги вики». Проект приветствует любые усилия документации, которые обсуждаются открытым исходным кодом программного обеспечения, будь то для одного приложения или охватывающих несколько приложений.

Согласованные усилия приносят текущие результаты

Открытым исходным кодом программисты давно использовали «спринт» или «hackfests» как способ увеличить проект сбора участников для краткой, но концентрации усилий. Этот же принцип применяется к документации, а также кода. Проект FLOSS Manuals отточенные и доработать идею «спринт книги», первоначально созданные Tomas Krag для записи беспроводных сетей в развивающихся странах. Набор людей, которые заинтересованы в создании книги по конкретной теме собираются в данном месте за короткий период, обычно 2-5 дней. В конце спринта книга публикуется на сайте FLOSS Manuals. Спринт книги не является требованием для создания книги на сайте FLOSS Manuals, но опыт показывает, что книги, которые были созданы в книгах спринты имеют наибольший уровень постоянного участия.

Дэйв Гринберг является соучредителем CiviCRM проекта который участвовал в FLOSS Manuals книгу Спринт для создания книги, понимание CiviCRM, в дополнение к существующим CiviCRM документации. Он говорит «онлайн doc (на wiki) процессуально ориентированной – много как-'s, но мы получили обратную связь, что... он не предоставил специалистов по оценке и новых пользователей с большой картиной. ' Это программное обеспечение для моей организации/клиента?» «Что делать с ним?» т. д.... Мы хотели, чтобы книга, чтобы помочь директивным и консультантов, которые оценивали программные решения, чтобы иметь несколько конкретных примеров о том, кто, как и что.» Он сообщает, что CiviCRM планирует провести еще два спринта в 2010 году для обновления первой книги и писать другую концептуальную информацию для разработчиков.

В отличие от краткосрочных спринтов еще одна стратегия для согласованной документации усилий была «документации марафон» к документу NumPy API, организованной Джо Хэррингтон за лето 2008 и 2009. Участники были набраны через списки рассылки сообщества и вознаграждены с футболки для значительных уровней взносов. Эти усилия привели в 78% из категорий API, достижения цели полного содержания готовы для рассмотрения.

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

Open Source программное обеспечение нуждается в открытой документации

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

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

Хорошая поддержка пользователей достижимо

В ответ на блоги и статьи о бедных открытым исходным кодом документации комментаторы привел примеры проектов, документация которых они считают полезными, включая OpenOffice.org, GnuCash, PHP, MySQL, Gnome, Ubuntu, OpenBSD и OpenSolaris, который указывает, что эти проекты успешно помочь хотя бы некоторые пользователи «удар осла». Вопросы, касающиеся производства полезные пользователей помощи не являются уникальными для открытых проектов. Несвободные программы компании сталкиваются с ними также: помощь пользователей несвободных программ отлично, и большое количество бедных. Сотрудники компаний несвободных программ обмена передовым опытом через такие организации, как общество для технической коммуникации и Ассоциацией поддержки специалистов. Члены сообщества с открытым исходным кодом проекты могут учиться непосредственно у этих организаций, но также могут и должны делиться с и узнать о лучших друг от друга. В этом духе, Июнь 2009 года была первой в истории Конференции по письменной форме открытым исходным кодом для открытия источника документации лидеров для сбора и обмена идеями. Что Конференция завершилась веб-сайт, который способствует совместной дискуссии по темам, начиная от написания технологии и общественные здания. Помощь пользователю хороший достижимо, но требует согласованных усилий, сильное руководство и акцент на потребности пользователей, укрепляется посредством диалога и сотрудничества с группами пользователей.

 

Доля этой статьи:

Цитируете эту статью:

Оцените содержание: 
Нет голосов были поданы еще. Скажи свое слово!