• We have short, url and usage terms that can be used as long. This information does not exist everywhere e.g per project request has only short.
• We need to provide some config to store short and long form
• Images return as different content as articles one coming from metadata hence forming the short v/s long difference
• Check T417664, T420784, T421051 for more info

• Implemeting a method to trigger statsd to push the stats(prometheus_
• Next part is in grafana to expose these metrics

• Depends on T422508

• Idea is to optimize handler by passing the data builder as a service.
• The data builder is currently extremely hard coded to page signals. A possible follow up is to generalize the builder for other use cases like site signals.
• The tracer will also have to be passed since it is per request

• Some of what's listed here might already been done.
• This is about putting prometheus calls inside the if statements..it's very specific to the listed stuff e.g how many times do we not get the data.
• We want to see the shape of data - how many times do we have cache misses

Update on this being a blocker to launch::

Picking this up as part of T421891 so the new Handler injects the builder as a service

Noted. Then moving it to Radar for us.

Acknowledging request and moving to discussion to align on prioritization

Ack. It was blocked for ci not descriptions

How much caching support works out of the box for MediaWiki cache control

The pywikibot query from my end returns the hundreds of results. @Ipr1 are the 2 users you are using in the same usergroup? The official usergroups are listed here User rights and groups