Редакционная модель проекта
В предыдущем уроке мы связали материал PUB-01 с задачей читателя. Теперь нужно сделать так, чтобы это решение сохранялось, когда статьи готовят разные люди. Редакционная модель описывает, какие материалы выпускает проект, кто принимает решения и какое состояние позволяет передать текст дальше. Она нужна даже маленькому сайту, где один человек совмещает несколько ролей.
Продолжим локальную редакцию ProfessorWeb. В папке lesson-02 учебного архива начальное состояние буквально повторяет результат первого урока. Имена ролей и сроки вымышлены. Мы проектируем процесс, не сообщаем о найме авторов или запуске реальной редакции.
Рубрика и формат
Рубрика отвечает на вопрос о предмете материала. Формат отвечает на вопрос о способе объяснения. «Разработка статических сайтов» может включать последовательный урок, разбор ошибки и справочную таблицу. Если назвать рубрику «полезные советы», авторы будут объединять несвязанные темы, а читатель не поймёт, какое продолжение ему доступно. Для учебной библиотеки важна возможность двигаться от понятия к практическому действию.
Выделим три редакционные линии: «Урок», «Разбор затруднения» и «Обновление материала». Первая развивает последовательный пример. Вторая объясняет одну конкретную ошибку и способ различить её причины. Третья меняет существующую страницу, когда её предпосылки устарели. Это внутренняя модель работы, а не требование создать три новых раздела сайта. Публичная рубрикация остаётся связанной с предметом урока.
| Линия | Вход | Готовый результат | Решение о выпуске |
|---|---|---|---|
| Урок | Учебная задача | Объяснение и ожидаемый результат | Редактор |
| Разбор | Конкретное затруднение | Причина и вариант исправления | Редактор с экспертом |
| Обновление | Подтверждённое изменение | Новая редакция прежней страницы | Ответственный за серию |
Для PUB-01 выбираем линию «Урок». Если позднее появится вопрос о неожиданном 404, его нельзя автоматически дописать в середину вводной статьи. Сначала выясним, дополняет ли он её основной результат. Если нужна отдельная диагностика маршрутов, создадим карточку разбора с явной связью. Такая операция сохраняет цель урока и позволяет расширять библиотеку без повторения одних абзацев.
Роли и право решения
Введём учебные роли: автор Лена, технический рецензент Максим и редактор Ольга. Это имена участников примера, не сведения о команде ProfessorWeb. Лена готовит объяснение. Максим отмечает технические утверждения, которые требуют первичного источника или проверки. Ольга сопоставляет текст с задачей, рубрикой и предыдущими уроками. Один человек может выполнять все три роли последовательно, но результаты этих действий всё равно различаются.
Технический рецензент не должен незаметно менять обещание статьи. Например, он предлагает дополнить PUB-01 настройкой серверных правил. Предложение может быть правильным, но расширяет результат. Редактор решает, добавить ли небольшой вариант, перенести его в следующий урок или изменить задание. Без этого решения статья постепенно превращается в набор полезных, но несвязанных замечаний.
У каждого материала появляется один ответственный за следующее действие. При состоянии «нужна правка» это автор. При состоянии «техническая сверка» — рецензент. При состоянии «решение о выпуске» — редактор. Поле ответственного не означает единоличного владения текстом: оно устраняет ситуацию, когда все считают, что следующий шаг выполнит кто-то другой. Дата передачи нужна для наблюдения процесса, а не для фиктивной отчётности.
Состояния нашей модели: idea, brief, draft, review, ready_local. Последнее означает только готовый локальный материал. Публикация представляет отдельное действие и отдельное разрешение. В примере нет состояния published, потому что внешние страницы и сообщения мы не размещаем. Даже хорошо оформленный Markdown-файл остаётся черновиком, пока процесс публикации не выполнен.
Критерий перехода
Переход из brief в draft требует результата, предпосылок и границ темы. Переход в review требует полного текста, приложений и списка непроверенных частей. Переход в ready_local требует снятых существенных замечаний. Это проектные критерии редакции. Их не следует выдавать за общий стандарт качества для всех сайтов: новость и подробный технический курс устроены по-разному.
Рассмотрим возврат. Максим замечает, что в примере обещано сохранение URL, но нигде не показан прежний путь. Он записывает замечание к конкретному абзацу и возвращает материал в draft. Автор добавляет путь и объясняет, как он связан с метаданными. История возврата сохраняется. Иначе редакция увидит только текущий статус и не сможет понять, почему подготовка заняла больше времени.
Не вводите десятки состояний ради точности интерфейса. «Проверка запятых», «проверка ссылок», «ожидание изображения» могут быть подзадачами одной рецензии. Отдельное состояние оправдано, если меняется ответственный, допустимое действие или критерий готовности. В нашей маленькой редакции пяти состояний достаточно, чтобы передавать материал и видеть блокировку.
Файл artifact.md содержит матрицу ролей и переходов. В after.json добавлены редакционные линии и карточка PUB-01 со статусом brief. Роль аудитории из первого урока сохранена. Ожидаемый результат чтения двух файлов — возможность объяснить, кто и на каком основании передаёт статью автору. Никакие письма Лене или Максиму не отправляются; это локальные персонажи модели.
Для небольшого проекта полезен ещё один журнал — запись решения о спорном изменении. Предположим, автор хочет добавить в PUB-01 пример поиска по сайту. Рецензент замечает, что поиск требует отдельной клиентской или серверной логики. Ольга фиксирует решение: сохранить в текущем уроке обычную страницу, а поиск предложить отдельной темой. В журнале есть вопрос, выбранный вариант и причина; оценка личности автора отсутствует. При следующем расширении серии команда увидит, почему тема была отложена, и сможет пересмотреть решение при новых условиях. Запись не обязана быть длинной: достаточно восстановить ход предметного выбора. Если один человек совмещает роли, он может вести тот же журнал. Пауза между написанием и редактурой помогает увидеть пропущенную предпосылку, а явное решение не позволяет считать любое новое предложение автоматически принятым.
Проверьте модель на изменённом условии: рецензент недоступен в неделю подготовки. Правильный ответ не состоит в автоматическом присвоении ready_local. Редактор либо меняет срок, либо передаёт рецензию другому квалифицированному участнику, либо сужает материал до уже подтверждённых утверждений. Решение записывается вместе с причиной. Следующий урок добавит реестр существующего контента, чтобы работа начиналась с пробела библиотеки, а не только с новой идеи.