-
Notifications
You must be signed in to change notification settings - Fork 2
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
Group charter for 2024 #12
Comments
Just some ideas for the compatibility report if we go in that direction. Trying to maintain compatibility with caniuse sounds like it could be a great idea: |
Pull request with proposed charter changes: We will discuss this in the next group meeting. |
More specifically, a useful approach could perhaps be to base this compatibility report on web-features, a shared catalog of features of the web platform developed in the WebDX Community Group, with representatives from browser vendors, MDN, BCD, Can I Use (this includes @Elchi3, @Fyrd and me). That would allow to maintain compatibility with Can I Use, but also with MDN (both Can I Use and MDN now use web-features to document baseline support), and hopefully with other places that need to talk about web features at a relatively coarse level, down the road. It would also probably help with bringing WebView support data to BCD directly. |
Expanding on today's discussion, what I think could be useful for developers is not a one-time document that describes the API differences between WebViews, but rather continuously updated support data about WebViews that get integrated and reflected in available documentation, in turn to provide incentives to maintain the data over time. From a charter perspective, instead of a "document", the WebView CG could perhaps endeavor to gather compatiblity data for WebViews, feed them into common sources (best one that comes to mind would indeed be BCD, since it is used in MDN, Can I Use, and web-features), and develop or contribute to tools that can ease data maintenance. This could mean adjusting #13 to:
On top of gathering the data, which would also be a problem to create a document, the main hurdle with that proposal is of course data maintenance... Hence the idea to create synergies between people who have support data and those who can consume it. BCD contains fine-grained features. If it it turns out to be impractical to provide support data at that level, this is where web-features could help, as it provides a list of higher-level features that are more directly usable in discourse, and that map to BCD features (meaning a tool could easily and automatically convert the higher-level support data for use in BCD). |
Thanks, those suggestions are great and I absolutely agree with the sentiment of focusing on cementing process rather than having a one time report. I figured it can't hurt to just add a second heading called non-normative data? It would also be great to investigate if the WebView providers can help support this data programmatically to some degree. This deliverable captures that, while not necessarily committing us to it if it proves too difficult. I've updated the charter proposal PR. If we move ahead with this updated charter, I'll create a new repo that we can start tracking these TODOs in. |
We have now updated the charter. We will initiate the compatibility data project under https://github.com/WebView-CG/Compatibility-Data-Project. |
This issue will be used to track high level discussions into the charter for 2024.
The chairs are proposing that we add the deliverable, a webview compatibility report. This would serve as a reference point into the differences between different WebView providers.
We are also proposing to add a decision process like other community groups have.
The text was updated successfully, but these errors were encountered: