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.
Прошу высказываться, не стесняться.
Эта система хороша тем, что будут назначены конкретные 4 человека, и каждому дано конкретное (и адекватное) количество работы. Плоха система тем, что узким местом станут верстальщики. Полноценных верстальщиков у нас сейчас двое.
Если выбирать из нынешней системы и системы предложенной, то я, конечно, за предложенную.
Но всей проблемы долгой вычитки это не решит.
Ранее был предложен вариант, описанный в этом блупринте — https:/
На мой взгляд, единственно правильный вариант — вёрстка журнала с нуля в нормальной системе. Нормальной я считаю систему, которая поддерживает полноценную командную работу. С нормальными диффами и с конфликтами, которые легко устранить.