Re: [gentoo-doc-ru] Трудности перевода, наша дизорганзация и инфраструктура

[Peter Volkov]

К сожалению убедить всех в команде gentoo.ru отвечать в этот список

рассылки мне не удалось, но я получил разрешение пересылать ответы сюда,

сохраняя всё цитирование. Это мой ответ Антону, на его ответ мне.



==========================================================================





В Пнд, 04/02/2008 в 09:45 +0300, Chaplygin Anton пишет:

> > Друзья, это обещанная во время митинга затравка для обсуждения проблем
> > перевода. Так как я уверен, что обсуждение будет интересно всем, в том
> > числе потенциальным переводчикам, прошу отвечать в gentoo-doc-ru, куда
> > это же письмо было отправлено минуту назад. Спасибо.
>
>
> --1--
> Ох, слишком много букаф. Асилил с трудом и то со второго раза.


Ух. А первый абзац осилить видимо вообще не получилось. :(

Придётся мне форвардить ибо не хочу терять историю. Я её иногда

просматриваю...



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


Антон, я овлёк тебя от перевода? Хм, не уверен, и когда перевод в

очередной раз зачах, мне думается стоит оглянуться и попробовать понять

почему это произошло. Это поможет избежать этих проблем в будующем...



> Не стоит забывать, что все мы - люди, а не машины, и способны
> воспринимать информвцию только сравнительно небольшими квантами,


Квант это сколько строчек? Сколько раз мне надо будет написать, чтобы

освятить всё то, что я написал? В конце концов, если нет времени

прочитать несколько страниц текста, то не удивительно, что мы ещё ничего

не сделали. Очевидно что, процесс работы не всегда только fun и нужны

усилия. Было бы желание осилить всё можно.



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


Вопрос, а сколько из существующих ссылок в конце письма ты открыл?



> Не стоит обязывать
> переводчиков читать мануал полностью, не не удивляться, если они не
> будут этого делать.


Где я писал про обязывание переводчиков?



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


Этого никто не отменял.



> То же самое касается и писем!
>
> Я понимаю стремление руководителей и координаторов по возможности
> максимально формализовать процесс, сделать его логичным и исключить
> возможность ошибиться. Но в проектах с нематериальной мотивацией, тем
> более, если команда географически распределенная, эта склонность
> может сильно навредить, потому что не у всех есть лишний час времени
> на чтение пространных руководств о том, как надо помогать проекту.


Где я писал про пространные руководства? То есть стоит обязывать

редакторов раз по сто писать одно и тоже, чем один раз написать как что

делать и направлять переводчиков туда читать? Пример из жизни: у вас в

рассылке лежит несколько неотвеченных писем потенциальных переводчиков.

Им даже не послали ссылку :(



> Мы должны быть благодарны даже за одну строку переведенного текста,


Зависит от того, это перевод или ручной аналог prompt'а.



>  даже
> если этот перевод сделан не совсем в соответствии с требуемым стилем.


Я писал, что за стиль отвечает (если хочет) редактор, но не переводчик.

Опять не понимаю, к чему это написано...



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




> --2--
> Не понимаю, зачем отгораживать переводчиков от SVN-репозитория


Зачем знать svn переводчику? Разве знание svn помогает переводить? Мне

писали переводчики, которые вообще не слышали такого слова. Значит мы

хотим, чтобы переводчики не читали документ о том, как переводить, но

разобрались с svn? На что лучше направить усилия переводчиков?



> создавать ненужный шаг в цикле - для SVN'а есть куча неплохих
> клиентов с GUI и без, с которыми справится любой человек с головой.
> Для того, чтобы отслеживать, кто чем занимается, можно использовать
> одну из 2 схем:
> 1. Папки draft, translated и т.п. можно создать прямо в репозитории.
> Переводчик делает checkout, потом средствами SVN переносит файл в
> папку соответствующего статуса и делает commit.


Ок. Но опять же изучать svn? И кто будет писать к нему хуки, что бы не

было одного и того же файла в двух папочках одновременно? Но, наверное,

это можно сделать. Я поэкспериментирую.



> 2. Договариваемся, что начиная работу над переводом переводчик просто
> изменяет статус тикета в системе Trac на "assigned". Для того, чтобы
> псмотреть, кто чем занимается, достаточно будет посмотреть на
> стандартный отчет {9} (вот пример: http://trac.edgewall.org/report/


То есть, кроме работы над переводом мы заставляем ещё открыть браузер и

изменить статус (см. ниже(*))?



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


Хм, похоже действительно осилить несколько страниц текста это ад... Я

там упоминал скрипт, который написать легко и он будет составлять

отчёты, чтобы не считать пальцем...



> - это большой плюс, который, imho, покрывает все минусы.


Тикеты создать возможно: сначала для приоритетных документов, потом для

остальных.



(*) Но ты не понял главной проблемы! Нам нужно видеть не что уже

переведено, а что в процессе перевода. Редко кто писал в рассылку письмо

о том, что взял то-то или то-то на перевод, так почему ты думаешь, что

кто-то будет в траке менять статус? Когда я говорил про связь svn и

$issue_tracker я понимал, что коммитом, я смогу закрывать/менять

состояние тикета. Это можно сделать в trak? Я не нашёл и поэтому ищу

другой путь.



> Мне второй вариант видится более простым для всех. Посмотрел я
> Mantisbt (я им не пользовался, но о нем слышал), но скажу честно, что
> меня он совсем не впечатлил. Если есть желание посмотрите на систему
> http://unfuddle.com -  это коммерческий аналог системы Trac, но
> большинство функций (например, контроль времени на закрытие тикетов,
> иерархическое связываение тикетов и т.п.) доступно и в Trac'е, если
> повозиться с хаками и модулями. Лучшей в смысле удобства системы я
> пока не видел - даже аккаунт там купил.


Ок. Если мы начинаем обсуждать багзилы, то первое, что нужно решить это

возможно ли не открывать браузер всякий раз, когда я закоммитил, изменил

что-нибудь? Как? (опять же см. выше (*))



> --3--
> В очередной (не помню уже какой по счету) раз озвучу схему работы с
> резпозиториями, которую я предлагаю.


Схема не единственная проблема. Эта схема упирается в технические

проблемы и именно поэтому моё письмо получилось длинным.



> В данной схеме выделяется 3 основных цикла:
> 1. Цикл подготовки подстрочных переводов. Участвуют все желающие,
> имеющие доступ к репзиторию (Community Translators или CT).
> Повторяется пока кто-нибудь из переводчиков, стоящих на втором
> уровне, не возьмет подстрочник в работу.


Как говорил Азамат, и я с ним согласен: "отсутствие видимого результата

- главный дестимулирующий фактор." Поэтому думаю повторение циклов

подстрочников быстро остановиться. Другое подтверждение этому факту сайт

it.kondopoga.ru.



> 2. Во втором цикле участвует переводчик (Translator) и один из
> ответственных за качество и стилистику (назову эту группу QA -
> Quality Assurance). QA может отправлять текст переводчику на
> доработку, скажем, до 5 раз (через svn-репозиторий, делая пометки и
> замечания в соответствующем тикете). После того, как перевод принят,
> он поступает к координатору (Coordinator - C).
> 3. 3-й цикл охватывает весь процесс, и за него отвечает координатор.
> Данный цикл состоит из коммитов переводов в официальный репозиторий
> Gentoo.org, выкладывания в наш репозиторий новых и обновленых
> англоязычных текстов для работы CT и создания тикетов.


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



> Таким образом у нас получается 4 уровня ответственности (каждый тикет
> проходит через все 4 уровня):
> 1. На самом верху стоит координатор проекта переводов на русский
> язык, на котором лежит весь груз ответственности. В его обязанности
> входит общение с руководством межунароной команды переводов, решение
> нестандартных проблем, работа с QA (ибо они - его щит и опора).
> 2. QA - команда из 2-3 человек, которая отвечает за качество
> переводов. Они же будут заниматься составлением и актуализацией
> словарей терминов, FAQ' а и контроллировать процесс.
> 3. Переводчики - занимаются переводами текстов в полном объеме, на
> основе подстрочников, подготовленных CT. Взаимодействуют с QA.
> 4. CT - молодняк и неофиты,


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

будет приятно слышать про себя такое от умудрённого гуру...



>  которые занимаются подстрочниками, учатся
> работать с SVN (если не умеют) и т.п.


Антон. Подстрочник не нужен ибо править подстрочник сложно. Правя

handbook и GWN'ы я много раз ловил себя на том, что удалить абзац

перевода и перевести заново значительно проще, чем пользоваться

переводом. Да это даже был не подстрочник. А вот яркий пример

подстрочников это сайт Banderazzz'а. Ну что делать с теми кусками

текста? Очевидно, заново переделывать.



> Систему продвижения вверх по лестнице уровней ответственностей,
> думаю, стоит построить на основе рекомендаций. Например, координатор
> чувствует, что QA-группа не справляется, и если для решения проблемы
> нужны кадры, то он просит у QA порекомендовать кого-нибудь из
> переводчиков (1-2 кандидатуры, скажем). Естественно, для QA клавным
> критерием будет то, насколько просто было с переводчиком работать:
> если переводчик присылал почти идеальные тексты, то у его шансы
> сильно возрастают. Решение о переводе в QA принимает координатор.
> Аналогично с переводчиками: переводчики рекомендуют QA особо
> отличившихся из CT (тех, чей подстрочник был максимально точен и
> близок к готовому переводу). Решение о изменении статуса CT->T
> приниают QA коллегиально. Кто-то из них становится супервайзером
> нового переводчика (т.е. с ним работает только он) и по истечении
> определенного срока, отчитывается перед остальными QA, можно ли этому
> переводчику доверять или, иными словами, прошел ли он испытательный
> срок.


Пока нас мало и кого продвигать будет видно.



> Такой подход позволит:
> 1. сделать систему продвижения понятной и прозрачной для всех - это
> большой плюс к мотивации:
> 2. четко распределить зоны ответственности и избежать самодурства;
> 2. все кадровые решения будут приниматься на основе оценки полезности
> человека: от кого много проблем, продвигаться не сможет, а те, кто
> проблемы помогает решать или хотя бы их не создает, будет
> продвигаться быстро.
>
> Если есть вопросы, то готов на них ответить.


Да, и много. Выше по тексту :)



Peter.