35 lines
4.4 KiB
Markdown
35 lines
4.4 KiB
Markdown
# Редакционный стандарт качества
|
|
|
|
Этот стандарт применяется к каждой переработанной статье. Он нужен не для того, чтобы сделать все тексты одинаковыми, а чтобы читатель получал законченное расследование, а не яркий заголовок с короткой заметкой.
|
|
|
|
## До написания
|
|
|
|
- Выбрать конкретную проблему, наблюдаемый симптом и практический результат для читателя.
|
|
- Проверить как минимум два первичных, нормативных или официальных источника. Для исторического API отдельно назвать версионные ограничения.
|
|
- Собрать один воспроизводимый пример: код, запрос, конфигурацию, замер или диагностическую последовательность.
|
|
- Подобрать собственный визуальный материал: схема, диаграмма, скриншот с разрешением на публикацию или иллюстрация. У изображения должны быть осмысленные `alt` и подпись.
|
|
|
|
## Каркас статьи
|
|
|
|
- В первых двух абзацах назвать исходную ситуацию и цену ошибки.
|
|
- Показать механизм, а не только рецепт: что меняется, кто владеет состоянием, где проходит граница ответственности.
|
|
- Дать читателю рабочий пример и объяснить, какие значения в нём проектные.
|
|
- Добавить минимум одну таблицу: сравнение вариантов, матрицу симптомов, контракт данных или последовательность проверки.
|
|
- Добавить минимум один рисунок или диаграмму, один пример и один проверяемый источник.
|
|
- Закончить конкретным порядком действий, ограничениями и тем, что именно следует проверить в своём проекте.
|
|
|
|
## Голос автора
|
|
|
|
- Для 2017–2018 годов — практичная, тёплая заметка инженера: «давайте разберём», осторожные выводы, внимание к реальной ошибке и следующему шагу.
|
|
- Не подменять опыт общими фразами вроде «важно учитывать» или «магическая сила». Каждое обобщение должно опираться на случай, код, таблицу или источник.
|
|
- Не делать вид, что исторический автор уже знает инструменты и практики 2027 года. Поздние материалы могут становиться системнее, но развитие должно быть постепенным.
|
|
- Термины и сокращения раскрываются при первом появлении, если они не очевидны из контекста кода.
|
|
|
|
## Тройное ревью перед публикацией
|
|
|
|
1. **Факты и техника.** Сверить утверждения с источниками, проверить пример, версионные оговорки, ссылки и отсутствие ложных обещаний.
|
|
2. **Редактура и голос.** Проверить постановку проблемы, полноту раскрытия, естественность тона соответствующего года, повторы и ясность переходов.
|
|
3. **Визуал и выпуск.** Открыть изображения и диаграммы, проверить таблицы на узком экране, доступность `alt`/подписей, JSON, автоматический аудит и production-сборку.
|
|
|
|
Результат каждой ручной проверки фиксируется рядом с партией в `editorial/reviews/`.
|