736079e28c
In the general sense we have an existing `order by` that follows the following format: `order(x) = f(x) * rand() ^ ( 1 / g(x))` For the present [20220603-variant-b][1], `g(x)` is the article’s score. And `f(x)` is 1. This pull request introduces a few named variations for the above `order(x)` formula. The three named formats each use a different `g(x)` function; namely `greatest(0.1, ln(1 + greatest(0, public_reactions_count)))`. The more public_reactions the article has the closer to zero the resulting positive number will be. And raising a random number, with range `(0..1)`, to the inverse of that number will tend to mean that artciles with many reactions will tend to group towards the higher end of the random range, whereas articles with few reactions will have a more even distribution across the range. Further the `ln` function helps dampen the weight we give to reactions. The variation within these three order levers is on the `f(x)` portion: 1. Using `published_at` 2. Using `last_commented_at` 3. Using a mix of `published_at` and `last_commented_at` In all cases, those dates are converted to an integer. A date 2 weeks ago will result in a number less than a date 1 week ago which will be less than a today. The idea for the mix of `published_at` and `last_commented_at` is to see a mix of things where some “older” articles (from the underlying result set) will get a chance to show up earlier in the feed. My rational for this order structure is because the `RANDOM() ^ (1 / score)` is showing possible success in a current experiment. And in past trials long past, it rose to the top as a likely and viable contender. These new `order_by` lever patterns introduce three things: 1. A variable based on a date in time 2. A dampening of what can be a large number; (we have scores in the publication range that are between -200 and 750 so I think it is important to apply a dampening. For example `(0.1 ^ (1/100)) = 0.977` and `(0.01 ^ (1/100)) = 0.955`; in other words these large scores aggressively pushed their corresponding posts to the top of the relevance; even as we weren't explicitly querying for those scores. 3. With the score being quasi-magical, it doesn’t make sense to sort on that value but to instead sort on a property that represents what we’re setting as our experiment goals (e.g. publishing something or commenting on something and/or reacting to something) Note: it would be feasible to extract these into a singular order lever that we would configure. But that's a future concern. Also note, none of these are yet part of any experiment, but are instead being "queued up" to add to our available corpus. Closes forem/forem#17834 Related to: - forem/forem#17827 - forem/forem#17826 - forem/forem#17833 - forem/forem#16128 :: for past order queries to seek as inspiration [1]:https://github.com/forem/forem/blob/main/config/feed-variants/20220603-variant-b.json |
||
|---|---|---|
| .buildkite | ||
| .gems | ||
| .github | ||
| .husky | ||
| .vscode | ||
| .yarn/releases | ||
| app | ||
| bin | ||
| config | ||
| cypress | ||
| datadog | ||
| db | ||
| lib | ||
| log | ||
| public | ||
| scripts | ||
| spec | ||
| vendor | ||
| .codeclimate.yml | ||
| .dockerignore | ||
| .editorconfig | ||
| .env.test | ||
| .env_sample | ||
| .erb-lint.yml | ||
| .eslintignore | ||
| .eslintrc.js | ||
| .gitattributes | ||
| .gitignore | ||
| .gitpod.dockerfile | ||
| .gitpod.yml | ||
| .lintstagedrc.js | ||
| .nvmrc | ||
| .postcssrc.yml | ||
| .prettierignore | ||
| .prettierrc.json | ||
| .rspec | ||
| .rubocop.yml | ||
| .rubocop_todo.yml | ||
| .ruby-version | ||
| .simplecov | ||
| .slugignore | ||
| .solargraph.yml | ||
| .travis.yml | ||
| .yardopts | ||
| .yarnclean | ||
| .yarnrc | ||
| babel.config.js | ||
| CHANGELOG.md | ||
| CODE_OF_CONDUCT.md | ||
| config.ru | ||
| container-compose.yml | ||
| Containerfile | ||
| customJsDomEnvironment.js | ||
| cypress.dev.json | ||
| cypress.json | ||
| docker-compose.yml | ||
| Dockerfile | ||
| empty-module.js | ||
| Gemfile | ||
| Gemfile.lock | ||
| gitpod-init.sh | ||
| Guardfile | ||
| jest.config.js | ||
| jsconfig.json | ||
| LICENSE.md | ||
| package.json | ||
| postcss.config.js | ||
| Procfile | ||
| Procfile.dev | ||
| Procfile.dev-hot | ||
| Rakefile | ||
| README.md | ||
| release-tasks.sh | ||
| SECURITY.md | ||
| svgo.config.js | ||
| testSetup.js | ||
| yarn.lock | ||
Forem 🌱
For Empowering Community
Welcome to the Forem codebase, the platform that powers dev.to. We are so excited to have you. With your help, we can build out Forem’s usability, scalability, and stability to better serve our communities.
What is Forem?
Forem is open source software for building communities. Communities for your peers, customers, fanbases, families, friends, and any other time and space where people need to come together to be part of a collective. See our announcement post for a high-level overview of what Forem is.
dev.to (or just DEV) is hosted by Forem. It is a community of software developers who write articles, take part in discussions, and build their professional profiles. We value supportive and constructive dialogue in the pursuit of great code and career growth for all members. The ecosystem spans from beginner to advanced developers, and all are welcome to find their place within our community. ❤️
Table of Contents
- What is Forem?
- Table of Contents
- Community
- Contributing
- Getting Started
- Developer Documentation
- Core team
- Vulnerability disclosure
- License
Community
For a place to have open discussions on features, voice your ideas, or get help with general questions please visit our community at forem.dev.
Contributing
We encourage you to contribute to Forem! Please check out the Contributing to Forem guide for guidelines about how to proceed.
Getting Started
This section provides a high-level quick start guide. If you're looking for a more thorough installation guide (for example with macOS, you'll want to refer to our complete Developer Documentation.
We run on a Rails backend, and we are currently transitioning to a Preact-first frontend.
A more complete overview of our stack is available in our docs.
To launch Forem in Gitpod, navigate to https://gitpod.io/#https://github.com/{your_github_username}/forem.
Prerequisites
Local
- Ruby: we recommend using rbenv to install the Ruby version listed on the badge.
- Yarn 1.x: please refer to their installation guide.
- PostgreSQL 11 or higher.
- ImageMagick: please refer to ImageMagick's installation instructions.
- Redis 4 or higher.
Containers
Linux
- Podman 1.9.2 or higher
- Podman Compose 0.1.5 or higher
OS X
Installation Documentation
Please see our installation guides, such as the one for macOS.
Developer Documentation
Check out our dedicated docs page for more technical documentation.
Core team
- @benhalpern
- @jessleenyc
- @peterkimfrank
- @maestromac
- @zhao-andy
- @lightalloy
- @joshpuetz
- @juliannatetreault
- @ridhwana
- @fdoxyz
- @msarit
- @jdoss
- @cmgorton
- @andygeorge
- @phannon716
- @s_aitchison
- @rt4914
- @jeremyf
- @dscottS3
- @asheren
- @jaw6
Vulnerability disclosure
Forem is the open source software which powers DEV.
We welcome security research on DEV under the terms of our vulnerability disclosure policy.
Acknowledgments
Thank you to the Twemoji project for the usage of their emojis.
License
This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. Please see the LICENSE file in our repository for the full text.
Like many open source projects, we require that contributors provide us with a Contributor License Agreement (CLA). By submitting code to the Forem project, you are granting us a right to use that code under the terms of the CLA.
Our version of the CLA was adapted from the Microsoft Contributor License Agreement, which they generously made available to the public domain under Creative Commons CC0 1.0 Universal.
Any questions, please refer to our license FAQ doc or email yo@dev.to.
Happy Coding ❤️