-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Increase quality of compat data #3555
Comments
Status as of version 0.0.69 (released on 28th February 2019) for web platform features:
I've highlighted Edge here to show the most significant changes to the prior statistics. Updating Edge data was mostly driven by @foolip. Thanks for your work, Philip! |
@Elchi3, this is excellent! Thank you for getting started on this effort and sharing the baseline publicly. Would you mind sharing the code you're using to generate the stats, too? Just a gist would be fine—I think generating quality stats could be baked into the |
Thanks Daniel! It makes total sense to have this as a script! I've opened #3557 as a first stab at this. When you commented here, I actually realized that we should review the data gathering of this as we surely want these statistics to be correct 😄 Previously, there was a script that created a csv which then was used to make charts in a sheet, so this is inspired from that prior art (see https://github.com/atopal/browser-compat-data-dashboard). |
Thanks for the stats @Elchi3! I wonder how you'd like to deal with increasing the API coverage of BCD? When adding new entries entirely, it is arguably increasing the the usefulness of the data, but if data for all browsers isn't added up front it will regress these metrics slightly. One option for dealing with this is using absolute values, and aiming for what 100% would mean today. |
Thanks @foolip! You're right, by adding more data, this metric can regress. I think I'd want to be ambitious and see if we can reach this goal anyway and see if can maybe disallow adding new "true" and "nulls" once we've finished parts of this. So, e.g. "all Edge data" or all "Edge CSS data" has 100% real values and then the linter would disallow adding new "true" and "null" values for these parts and so we can't regress anymore. This would force new data contributors to provide real values and I don't know how much of a burden that would be on them. It would be another option, however. Also tagging @atopal to comment on the option of tracking absolute values of today. |
That is an interesting problem. The key result is an indicator for substantial progress against what we really care about: making the compatibility data more useful for individuals and tooling vendors. So, I think we want to reflect current reality as part of that key result and that means using the current data set at any given time. As an added benefit, I think that it will motivate us to figure out how to keep the quality up and not regress over time. That said, we might want to set a goal that allows for some minor fluctuations. 100% is just a very nice and very round number 😃 |
If you treat 0.7 as the expected average score of KRs (do you?) then to either 70% or ~85% real values, depending on if you treat 0% or 51.11%, would be success. |
Yes, .7 is the expected average score. I think it's fair to take 51% as the baseline. We are shooting for 100%, but a minimum of 85% would already be a significant improvement. |
I've updated the above stats for 0.0.66 and 0.0.69 using the latest version of the the script and here is the latest numbers for yesterday's release. Status as of version 0.0.70 (released on 07/03/2019) for web platform features:
|
Florian,
Is your script publicly available? I'd like to run it against releases for
the last year to find out how far we've come and how fast.
Joe
…On Fri, Mar 8, 2019 at 3:15 AM Florian Scholz ***@***.***> wrote:
I've updated the above stats for 0.0.66 and 0.0.69 using the latest
version of the the script and here is the latest numbers for yesterday's
release.
Status as of version 0.0.70 (released on 07/03/2019) for web platform
features:
browser real values true values null values
All 8 browsers 55.02% 22.08% 22.90%
chrome 65.68% 23.92% 10.40%
chrome android 49.91% 31.99% 18.09%
edge 53.46% 19.96% 26.59%
firefox 73.60% 12.90% 13.50%
ie 60.19% 14.79% 25.02%
safari 49.03% 18.88% 32.08%
safari ios 40.74% 20.34% 38.93%
webview android 47.51% 33.90% 18.59%
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#3555 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AH0viwg2Jwx1SxwKgyhCaWq8pNNXCZOvks5vUkY5gaJpZM4bZAak>
.
|
Yes, it's available here: #3557 |
Nice work!
Joe Medley | Technical Writer, Chrome DevRel | [email protected] |
816-678-7195
*If an API's not documented it doesn't exist.*
…On Thu, Mar 21, 2019 at 12:30 AM Vinyl Darkscratch ***@***.***> wrote:
I went ahead and compiled a list of all the features that are still listed
as null for Firefox, Safari, Chrome, IE, and Edge (all the desktop
versions), putting them in a public gist which can be found here
<https://gist.github.com/vinyldarkscratch/51e8e607a3fcc4a7d186e189a9b71a83>
.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3555 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AH0vi56iSXpm1TBloLYNu6_csGUHG9Vjks5vYzUngaJpZM4bZAak>
.
|
[Apologies to everyone for the lack of reviews from my side last week and this week. I was on vacation and then at a workshop presenting about this project :)] Status as of version 0.0.72 (released on 21/03/2019) for web platform features:
|
Status as of version 0.0.73 (released on 28/03/2019) for web platform features:
|
Status as of version 0.0.74 (released on 04/04/2019) for web platform features:
In this release we were able to move 2% of the values from |
Thanks @Elchi3, that's great to see! |
💜 All null and true values, begone! |
Someone should write a script that can generate a line graph of these percentages over time :) (bonus points if you go back all the way to ~0.50 as well) |
@vinyldarkscratch did you generate that gist with a script, and if so could you share it? :) |
I did, yeah -- I wrote linter/test-version-bool.js initially as a test against |
Status as of version 0.0.75 (released on 11/04/2019) for web platform features:
|
Status as of version 0.0.76 (released on 18/04/2019) for web platform features:
|
Status as of version 5.2.34 (released on 2023-02-03) for web platform features:
|
Status as of version 5.2.35 (released on 2023-02-10) for web platform features:
|
Status as of version 5.2.36 (released on 2023-02-17) for web platform features:
|
Status as of version 5.2.37 (released on 2023-02-21) for web platform features:
|
Status as of version 5.2.38 (released on 2023-02-23) for web platform features:
|
Status as of version 5.2.39 (released on 2023-02-28) for web platform features:
|
Status as of version 5.2.40 (released on 2023-03-07) for web platform features:
|
Status as of version 5.2.41 (released on 2023-03-10) for web platform features:
|
Status as of version 5.2.42 (released on 2023-03-14) for web platform features:
|
Status as of version 5.2.43 (released on 2023-03-17) for web platform features:
|
Status as of version 5.2.44 (released on 2023-03-21) for web platform features:
|
Status as of version 5.2.45 (released on 2023-03-24) for web platform features:
|
Status as of version 5.2.46 (released on 2023-03-28) for web platform features:
|
Status as of version 5.2.47 (released on 2023-03-31) for web platform features:
|
Status as of version 5.2.48 (released on 2023-04-04) for web platform features:
|
Status as of version 5.2.49 (released on 2023-04-07) for web platform features:
|
Status as of version 5.2.50 (released on 2023-04-11) for web platform features:
|
Status as of version 5.2.51 (released on 2023-04-18) for web platform features:
|
Status as of version 5.2.52 (released on 2023-04-21) for web platform features:
|
Status as of version 5.2.53 (released on 2023-04-25) for web platform features:
|
For quite some time, this goal has been very low on our priority list, as other goals have been more important, in particular the goal to ensure that our version numbers are accurate. As such, I'm going to close this issue. |
Work on this issue had resumed once again in the form of a project managed by Open Web Docs -- see openwebdocs/project#206 for more details! |
The MDN team is employed by Mozilla and has yearly goals. I'm opening this issue to inform you about this year's goal and to give status updates throughout the year.
In 2018, the team's goal for mdn/browser-compat-data has been to finish migrating compat data from the legacy wiki tables into this repository and offering the data to 3rd party tools.
This goal is now almost complete (see this gist for remaining pages using the legacy tables and the list of tools using the data.) Work is underway to fully finish this.This goal is now complete.In 2019 and going forward, the goal will be to increase the quality of the compat data found in this repository. Compat data quality can be measured in various ways (I will write about this in the wiki soon), but we're going to focus on our efforts on getting 100% real values for Firefox, IE, Edge, Chrome, Safari, mobile Safari, mobile Chrome for all web platform features (i.e. WebExtensions are excluded). Real values here means to replace all "true", "null" or no data values with either a version number or "false".
We have finished the following categories:
xpath(removed in Remove XPath and XSLT data #9830)xslt(removed in Remove XPath and XSLT data #9830)Beginning of the year overall baseline data (based on version 0.0.66, released on 7. Feb. 2019) for all 8 tracked browsers for web platform features: :
true
valuesnull
valuesGoing forward, I will update this issue with every release of BCD, so that we can track where we are.
If you have questions about how this goal was decided, or if you have feedback, please reach out to me or other MDN team members.
The text was updated successfully, but these errors were encountered: