I love it because:

1. It's simple and minimally intrusive. It doesn't flood your notification panels with a lot of small details. It's more like a gentle reminder that there's something happening over there.
2. There is already many things we can measure and learn from
3. It certainly meets out goal for the quarter: "cross-wiki notifications, in one form or another"

@Legoktm: How feasible is this? My understanding is that CrossWatch can only pull this off by doing dozens of API requests and taking a long time to load. Do you think it's feasible and/or worth it to implement this ahead of "real" cross-wiki notifications?

@Mattflaschen pointed out this could also be done by leaving "pointer" notifications on all (or some?) other wikis.

It wouldn't be very difficult IMO. We'd need a db table (or we could abuse an object cache)[1] that keeps track of what wikis you have unread notifications on, that we update whenever a new one is created. And we add that to the API response and have it show up in the flyout.

[1] My proposal for cross-wiki API requests (link) has the same requirement.

In T114354#1711173, @Catrope wrote:

@Legoktm: How feasible is this? My understanding is that CrossWatch can only pull this off by doing dozens of API requests and taking a long time to load.

I'm not exactly sure how they do it. They're apparently using WebSockets for part.

I don't think spending users' conceptual space (and developer effort) on building something we don't think is the real solution is a good idea. It will spoil the idea of 'cross-wiki notifications' to be a poor imitation of what people want. You only get one first impression.

In T114354#1749021, @Jdforrester-WMF wrote:

I don't think spending users' conceptual space (and developer effort) on building something we don't think is the real solution is a good idea. It will spoil the idea of 'cross-wiki notifications' to be a poor imitation of what people want. You only get one first impression.

I don't think that the iterations vs. increments debate has a always a clear winner for all situations (i.e., applying the "best first impression" or " release early and ofter" always at any cost). I can detail a bit the reasons why I thought an iterative approach could work here.

This was proposed as an initial iteration because while still being useful and providing value, it won't require many route changes (in terms of development effort or changing the interaction paradigm). Users get a basic notification that will become expandable in a later stage with access to the individual notifications (keeping the same icon and text that was provided in the first step, but adding more details).

agree there is always a risk to provide an initial step that it is too basic, but the delivery through beta features (T114237) was intended to compensate that.