Ця сторінка описує, як ми створюємо, редагуємо та підтримуємо актуальними матеріали на solana.org.ua. Тут немає загальних фраз — лише конкретні правила, за якими працює редакція незалежного українського хабу.
Принципи підготовки матеріалів
Вимоги до структури та стилю
Кожен матеріал на сайті відповідає трьом структурним вимогам:
- Чіткий фокус. Одна стаття — одна тема. Наприклад, стаття про PDA (Program Derived Address — похідні адреси програм у Solana) не повинна перетворюватися на загальний посібник із розробки смарт-контрактів.
- Логічна послідовність. Ми йдемо від контексту до деталей, а не навпаки. Читач має зрозуміти, про що йдеться, до того як зіткнеться з технічними специфікаціями.
- Практична цінність. Якщо розділ можна вилучити без втрати змісту — він не потрапляє на сайт. Типова помилка, яку ми уникаємо: абзац про історію блокчейну в статті, де читачу потрібна інструкція налаштування RPC-вузла.
Стиль — професійний, але не академічний. Ми пишемо так, як пояснили б колезі, який розуміє основи, але не є спеціалістом у конкретному питанні.
Мовні стандарти та Tone of Voice
Усі матеріали публікуються українською мовою. Дотримуємося таких правил:
- Професійна термінологія залишається незмінною. Solana, SOL, Rust, Anchor, RPC, PDA, CPI, MEV, RWA, API — ці терміни не перекладаються штучно. При першому вживанні в матеріалі такий термін супроводжується коротким поясненням українською мовою, якщо це доречно для рівня складності статті.
- Жодних русизмів і кальок. Замість «в рамках» — «у межах», замість «отже» — «отже» або «зрештою», замість «насамперед» — « насамперед».
- Пряма мова. Ми уникаємо пасивних конструкцій там, де доречний активний стан. Не «було розглянуто», а «ми розглянули» або «редакція розглянула».
Процес редагування та затвердження
Жоден матеріал не потрапляє на сайт без проходження трьох етапів:
- Первинна підготовка. Автор створює чернетку за затвердженим планом. План містить мету статті, цільову аудиторію та перелік ключових питань, на які треба відповісти.
- Редакційна правка. Редактор перевіряє структуру, логіку, стиль і відповідність мовним стандартам. На цьому етапі можуть видалитися цілі розділи, якщо вони розмивають фокус матеріалу.
- Фактична перевірка. Технічні твердження, фрагменти коду, посилання на документацію та специфічні параметри перевіряються окремо. Як цей процес влаштований детально — описано на сторінці Політика перевірки фактів.
Для технічних матеріалів (інструкції з розробки, налаштування середовищ, робота з Anchor) перед публікацією обовʼязкове тестування описаних кроків. Якщо в інструкції йдеться про створення PDA за допомогою CPI (Cross-Program Invocation — міжпрограмні виклики в Solana), редакція перевіряє, чи описаний процес дійсно призводить до очікуваного результату у вказаному середовищі.
Маркування статусу матеріалів
Позначки актуальності та дати перевірки
Екосистема Solana змінюється швидко. Щоб читач розумів, наскільки свіжий матеріал, ми використовуємо такі позначки:
- Дата останньої перевірки. Вказується в кінці статті. Це означає, що в зазначену дату редакція підтвердила: технічні кроки працюють, терміни використовуються коректно, жодних суттєвих змін у темі не сталося.
- Позначка «Застарілий матеріал». Зʼявляється, якщо після планової перевірки виявлено, що частина інформації більше не відповідає дійсності, але стаття зберігається як історичний довідник. У такому разі на початку матеріалу розміщується чітке попередження з описом того, що саме застаріло.
Якщо ви бачите матеріал без дати перевірки або з датою старішою за шість місяців — це сигнал перевірити ключові твердження за первинними джерелами перед використанням.
Позначки рівня складності
Кожен матеріал має одну з трьох позначок:
| Позначка | Що означає | Для кого |
|---|---|---|
| Початковий рівень | Не вимагає попередніх знань про Solana. Базові терміни пояснюються в тексті. | Новачки, які тільки знайомляться з екосистемою. |
| Середній рівень | Вимагає розуміння базових концепцій блокчейну та загальної архітектури Solana. | Розробники з досвідом в інших мережах, інтегратори, технічні менеджери. |
| Просунутий рівень | Передбачає практичний досвід розробки на Rust та/або Anchor, розуміння моделі обліку Solana. | Розробники смарт-контрактів, архітектори, дослідники безпеки. |
Позначка рівня стоїть на початку статті. Якщо матеріал містить розділи різної складності, це окремо зазначається в анотації.
Відповідальність редакції
Редакція solana.org.ua несе відповідальність за таке:
- Якісну підготовку матеріалів. Ми гарантуємо, що кожна опублікована стаття пройшла описаний вище процес редагування та перевірки.
- Чітке маркування. Статус матеріалу, рівень складності, дата перевірки — ці дані завжди доступні читачу.
- Коректність мовлення. Ми дотримуємося літературної української мови та не допускаємо російськомовних конструкцій.
- Незалежність позицій. Про статус хабу детально розказано на сторінці Про незалежний український хаб Solana. Тут наголосимо: ми не є офіційним представництвом Solana Foundation, не говоримо від її імені та не маємо документально підтверджених повноважень представляти інтереси цієї організації.
Редакція не несе відповідальності за:
- Зміни в екосистемі Solana, які сталися після дати останньої перевірки матеріалу.
- Рішення, прийняті читачами на основі опублікованої інформації — зокрема фінансові, інвестиційні чи юридичні.
- Коректність роботи сторонніх інструментів, сервісів та проєктів, які згадуються в матеріалах як приклади.
Якщо ви знайшли неточність, застарілу інформацію або мовну помилку — повідомте редакцію через контакти, вказані на сайті. Ми фіксуємо такі звернення, перевіряємо та оновлюємо матеріал із вказанням нової дати перевірки.