search

WebKit / standards-positions

WebKit's positions on emerging web specifications
https://webkit.org/standards-positions/
254 stars 21 forks source link

Map WebKit positions to web-features IDs #357

Open captainbrosset opened 5 months ago

captainbrosset commented 5 months ago

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 summary.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 WebKit positions with a lot of other data about web platform features around various web properties.

I opened a similar PR on Mozilla's positions repo, see https://github.com/mozilla/standards-positions/pull/1034

cc @annevk who we discussed this with.

annevk commented 5 months ago

This seems reasonable to me, but if you run python3 summary.py --process I suspect this would all be removed again so that will need to be patched as well somehow which might be quite involved. It might be easier to figure out a way to annotate issues with this.

cc @jdatapple @hober

captainbrosset commented 5 months ago

Oh, I see. So the way this works is:

  1. You run an update, which fetches the data from all GitHub issues and writes it to summary-data.json
  2. You process that data, which writes summary.json
  3. The website displays summary.json nicely

Is this roughly correct?

If so, I agree that the right thing to do seems to figure out a new GitHub issue label to add to issues, and which would be processed by the python script and written to summary.json.

The only potential blocker I see with this is that I'm not allowed to add labels to issues on this repo. While I'm happy to change this PR to update the python script, I wouldn't be able to update all of the necessary issues with the right labels.

Or, we maintain the mapping in a new file instead? And I can open PRs to just make changes to this file.

annevk commented 5 months ago

Yeah that's correct.

I like the separate file idea. That seems pretty straightforward.

Though I guess you could also maintain that mapping in a separate repository if you wanted to. Pretty happy to not change our IDs ever.

rik commented 5 months ago

Another option would be to change the issue form to ask for a web-feature id and update summary.py to extract it.

The benefit I see compared to the separate file is that issues would display that name to help browse.