-
Notifications
You must be signed in to change notification settings - Fork 47
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
Add script to find list of specs potentially in scope #70
Conversation
per #50 Looks into the report from validate-repo for repos associated with browser-spec producing WGs and well-known browser-spec producing CGs (both lists curated manually) and match that list of repos with URLs known in browser-spec
current output (which has false positives but also true ones that need review/discusison): |
right now, the script doesn't have a way to track repos/URLs that would have been reviewed as not worth watching - input on where/how to track this would be useful (could be done the same was as WGs/CGs with a static list in the code?) I'm also not clear how to handle URLs which right now have uninteresting content, but might become interesting (e.g. https://w3c.github.io/system-wake-lock/) - maybe the script should have a bit more heuristic than just 404 check. Some of the false positives could be fixed by fixing the underlying repos (e.g. adding a proper w3c.json); others could be by relaxing some of the tests (e.g. the CSS specific URLs could be checked as a prefix of a known spec URL). |
conversely, the script right now is not useful in identifying new specs in csswg-drafts and similar multi-spec repos; this would probably require additional repo-specific heuristics |
probably helps with #62
I've added a test that compares with the data from the spec-dashboard, which I think will help with #62 and should also help with some of the CSS spec finding. The data from that new test gives: The false positives here probably also imply some TR cleanup (in addition to clean up in specs.json) |
mostly useful cosmetic changes
Yay modern JS
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While you're at improving readability, a couple of additional suggestions :)
https://w3c.github.io/webdriver-bidi/ doesn't have any implementation yet, but is intended for browser implementation (and nothing else). It's not important to include it now, but also not bad. It doesn't define any CSS or IDL that will trickle down anywhere else. |
This is still a draft, should I do a final review pass, or wait until it's marked ready? |
@tidoust and I discussed this morning: to finalize this PR, I'll
Later improvements (e.g. setting up a regular github action to run it, post the results as github issue or pull request) will be raised as issues for improvement. Likewise will I raise issues for the specs identified by the script as needing reviews or fixes in our list. |
They'll have to be identified through other mechanisms
…arily Defines a JSON list of specs and repos that can be ignored (e.g. because the work is not targeted at browsers) Defines a JSON list of specs with no relevant content at the moment but that may become relevant later (to be regularly checked)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of editorial comments which are up to you.
Otherwise, I note that we will need to add some code as part of the GitHub action that runs this script periodically to check on lastreviewed
dates and report on entries that need to be checked again (e.g. if they haven't been reviewed in the last 3 months or so). One option is to have this script filter out old entries from monitor-repos.json
when it parses it. Doing it separately would probably help clarify that the entry is a actually a known one, just one that needs to be evaluated again. Anyway, that can be done separately.
- Use TR URL for geolocation-sensor - Use TR URL for reporting-1 - Use TR URL for feature-policy-1 - Use TR URL for accname-1.2 - Use TR URL for core-aam-1.2 - Add css-box-4 (on top of -3, which is still "active") - Add user-timing-3 (on top of -2, which is still the "default" for user-timing) - Replace webdriver1 with webdriver2 - Adjust shortname for webxr-ar-module-1 (fixed in W3C API) - Adjust shortname for webxr-gamepads-module-1 (fixed in W3C API)
- Use TR URL for geolocation-sensor - Use TR URL for reporting-1 - Use TR URL for feature-policy-1 - Use TR URL for accname-1.2 - Use TR URL for core-aam-1.2 - Move to W3C URL for badging - Add css-box-4 (on top of -3, which is still "active") - Add user-timing-3 (on top of -2, which is still the "default" for user-timing) - Replace webdriver1 with webdriver2 - Adjust shortname for webxr-ar-module-1 (fixed in W3C API) - Adjust shortname for webxr-gamepads-module-1 (fixed in W3C API)
- Use TR URL for geolocation-sensor - Use TR URL for reporting-1 - Use TR URL for feature-policy-1 - Use TR URL for accname-1.2 - Use TR URL for core-aam-1.2 - Move to W3C URL for badging - Add css-box-4 (on top of -3, which is still "active") - Add user-timing-3 (on top of -2, which is still the "default" for user-timing) - Replace webdriver1 with webdriver2 - Adjust shortname for webxr-ar-module-1 (fixed in W3C API) - Adjust shortname for webxr-gamepads-module-1 (fixed in W3C API)
per #50
Looks into the report from validate-repo for repos associated with browser-spec producing WGs and well-known browser-spec producing CGs (both lists curated manually) and match that list of repos with URLs known in browser-spec