The "read" field is a timestamp right now, that stores when the message was read. There's no real reason to store that information, and on top of that, it may result in some issues of timezones with cross-wiki notifications.
We should transform the 'read' property into a boolean and save room in our database.
Would break analytics queries like https://phabricator.wikimedia.org/diffusion/ANLE/browse/master/ee/distribution_of_response_time.sql which use the actual values.
See also T131206: Notification dashboards miscount time-to-read (separate issue, just context).
As far as I can think, it wouldn't just break those queries—it would make them impossible to replicate unless we added the same information back into EventLogging (possibly in a new schema). I suppose that wouldn't defeat the purpose, since production would still be isolated from timezone issues and since we can automatically purge information from EventLogging where we can't in production.
@jmatazzoni, @Pginer-WMF, how important is that "distribution of response time" dashboard to product decision-making?
That metric was proposed as an indicator that illustrates how well users are dealing with the current stream of notifications. It can help to understand the effect of changes in the notification stream (e.g., provide new types of notifications) or the tools users have to deal with it (e.g., letting users focus on notifications of their interests or mute those that are not).
If we can identify alternative or better metrics to understand that, I'm ok in replacing that metric but I'm not sure we have such candidates now. Also, we need to reevaluate the usefulness of the current metric once the way it is calculated gets fixed.
My recollection is that in the triage meeting the other day the team didn't see this as a priority to begin with. If making it causes problems with metrics, it seems like this is something we probably don't need to pursue. I'm going to decline this ticket. @Mooeypoo, if you disagree, please speak up.