forem
Feed may be featuring stories that are not marked as "featured"
Describe the bug
The Articles::Feeds::FindFeaturedStory (see below) implies that we should select articles that are featured == true. However, the implementation does not force that a featured article must be featured == true (it instead says an article may be featured if it has a main image).
https://github.com/forem/forem/blob/7010c8733002ff12d08051dfeff0b6270e1cd315/app/services/articles/feeds/find_featured_story.rb#L1-L27
To Reproduce
I'm uncertain, except to say that you may well see articles in the "featured" slot that are not in fact featured. They just happen to have a main image.
Expected behavior
If the content administrators set an article as featured, I think that they would assume that the feed's featured article was featured == true.
The Articles::Feeds::WeightedQueryStrategy selects an article that is featured == true, which I believe is conformant to the expectations.
Screenshots
Not applicable.
Desktop (please complete the following information):
Not applicable.
Smartphone (please complete the following information):
Not applicable.
Additional context
Given Remove the requirement of the featured post to have an image · Issue #15292 · forem/forem, I believe that the "featured" story should have a featured == true attribute.
Thanks for the issue, we will take it into consideration! Our team of engineers is busy working on many types of features, please give us time to get back to you.
Feature requests that require more discussion may be closed. Read more about our feature request process on forem.dev.
To our amazing contributors: issues labeled type: bug are always up for grabs, but for feature requests, please wait until we add a ready for dev before starting to work on it.
To claim an issue to work on, please leave a comment. If you've claimed the issue and need help, please ping @forem/oss. The OSS Community Manager or the engineers on OSS rotation will follow up.
For full info on how to contribute, please check out our contributors guide.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This does seem like a bug. Your definition of featured in expected behavior is exactly what I'd expect:
If the content administrators set an article as featured, I think that they would assume that the feed's featured article was
featured == true.
@michael-tharrington is there any historical reasons that this is the way it is right now? Or do you think this is also a bug?
I did some sleuthing and for the "feed" (or at least some aspects of the feed), the featured == true has not been part of some of the feed generation considerations for quite some time; at least 2 years.
@amywtlin — to be honest, I was always a bit unclear about exactly what that button did.
I honestly think it was just used to highlight an article in green on the https://dev.to/admin/content_manager/articles interface. For instance, Ben would click the button on an article as a signifier to anyone working the "Content shift" (posting to buffer) that the article was good to share. Note that back then we used to have a more comprehensive system built into https://dev.to/admin/content_manager/articles for sending articles to Buffer — this was before the days of the forem2buffer app which has replaced that system.
I slightly feel like clicking featured would also auto bump the featured number of a post by some amount, but I could be wrong about that.
@michael-tharrington I looked at the code and checking featured does nothing to the featured_number.
So, the question is a matter of least surprise:
Given I am a content moderator
When I say an article is "featured"
Then I would expect that article would/could be shown in the featured slot
Right now, the criteria for the featured slot in the "Relevant" feed is what is "popular" and has a main image. I think that runs a bit counter intuitive to having a "featured" attribute for Article.
And if we don't add the featured == true filter, then if we implement the feature "don't require image for featured in the feed" will be whatever's popular/at the top of the list. When then begins to ask the question "Why are we having a featured section?"
Oh okay I didn't actually know what the featured slot meant at all prior to this – it sounds like it's hidden in the code and so requires knowledge of the code to understand.
"Why are we having a featured section?"
I think this featured box should just be removed because it's confusing.
Perhaps one day, we could have curated instead and add the item to an hand-picked/curated feed.
We have the concept of a pinned article. Personally, I think we should say that if moderators have marked something as featured AND we have a featured slot, then it makes sense to put those featured things in that slot.
That is a far easier change than ripping out the featured slot (which I'm all for but which has a larger impact on the existing system and our users).
Well really, this button is admin exclusive right now, so it's not available to mods. But maybe we could make it do the same thing if an admin decides to click it?
Can you please explain what happens when someone features an article again? I'm struggling to understand this. It sounds like it increases the chance of it appearing in the top spot of a feed, right? But it doesn't increase the feature score (that's unconnected)? And it doesn't sure-fire put the article in the top (pinned) spot just makes it more likely to be there?
It's tough for me to wrap my head around what it does and I'm not sure how I'd explain it to other Forem admin.
Can you please explain what happens when someone features an article again?
What I've found is:
- In the API, if you don't search on anything, we only surface featured articles
- In our digest emails, if the user doesn't follow anything, we surface only featured articles
This also highlights that our API is using different logic than our non-logged in users which uses different logic than our logged in users which uses different logic than our RSS feed.
Ideally, I'd like to have a singular "I'm logged in here's the articles that are part of the feed" and likewise, if I'm not logged in I'd have consistent results.
(This inter-relates with DEV.to's churn of data so it's not obvious from the outside that this churn inconsistency exists, because there are tens of thousands of updates each day that refine the score and thus the order of posts)
@michael-tharrington: featured tick under /admin/content_manager/articles isn't being used by community success. Correct?
After a discussion with @jeremyf, we think it makes sense to remove this both in /admin/content_manager/articles and the backend algorithm, and rethink what Creators/admins want with "featured" in the Forems. The idea to feature posts still make sense to me, but the currently implementation pulls in too many unnecessary things.
However, as these featured posts (the latest one is back in June, from Jeremy's query results) are actually used as fallback posts in 1) digest emails when users don't follow tags 2) API response when tags not specified, we do need to find a set of fallback posts for these cases, and potentially more similar scenarios that we haven't discovered.
@amywtlin that's right! The featured tick under /admin/content_manager/articles isn't being used by community success. I don't think it's being used by our editorial team either as they are now using forem2buffer.
After a discussion with @jeremyf, we think it makes sense to remove this both in /admin/content_manager/articles and the backend algorithm, and rethink what Creators/admins want with "featured" in the Forems. The idea to feature posts still make sense to me, but the currently implementation pulls in too many unnecessary things.
Awesome! I'd agree with this. Perhaps we can even find a way to lean on moderators to help us select "featured" posts. And maybe when a post is picked in this way, it can be marked as "staff" or "moderator" curated to specifically let onlookers know how the post was picked. The perks of this would be that it would likely feel good as an author to know that your post was handpicked + it would be very clear to our audience what is happening (i.e. no magic).
However, as these featured posts (the latest one is back in June, from Jeremy's query results) are actually used as fallback posts in 1) digest emails when users don't follow tags 2) API response when tags not specified, we do need to find a set of fallback posts for these cases, and potentially more similar scenarios that we haven't discovered.
Gotcha! Yeah, that makes sense that we'd need to fill that hole.
I am going to work to close the loop on the clear purpose of "featuring" a post:
- It adds outsized weight to the a post's likelihood of appearing in peoples' Relevant feed, to work in conjunction with natural relevancy factors such as tags, followed users etc.
- Its precise impact may vary based on feed strategy and a/b testing, but admins can use it to promote content that is generally useful to the community.
- It is the main action admins can use to impact a post in a positive way. It should be substantially more impactful than a thumbs up.
- It is not specifically related to "featured story" aka the top one with an image — we will seek to clarify verbiage here.
We will move forward with always having a button that admins can press to mark a post as important and valuable for the community. Further renaming and exact details around this are TBD, but we will work to make all of the above clear within the product and the docs. How individual admins choose to use the button will vary, but the impact will be consistent.
