Процесс завершающей вычитки журнала.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
FCM RU |
Fix Released
|
Low
|
Unassigned |
Bug Description
25 выпуск делался долго. Одной из главных причин, как мне кажется, был этап заключительной вычитки журнала. На мой взгляд, основная проблема в том, что нет технической возможности править тексты одновременно и загружать свои поправки, за что огромное спасибо системе Scribus.
Проблема была в том, что люди вычитывали журнал одновременно, и соответственно находили ошибки в одних и тех же местах. Кто-то отписывался о найденных ошибках, а кто-то ещё и тратил время на чтение этих отчетов в поиске, не была ли указана там его правка и стоит ли её писать.
Главная моя идея в процессе вычитки - не пересекаться.
Пример, есть сверстанный журнал и он ждёт вычитки. В нём около 36 страниц. Кол-во страниц особой роли не играет. В этом случае нужно назначать 3-4 человек для вычитки.
Итак процесс.
1. Эти 3-4 человека делят журнал на соответствующее кол-во страниц. Пусть будет 4 человека. Тогда каждому из них достанется по 9 страниц.
2. Каждый из 4-х вычитывает только свой кусок: 1-й вычитывает с 1 по 9, 2-й с 10 по 18, 3-й с 19 по 27, 4-й с 28 по 36.
3. Каждый пишет в соответствующем баге то, что нужно поправить.
4. Верстальщики вносят изменения. Выпускают новый PDF.
5. Каждый их 4 вычитывает следующий кусок: 1-й с 10 по 18, 2-й с 19 по 27, 3-й с 28 по 36, 4-й с 1 по 39.
6. Повторяем пункт 3 и 4.
Таким образом, каждая страница журнала будет вычитана по два раза совершенно разными людьми.
Возможно, пункты вместо 3 и 4 пунктов редактор сам сможет сказать исходник, поправить его, а потом залить изменения на сервер. Но это ещё надо обсудить. Кажется. что как раз на с этим и проблемы возникают при работе в Scribus.
Прошу высказываться, не стесняться.
Changed in fcm-ru: | |
importance: | Undecided → Medium |
status: | New → In Progress |
tags: | added: proofreading system |
Changed in fcm-ru: | |
importance: | Medium → High |
Changed in fcm-ru: | |
status: | In Progress → Fix Released |
importance: | High → Low |
Эта система хороша тем, что будут назначены конкретные 4 человека, и каждому дано конкретное (и адекватное) количество работы. Плоха система тем, что узким местом станут верстальщики. Полноценных верстальщиков у нас сейчас двое.
Если выбирать из нынешней системы и системы предложенной, то я, конечно, за предложенную.
Но всей проблемы долгой вычитки это не решит.
Ранее был предложен вариант, описанный в этом блупринте — https:/ /blueprints. edge.launchpad. net/fcm- ru/+spec/ scribus- simplifier. Вариант хороший, но потребуются люди, который будут это писать. Сейчас «упрощатель» работает неправильно. И, как сказано в блупринте, вёрстка всё равно поедет.
На мой взгляд, единственно правильный вариант — вёрстка журнала с нуля в нормальной системе. Нормальной я считаю систему, которая поддерживает полноценную командную работу. С нормальными диффами и с конфликтами, которые легко устранить.