Перейти к содержимому

Редакционная политика

Правила, принципы и стандарты, по которым Opensophy создаёт материалы — от структуры и стиля до авторства, обновлений и партнёрских публикаций.


Редакционная политика Opensophy

Привет! В Opensophy мы считаем, что у каждого, даже небольшого проекта, должна быть редакционная политика.

Редакционная политика (редполитика) — это свод правил, принципов и стандартов, по которым проект создаёт тексты и общается с аудиторией. Она задаёт единый голос бренда во всех каналах: от блога и соцсетей до рассылок и интерфейсов.

Статьи, написанные начиная с 28 июля 2026 года, следуют этой политике. Старые материалы, написанные до её появления, могут быть приведены в соответствие с ней — но это необязательно.

Материалы, которые публикуются в Opensophy, преимущественно образовательные, но также встречаются обзоры, мнения и кейсы. На данный момент (28 июля 2026 года) действуют следующие категории:

  1. Обзор
  2. Мнение
  3. Туториал
  4. Кейс

Прежде чем переходить к правилам по каждой категории, разберём общие требования.


Общие правила

Структура и стиль

  1. В статье обязательно должны присутствовать Введение и Заключение.

  2. Заголовки и подзаголовки не должны иметь нумерацию, за исключением пошаговых туториалов и материалов любой другой категории, где присутствует пошаговая структура (например, хронология в кейсе или мнении).

  3. Стиль — преимущественно разговорный, без перегрузки текстом.

  4. Обращение к читателю — уважительное, на «вы».

  5. Минимум 10 000 символов на статью — обязательное требование для всех категорий, без исключений.

  6. Статья пишется в формате Markdown. Исключение — публикация на сайте Opensophy или в среде с поддержкой кода/markdown-блоков: в этом случае разрешено использовать код/markdown-блоки для демонстрации.

  7. Запрещено использовать ИИ в качестве «автора» — то есть выдавать сгенерированный ИИ текст за написанный вами. Также не допускается публикация материалов, состоящих из сгенерированных изображений или диалогов с ИИ (исключение — материалы, посвящённые непосредственно ИИ). При этом разрешается использовать ИИ для поиска материала (например, официальных источников, где упоминается нужная информация) и для поиска ошибок в тексте (грамматических, орфографических).

  8. Сложные концепции — там, где это уместно — стоит сопровождать визуализацией: таблицами, схемами или диаграммами. Это не обязательное требование к каждой статье, но рекомендация для случаев, когда текстовое объяснение перегружает читателя (сравнение нескольких сущностей, архитектура, последовательность процессов).

  9. Изображения вне категории «Обзор» (иллюстрации, скриншоты, схемы) — на усмотрение автора, единых требований к оформлению нет.

  10. Англицизмы и профессиональные термины даются в русском написании с оригиналом на английском в скобках при первом упоминании. Например: именованный канал (named pipe). Это касается всех категорий, а не только туториалов — аудитория Opensophy в целом не предполагает свободного владения английским.

    Исключение — служебные и мета-термины. Слова и аббревиатуры, относящиеся к устройству самой редакции, платформы или процесса публикации (например: ИИ, апдейт, SAST, SCA, редполитика и подобные), не подпадают под это правило и могут использоваться в привычном виде без расшифровки и без оригинала в скобках при каждом упоминании. Правило 10 регулирует термины внутри публикуемых статей, адресованные читателю-новичку, а не служебную лексику самой редполитики или внутренние обозначения инструментов и процессов Opensophy.

Авторство и ревью

  1. Статьи в основном пишутся одним автором. Если авторов несколько — они указываются явно.
  2. За редакторское ревью материала перед публикацией на сайт opensophy.com отвечает Владелец Opensophy.

Источники

  1. Обязательные ссылки на источники требуются только в категории «Мнение»: любое утверждение, которое претендует на объективность (статистика, технический факт, чьи-то слова), должно сопровождаться ссылкой на независимый источник или исследование. В остальных категориях («Туториал», «Обзор», «Кейс») ссылки на источники не обязательны, но приветствуются — автор может опираться на реальный опыт и/или официальные источники по своему усмотрению.

Обновление материалов

  1. Opensophy стремится поддерживать актуальность опубликованных материалов. Если статья обновляется после публикации — в ней указывается пометка «Обновлено» с датой обновления.

Права на материал и партнёрства

  1. Если статья публикуется в рамках партнёрства (например, в блоге партнёра с указанием их бренда) — исключительные имущественные авторские права на материал могут принадлежать партнёру согласно условиям сотрудничества. При этом авторство (то, что материал написан именно вами) сохраняется за автором/Opensophy.
  2. Opensophy сотрудничает только с партнёрами, которые предоставляют право на повторную публикацию материала на других площадках после первой публикации. Партнёрство, не предполагающее права репоста, не рассматривается.
  3. Специфика для партнёрства с RUVDS: материал можно повторно опубликовать на других площадках (включая сайт Opensophy) не ранее чем через 24 часа после публикации на Хабре (или другой площадке, где идёт публикация). Для новых партнёров срок и условия повторной публикации согласовываются отдельно, но должны быть закреплены явно.
  4. Партнёры, в рамках сотрудничества с которыми публикуются материалы, указываются в разделе «О партнёрах проекта» с кратким описанием характера сотрудничества и ссылкой на партнёра (переход на главную страницу или иной согласованный редирект).

