Map mozilla positions to web-features IDs

[captainbrosset]

The web-features repository maintains a growing list of web platform features. This list acts as a hub for various web data such as browser-compat-data, Can I Use, specs, WPT, Chrome's usage counters, etc.

The most useful thing the web-features repo offers right now is a summary of browser support and a Baseline status per feature. The Baseline status, in particular, is used on the MDN Web Docs and Can I Use websites.
Other websites such as webstatus.dev use a bunch of information from web-features.

The W3C WebDX CG (which currently maintains the repo) recently discussed mapping web-features entries to browser standard positions too.

This PR is a proposal for the first step towards achieving this. It adds IDs of features in the web-features repo to individual entries here. This is done by adding an optional webFeaturesID property to entries in activities.json. This property is a string which value matches filenames in https://github.com/web-platform-dx/web-features/tree/main/features (without the file extension).

If you agree with this approach, this will help us link Mozilla positions with a lot of other data about web platform features around various web properties.

I plan on proposing a similar PR for https://webkit.org/standards-positions/

cc @jgraham who we discussed this with.

[captainbrosset]

I could use help for an additional mapping:

• webFeaturesId: registered-custom-properties
• Possible IDs in this repo: css-properties-and-values-api or at-property.

Any idea which one I should be mapping to?

[zcorpan]

Thanks for this PR!

We're considering moving away from maintaining activities.json for each request, and instead mostly use GitHub labels. Right now some requests with a position aren't listed in activities.json. Maybe we can use labels for web features though.

[captainbrosset]

We're considering moving away from maintaining activities.json for each request, and instead mostly use GitHub labels. Right now some requests with a position aren't listed in activities.json. Maybe we can use labels for web features though.

This sounds very similar to how WebKit does it then. Using labels would indeed work, but it means that your team would have to maintain these labels (mostly remembering to add the label in the first, web-features IDs are very unlikely to change over time).