I have this open PR....
Add feed_strategy config
#10245
What type of PR is this? (check all applicable)
- [ ] Refactor
- [x] Feature
- [ ] Bug Fix
- [ ] Optimization
- [ ] Documentation Update
Description
This PR adds a feed_strategy configuration option, with either "basic" or "optimized", and more possible options in the future.
This solves the issue of the DEV feed really being "optimized" for a lot of users, when a typical forem doesn't really need that algorithm (arguably DEV doesn't either), but this gives us some room to offer different approaches for different types of forems, while not exposing too many knobs to the admin-facing API which will let us work with the underlying algorithms over time.
This PR does not include all the possible code that could fall under a choice, but I wanted to provide the basics to ensure new forems have a usable feed right away and the choice in config. We can adjust more of the underlying functionality, including further refactoring in the future.
Post deploy task: DEV should be updated to "optimized", other forems should get on the default "basic" version. No need for data update script
It adds feed_strategy alongside feed_style as a way for choosing which feed algorithm to select for one's forem. 99% of forems should start with "basic", including all existing forems except DEV.... With the idea that a lot of the work that went into DEV's current algorithm is not useful across forems of all scale.
I envision a future with dozens of different strategies for different cases and a lot of transparent experimentation in this regard.
A good follow-on feature would be transparency over what strategy a forem is using alongside other config transparency.
The hair-on-fire problem this addresses is offering up a simpler, less random feed algorithm for all new forems, and a base config which we can build on.
I suspect that once this is merged, the home page for forem.dev will immediately be a lot more useful.
Top comments (2)
I am live with this now :D
Brilliant 😻