Generate new statistics

[ddbeck]

Since the beginning of the year, we've been (mostly) complete in backfilling features from the history of the web, so the stats in #788 no longer have a lot of meaning for progress in web-features. We ought to adopt new stats that help us understand web-features in this more stable and maintenance-oriented era of the project.

New stats ought to help us:

• Highlight material changes in coverage of BCD keys and caniuse mappings (for example, a fractional percent change in BCD or caniuse coverage does not speak very loudly)
• Encourage us to direct our attention or resources to areas that will make material improvements to the data (for example, presently all BCD keys have the same weight in our statistics, even though I know they do not have equal utility or interest for developers)

[ddbeck]

I've got ideas for the following new metrics:

• Cumulative shipping days of unmapped BCD keys (smaller is better)

  Calculated as the sum of days since each unmapped BCD key has shipped in each browser in the core browser set. Keys which have not yet shipped in a stable release would count as 0. Partial implementations and prefixes would count toward this sum, but prefixes and flags would not.

  Unmapped keys shipped in more browsers would increase the metric more than unmapped keys shipped in fewer browsers. My intent here would be that the metric would go up more for keys developers are more likely to have encountered. Consequently, this metric would encourage us to prioritize mapping keys that have shipped more widely before keys that have shipped less widely (or not at all).

• Absolute unmapped BCD keys remaining (smaller is better)

  This would succeed (and invert) the existing "compat keys mapped to web-features" and BCD coverage metrics.

  Calculated as the number of BCD keys that have not been assigned to a feature in web-features. The target value would be 0 (though this would probably be an infrequent event, at best).

  If this number trends upward, it indicates that we're not assigning keys to keep up with BCD and may need more attention or resources. If this number trends downward, then it means that we're keeping up with BCD (and, presumably, the platform itself).

  This number would jump sometimes (e.g., if BCD adds a lot of backfill data, as it did in v7.1.18) but that would be a good signal that existing features need revision.

• Absolute unmapped caniuse IDs (smaller is better)

  This would succeed (and invert) the existing "caniuse IDs in web-features" and "caniuse IDs" coverage metric.

  Calculated as the number of caniuse IDs that do not have a mapping in web-features. The target value would be 0. Since caniuse now ingests web-features entries, it's possible that we might reach 0 and stay there.

  This metric would reflect a kind of (somewhat historic) comprehensiveness. Driving this number down would improve the continuity of web-features with the preexisting description of the web platform given by caniuse feature entries.

[jgraham]

The main metric I'd like us to improve on is the fraction of web-features that cover BCD keys with multiple baseline statuses. This should ideally be zero, possibly with some mechanism to allow explicit marking in exceptional cases.

Features with a baseline status other than "Limited Availability" covering things that are not in fact available across all the benchmark browser engines is by far the most common problem I've run into trying to use web-features data in practice, and we know it also causes confusion to end users (somewhat mitigated by sites like MDN simply not using web-features data for individual features, but directly computing baseline statuses for individual BCD keys).