Identify TR specs that are too far behind their Editor's Drafts

[jyasskin]

Given https://github.com/w3c/browser-specs/blob/main/index.json, for specs with organization == W3C, the tool can fetch the two URLs available at either {series.releaseUrl, series.nightlyUrl} or {release.url, nightly.url}, and compare their publication dates (<time class="dt-updated">). If they're different, the SLI is the age of the release, and the SLO could be 4 weeks.

IETF specs have a similar feature using <time class="published">.

[svgeesus]

Sounds good in general although I would be wary of a metric that encourages republishing unchanged drafts with a new date just to keep the metric happy.

Also depending on the document status:

• updating a CR Snapshot with another CR Snapshot requires a new round of horizontal review, a transition request, a mandatory one-week period for related groups to object, a once-weekly meeting to review the transition request and then scheduling publication. That will never happen in 4 weeks and 3 months is a more realistic minimum, assuming horizontal re-review starts on the day the previous CRS was published.
• updating a Rec with an edited Rec with proposed corrections or amendments requires a 4-week AC review plus a couple of weeks to review the responses, giving an absolute minimum of 6 weeks even if the process is started the same day the previous Recommendation is published, with no time for public review.