Редакционный стандарт качества

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

До написания

Выбрать конкретную проблему, наблюдаемый симптом и практический результат для читателя.
Проверить как минимум два первичных, нормативных или официальных источника. Для исторического API отдельно назвать версионные ограничения.
Собрать один воспроизводимый пример: код, запрос, конфигурацию, замер или диагностическую последовательность.
Подобрать собственный визуальный материал: схема, диаграмма, скриншот с разрешением на публикацию или иллюстрация. У изображения должны быть осмысленные alt и подпись.

Каркас статьи

В первых двух абзацах назвать исходную ситуацию и цену ошибки.
Показать механизм, а не только рецепт: что меняется, кто владеет состоянием, где проходит граница ответственности.
Дать читателю рабочий пример и объяснить, какие значения в нём проектные.
Добавить минимум одну таблицу: сравнение вариантов, матрицу симптомов, контракт данных или последовательность проверки.
Добавить минимум один рисунок или диаграмму, один пример и один проверяемый источник.
Закончить конкретным порядком действий, ограничениями и тем, что именно следует проверить в своём проекте.

Объём и плотность

Основной текст статьи, без HTML-разметки, заголовка, метаданных и списка источников, занимает от 5 000 до 15 000 знаков.
Нижняя граница — не повод искусственно растягивать выводы. Если тема проста, глубину создают контекст, контрпример, проверка и решение, а не повтор одной мысли.
Верхняя граница — повод разбить слишком широкую тему на серию. Одна статья отвечает на один главный вопрос.
Каждый абзац либо добавляет факт, решение, ограничение или следующий шаг. Вступления «вообще о важности темы» и эмоциональные связки без технического смысла вырезаются.

Техническая речь

Базовый стиль — прагматичная краткая техническая речь. Она следует уровню автора в конкретном году: ранний автор объясняет через собственную задачу, поздний — через измеримый компромисс и воспроизводимый процесс.
Пишем коротко и предметно: симптом → причина → проверка → действие. Предпочитаем глаголы и наблюдаемые факты: «запрос вернул 403», «фильтр исключает запись», «метрика выросла на 18%».
Один абзац — одна мысль; одно предложение не пытается одновременно описать проблему, историю команды и решение.
Термин используется только там, где он точнее обычного слова. После первого появления даём расшифровку или пример.
Не используем общие оценки: «в современном мире», «очень важно», «магическая сила», «просто нужно учитывать». Вместо них называем условие, риск или ограничение.
Заголовок обещает ровно тот вопрос, на который отвечает текст. Результат не объявляется «универсальным», если он зависит от версии, нагрузки, прав или архитектуры проекта.

Голос автора

Для 2017–2018 годов — практичная, тёплая заметка инженера: «давайте разберём», осторожные выводы, внимание к реальной ошибке и следующему шагу.
Для 2019–2021 годов — инженер развивает T-shape: от PHP и Bitrix к фронтенду, инфраструктуре и данным. Текст всё ещё говорит от первого лица, но уже связывает решение с границами системы.
Для 2022–2024 годов — системный практик: появляются измерения, надёжность, безопасность, доставка и взаимодействие ролей. Утверждения становятся проверяемее, а выводы — спокойнее.
Для 2025–2027 годов — наставник и техлид: автор сравнивает варианты, называет стоимость решения, объясняет компромиссы и оставляет команде воспроизводимый способ работы.
Не подменять опыт общими фразами вроде «важно учитывать» или «магическая сила». Каждое обобщение должно опираться на случай, код, таблицу или источник.
Не делать вид, что исторический автор уже знает инструменты и практики 2027 года. Поздние материалы могут становиться системнее, но развитие должно быть постепенным.
Термины и сокращения раскрываются при первом появлении, если они не очевидны из контекста кода.
Полная временная карта, словарь, переходы навыков и анти-анахронизмы находятся в editorial/voice/author-trajectory-2017-2027.md; она обязательна для редакторского прохода.

Тройное ревью перед публикацией

Факты и техника. Сверить утверждения с источниками, проверить пример, версионные оговорки, ссылки и отсутствие ложных обещаний.
Редактура и голос. Проверить постановку проблемы, объём 5–15 тыс. знаков, плотность, прагматичность речи, естественность тона соответствующего года, повторы и ясность переходов.
Визуал и выпуск. Открыть изображения и диаграммы, проверить таблицы на узком экране, доступность alt/подписей, JSON, автоматический аудит и production-сборку.

Результат каждой ручной проверки фиксируется рядом с партией в editorial/reviews/.

8.5 KiB Raw Blame History