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).

[zcorpan]

We have now moved to a new setup as of #1063

Data is from:

• The issue's OP (can be set by the issue reporter and people with triage or write access)
• The issue labels (can be set by people with triage or write access)
• activities.yml (can be set by anyone through PRs)

Not all issues are listed in activities.yml (to reduce the number of PRs / lower overhead).

[jgraham]

I think if we want to do this, a system where the reporter indicates which feature the proposal covers as part of the initial template makes sense.

I think on the WebDX side we need a better understanding of how we're going to manage early-stage features.

[captainbrosset]

@zcorpan feel free to close this PR. It no longer applies, and as @jgraham said, mapping your current system to web-features would likely require changing the issue template and some of the code you use to update the yaml file.

---

Not all issues are listed in activities.yml (to reduce the number of PRs / lower overhead).

Is the goal to eventually list them all there?

---

For information, I started manually mapping web-features to positions in this file: https://github.com/web-platform-dx/web-features-explorer/blob/main/standard-positions.json
The data in this file is now used to generate some UI in the web-features-explorer website. Here is an example (see it live):

---

Looking at activities.yml, it seems to me that you could almost get the caniuse, description, mdn, and url fields for free by linking your entries to web-features, which would simplify your file. Win-win 😄 ?

[zcorpan]

Is the goal to eventually list them all there?

No, going forward we'll only add entries to that file if we want to include a description and rationale in the dashboard website.

The gh-pages branch has a generated merged-data.json file which includes information for all standards position requests.