Редполитика по категориям

Туториал

Туториал пишется для всей аудитории, включая новичка. Кто такой новичок в представлении Opensophy? Новичок — читатель, который не знаком с английским языком (поскольку материал пишется преимущественно на русском), которому стоит объяснять даже самые очевидные детали, и который не обладает знаниями в IT-сфере — но должен как минимум понимать, о чём материал и зачем он.

Актуальность

  1. Тема и материал статьи должны быть:
    • актуальными;
    • написанными на основе реального опыта и/или официальных источников (документации, научных исследований и др.) — см. общий пункт 13.

Ценность времени

  1. Если материал получается объёмным — старайтесь сократить его, не теряя смысла. Пример:

    Плохо: описывать виды хранилищ Docker сплошным текстом, предложение за предложением. Хорошо: свести их в таблицу с колонками «Тип», «Кем управляется», «Где живёт», «Когда использовать».

  2. В каждом подзаголовке обязательно указывайте краткую пометку «Что это и зачем» — она поясняет, что внутри раздела и стоит ли его читать конкретному типу аудитории (например, новичку).


Мнение

Материал категории «Мнение» — самая рискованная категория с точки зрения объективности: личная позиция автора легко может быть прочитана читателем как установленный факт. Поэтому к «Мнению» применяются более строгие и детальные требования.

  1. Маркировка позиции. В начале материала (во Введении) должно быть явное указание, что читатель имеет дело с личной точкой зрения автора, а не с объективным разбором — например: «Дальше — моё личное мнение, а не претензия на истину». Далее по тексту позиция автора обозначается ещё минимум 1–2 раза в ключевых смысловых точках материала (например, при переходе к новому тезису), чтобы избежать эффекта «забытой оговорки», когда вступительная пометка теряется на фоне уверенного тона изложения.
  2. Отделение мнения от факта. Если в тексте встречается утверждение, которое претендует на объективность (статистика, технический факт, чьи-то слова), оно обязано сопровождаться ссылкой на независимый источник или исследование — см. общий пункт 13. Мнение автора и подтверждённый факт должны быть различимы по формулировке: например, «на мой взгляд» / «мне кажется» — для мнения, «по данным [источник]» — для факта.
  3. Аргументация. Позиция автора должна быть подкреплена аргументами или личным опытом, а не голым утверждением. Материал не обязан быть нейтральным, но обязан быть честным в том, что он субъективен.
  4. Альтернативная точка зрения. Если тема материала предполагает существование обоснованной противоположной позиции, желательно (но не обязательно) кратко её упомянуть — это не ослабляет материал, а показывает, что автор осознанно принял свою сторону.

Обзор

  1. Материал категории «Обзор» должен сопровождаться изображениями объекта обзора. Например, если это IT-проект с визуальным интерфейсом — обязательно нужно продемонстрировать этот интерфейс с пояснением, что где находится. Если у объекта обзора нет визуального интерфейса (библиотека, протокол, CLI-утилита и подобное) — вместо интерфейса демонстрируется код или схема использования (например, пример вызова, фрагмент конфигурации, диаграмма взаимодействия).
  2. По возможности обзор должен быть детальным: описывать характеристики и требования рассматриваемого элемента.
  3. Во введении автор обязательно должен дать личную оценку элемента и указать, для какой аудитории он создан.
  4. Рекомендуется (необязательно): если элемент представляет реальный интерес, стоит оценивать его на экспертном уровне — например, для open-source проекта разбирать стек, ограничения и безопасность с помощью инструментов автоматизации (SAST, SCA и др., в зависимости от того, что именно рассматривается).
  5. Opensophy сохраняет независимость даже в платных/спонсируемых обзорах и даёт честную оценку. Если продукт объективно плох — это будет сказано прямо, вне зависимости от того, оплачен материал или нет. Если обзор оплачен или подготовлен при поддержке партнёра — это указывается явно согласно общему пункту 19.
  6. Фактические утверждения о характеристиках, ограничениях и требованиях объекта обзора должны опираться на официальные источники или личный опыт использования — см. общий пункт 13.

Кейс

  1. К материалу категории «Кейс» применяются те же обязательства, что и к «Обзору», включая требование к источникам (общий пункт 13) и раскрытие спонсорства, если материал оплачен или подготовлен при поддержке партнёра (общий пункт 19).
  2. Оценка обязательна, включая указание недостатков решения, если они есть.
  3. Кейс обязательно должен быть реализован и использоваться на практике. При этом решение не обязано быть универсальным — оно может не подходить под чужие требования, и это нормально.
  4. Разрешается писать о кейсе, который формально не является полностью вашим, если вы участвовали в его реализации совместно с кем-то ещё.