Open ddbeck opened 2 months ago
There's two sides of this: upstreaming and downstreaming.
Downstreaming is sending changes from the upstream side (mdn/browser-compat-data) to the downstream (web-platform-dx/web-features).
I'd expect a web-features workflow along these lines:
@mdn/browser-compat-data
in web-features (e.g., via Dependabot, repository/workflow dispatch, or cron workflow). npm run bcd-sync
(or similar). Do these steps:
compat_features
list, then delete the compat_features
list from the file and commit.compat_features
list, then annotate the .yml
file’s compat_features
line with the discrepancy. Note: some discrepancies will be expected/desired (e.g., BCD is “stale”); this should not fail tests or block merging.npm run dist
and commit. web-features:
keys that exist in BCD that do not have a corresponding feature ID, then generate an issue (or perhaps even a PR from a template) in web-features
reporting a "missing" feature.Upstreaming is sending changes from the downstream side (web-platform-dx/web-features) to the upstream side (mdn/browser-compat-data).
I'd expect an mdn/browser-compat-data workflow:
web-features
in a PR (e.g., via Dependabot, repository/workflow dispatch, or cron workflow). migrate-to-bcd
.
Goal
When we override
compat_features
in a YAML file here, those changes ought to propagate to mdn/browser-compat-data. Likewise, new features originating in mdn/browser-compat-data ought to bubble up to web-features.Background
Open Web Docs is working on several tasks including:
(see https://github.com/openwebdocs/project/issues/208)
But we're not capturing this work here on the repo anywhere. This issue is attempting cover it.