Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Map WebKit positions to web-features IDs #357

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

captainbrosset
Copy link

@captainbrosset captainbrosset commented May 30, 2024

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 mozilla/standards-positions#1034

cc @annevk who we discussed this with.

@annevk
Copy link
Contributor

annevk commented May 30, 2024

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
Copy link
Author

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
Copy link
Contributor

annevk commented May 30, 2024

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
Copy link

rik commented May 30, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta For issues about this repo
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants