Фичеринг статей

[pepelsbey]

Хочется сделать удобный фичеринг статей, который сначала можно будет менять руками, а когда накопится коллекция статей, готовых для фичеринга, делать ротацию автоматически.

Хранить теги не в статьях, а в отдельных файлах кажется удобнее — единая точка входа, понятно как менять порядок.

Фаза первая

Создаём файл featured.md в контенте:

---
pinned:
  - css/box-model
  - css/display
  - css/grid-guide
  - html/div
  - html/doctype
  - html/head
  - js/clean-architecture
  - js/closures
  - js/execution-order
  - tools/ci-cd
  - tools/docker
  - tools/webpack
---

В нём перечисляем все готовые статьи для фичеринга в формате раздел/статья.

В нём же меняем порядок, чтобы фичеринг был не алфавитный, а справедливо-случайный:

---
pinned:
  - css/box-model
  - tools/docker
  - html/div
  - html/doctype
  - css/display
  - tools/webpack
  - js/clean-architecture
  - html/head
  - js/closures
  - tools/ci-cd
  - js/execution-order
  - css/grid-guide
---

Фаза вторая

В этой фазе у нас есть список статей, готовых для фичеринга (ready) и список статей, которые мы хотим зафорсить первыми в списке (pinned). Теперь в файле featured.md у нас будет два списка:

---
pinned:
  - html/doctype
  - css/grid-guide
  - js/execution-order
  - tools/ci-cd
ready:
  - html/div
  - html/head
  - css/box-model
  - css/display
  - js/clean-architecture
  - js/closures
  - tools/docker
  - tools/webpack
---

По ним раз в неделю (две недели?) скрипт в случайном (или другом) порядке выбирает статьи и фичерит.

Статьи из ключа pinned становятся первыми именно в таком порядке. Все остальные статьи из ready выбираются случайным образом и идут сразу после.

Для второй фазы ещё нужно продумать, как именно будет работать скрипт, где будут храниться артефакты его работы и так далее. Так что начинаем с первой фазы.

[nlopin]

Мне нравится формат, но не укладывается найминг. Может называть поднятые руками как-то типа priority?

[monochromer]

Может, pinned?

[solarrust]

А точно нам нужны два разных файла? Почему в одном не сделать вверху тег active, а ниже ready? Так проще будет перетаскивать статьи в форсив и избежать дублирования.

[pepelsbey]

Хорошая идея! Обновлю описание

[pepelsbey]

@nlopin @solarrust @monochromer обновил идею по вашим комментариям.

[solarrust]

Может быть избавимся от вложенности, если у нас один файлик в итоге будет? Просто в корне featured.md? И, кажется, уже в фазе первой мы можем использовать pinned.

[monochromer]

Только давайте не в корне репозитория, а во вложенной папке, например, settings или global_data?

[solarrust]

А зачем? Кажется, мы договорились прятать в паки то, что не относится к контенту. А этот файлик имеет прямое отношение к контенту, кмк

[furtivite]

А зачем?

Ну это вполне себе «кухонный» файл, его можно прятать, чтобы у контрибьюторов было меньше вопросов

[pepelsbey]

@monochromer пока у нас нет других претендентов на глобальные настройки, давай сохраним его в корне. Но можем ещё в пятницу побрейнштормить, есть ли у нас похожие материалы из контента, которые нужно линковать в платформу.

[monochromer]

С папкой работать проще. Её нужно будет просто добавить в env-файл. Иначе нужно править логику в файле make-links.js.

[furtivite]

Как думете, было бы классно, если бы при генерации|мерже новой главной скрипт|экшн проверял у статьи наличие у статьи заполненного поля description (обязательно) и обложки (опционально), и выдавал ошибку?

[pepelsbey]

Я бы не стал встраивать это в сборку, но мы можем такое линтить — если решим, что это важный сигнал.