Yeah, we were talking about only promoting it up on iOS on days when there is a new item. It does get stale pretty quick.

Tagging with the Feed 2.0 epic.

This is something to think about when planning improvements to the feed.

Right now everything is coupled to a concept of a day, we should revisit this here.

hi @Niedzielski – at the moment Android only shows 'In the news' once at the very top of the feed which is refreshed each day.
In this ticket, are you proposing inserting multiple instances of 'In the news' per day according to chronology (which is how iOS is currently doing it)?

@RHo, this task identifies that the news card shows very repetitive content for days and makes the whole feed feel outdated. The proposed solutions are one of: 1) show multiple news cards with redundant content filtered out (T149244) 2) move the news card further down the feed since the content has probably already been seen (this task). So, something like the iOS implementation would be preferable otherwise we should move the news card further down the feed.

Quick question for @Mholloway or @bearND :

It looks like the Aggregated feed endpoint is returning news items only for the current day, and doesn't return news for any previous days. Is this expected behavior? And if so, can we make it always return news items? Even with the understanding that many news items will repeat from one day to the next, we would still like to receive the full set of contents for any given day, and then optionally de-duplicate news items on our end.

@Dbrant Yes, that's the currently designed behavior. The main reason for this is because RESTBase doesn't store the news portion for historical aggregated feed entries. I'm not sure what the reason for that was. Maybe @Pchelolo remembers?

Maybe @Pchelolo remembers?

@Pchelolo remembers - we don't store any feed content because of vandalism and purging issues.

@Pchelolo So, we would need better dependency tracking in change-prop, right? Kind of a mapping of WP pages to aggregated feed entries.

@Pchelolo So, we would need better dependency tracking in change-prop, right? Kind of a mapping of WP pages to aggregated feed entries.

@bearND eventually - yes, but this is quite problematic to implement right now without a full-blown dependency tracking system. We were trying to solve this with really short TTL in cassandra and really short varnish TTL and content hydration, but as you remember it's proven to be not good enough T174993

News are particularly hard since apart from links to other articles it contains some text of the news item itself that comes from a special page that is different for every wiki.

So given we don't have a proper dynamic dependency tracking system, using our current static change-prop is unrealistic.

@Pchelolo Doesn't ChangeProp serve a dependency management role? Initially we could get away without an automatic one. I was thinking MCS could add a private endpoint that ChangeProp would access to add some mappings of dependencies, like this:

[ { 
    "source": { "domain": "en.wikipedia.org", "page": "Template:In_the_news" }, 
    "target": { "type": "feed", "value": "news" } 
} ]

Or similar, whatever makes more sense for ChangeProp. This kind of information would be fairly static and could only change during deploy time. It's somewhat similar to the feed availability endpoint in that regard, except that it doesn't have to be public to be useful.