docbrown/config/feed-variants/README.md
Jeremy Friesen 38ee9ef309
Refactoring so relevancy levers define expected variables (#17591)
Prior to this commit, the SQL fragments included variables that were set
configured at a global level.

With this commit, we're now saying that each lever "knows" what variable
it needs; and providing the means at lever declaration time to "say"
what those variable names are.  (e.g. `Articles::Feeds::LEVER_CATALOG`).

Then as part of the variant configuration (in the
`./config/feed-variants/*.json` files) we now include the expected value
of those parameters; which by convention (and coercion) are integers.

This relates to forem/forem#17584 because we want to move from a
privileged user reaction that has two values (`negative` and `positive`)
into four values (`very_negative`, `negative`, `positive`, and
`very_positive`).  To do that, we'll create a new lever; but that's for
another pull request.
2022-05-06 13:54:33 -04:00

1.8 KiB

Feed Variants

This folder contains the feed variants that we have, are, or will be testing. By convention the file's basename without extension is the name of the variant (e.g. "./config/feed-variants/20220415-incumbent.json" encodes the variant named 20220415-incumbent).

There exists one variant, original.json, which is our fallback variant. This fallback is performant and adequate for generating the feed for DEV.to. It is present in case we need to quickly turn off an experiment. The name original is the same as the AbExperiment::ORIGINAL_VARIANT constant.

Do not remove original.json without consideration for how to rollback a feed experiment.

Variants are loaded into production as needed. That "need" is determined by the configuration of the ./config/field_test.yml. Once we load a variant into production, we cache that variant (see Articles::Feeds::VariantAssembler.variants_cache).

As part of our test suite we assemble and verify each defined variant.

How to Make a Feed Variant

A feed variant is written in JSON format. A feed variant configures one or more Articles::Feeds::RelevancyLevers. The variant configuration defines:

  • The cases and fallback for each of the selected relevancy levers
  • Optionally the sort order of the query results
  • Optionally a few high level parameters.

The relevancy levers and their SQL query fragments are defined in Articles::Feeds::LEVER_CATALOG. Any levers not configured for a variant are omitted for that variant (but available for other variants).

The available sort order is also defined in Articles::Feeds::LEVER_CATALOG.

The high level parameters are defined in Aritcles::Feeds::VariantQuery::Config and as of <2022-05-06 Fri> are:

  • max_days_since_published: only consider articles that were published no more than the max_days_since_published.