Совместная разработка текстов: как преодолеть смешение языцей?

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

«Классическая» схема подготовки документации

• 8 томов в стиле UNIX
• Выпуск готовой документации вместе с выпуском продукта
• Выделенные профессии: технический писатель, редактор и пр.

Эта схема не подходит для Linux-сообщества:

• Большой объём работы, которую не очень нужно делать
• Слишком много основано только на материальной заинтересованности

Следствие: тяжело привлечь к работе сообщество

Аналогия: октрытая разработка программ?

Если попытаться организовать сообщество по тем же принципам, что и свободное сообщество разработчиков, какие будут различия?

Мотивация

• Нет непосредственной отдачи от работы (программа работает, текст — нет), неочевиден «fun»
• Неочевидно «повышение квалификации»

• Работа на сообщество ради внедрения дома / на службе — только в виде методички, большие книги часто хотят продавать

• Дополнительная мотивация: просветительская

Следствие: мотивированных людей намного меньше, чем в программистском сообществе

Технология

• Намного больше «прямого» написания текста, чем отладки, исправления, втягивания новых версий и пр.

• Обновление версий и перевод: «moving target», метод diff–patch не работает

• Поиск ошибок: ошибки не находятся сами, зато их может найти кто угодно
• Намного менее чёткое разделение на upstream и maintainer, часто роли совмещены
• Выходные форматы строго обусловлены: HTML, man, info, !LaTeX и т. д., в зависимости от задачи, нет выбора
• Множественность входных форматов: у каждого автора — свой

Следствие: процесс практически не автоматизирован. Максимальная степень автоматизации — wiki-подобные системы. Вариант: вручную силами наёмного технического писатела (a.k.a «робот-секретарша», контентщик). Узкое место всего процесса документооборота. Каждый сеанс «публичная правка»–«авторская правка»–«публикация» требует участия контентщика.

Куча ALT Docs Team

Куча — попытка построить сообщество документописателей по принципам свободного сообщесва. Развивается небыстро.

• Свобода входа:
  • Простота подключения к процессу

  • Приём текстов в любом формате (если из него можно сделать HTML или latex — прекрасно, если нет — можно написать HTNL-«паспорт» с пояснениями, чем читать)

• Средства совместной разработки: wiki; планируется git (с помощью http://git.altlinux.org)

• Публикатор (если можно сконвертировать в HTML); планируется публикация для вычитки с более простой обратной связью, чем bugzilla
• Классификатор по паспортам документа; планируется поисковая система и динамический классификатор

• Автоматическая сборка пакета документации в Сизиф

Проект «Вавилон»

Проект Вавилон — попытка построить систему обработки текстов, имеющую много и входных, и выходных форматов.

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

• Все документы преобразуются к универсальному формату хранения

• Допустимый набор средств разметки и их интерпретация задаются т. н. схемой

• Желательно соответствие средств разметки разных входных и выходных форматов в рамках одной схемы
• Диалекты входных форматов перед преобразованием унифицируются

Цели:

• Организовать цепочку «произвольный входной формат»–«произвольный выходной формат» (внутри одной схемы)
• Автоматизировать цикл «публичная правка»–«авторская правка»–«публикация» и оторвать его от единого формата разметки