Add OWD 2024 report #137
Draft
Add OWD 2024 report #137
+238
−4
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
✅ Deploy Preview for beautiful-dieffenbachia-e315ce ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
* Add a section on Fetch work * Update pages/content/reports/2024/index.md * Update pages/content/reports/2024/index.md * Update pages/content/reports/2024/index.md * Update pages/content/reports/2024/index.md * Update pages/content/reports/2024/index.md
| - [Collecting browser compatibility data whenever browsers release a new beta version](#collecting-browser-compatibility-data-whenever-browsers-release-a-new-beta-version) | ||
| - [Documentation for interoperable and widely available features](#documentation-for-interoperable-and-widely-available-features) | ||
| - [W3C WebDX web-features mapping of BCD keys into baseline features](#w3c-webdx-web-features-mapping-of-bcd-keys-into-baseline-features) | ||
| - [Replacing all "true" and "null" versions with real version numbers in BCD](#replacing-all-true-and-null-versions-with-real-version-numbers-in-bcd) |
There was a problem hiding this comment.
this one stands out as non very relatable to if you're not deep into BCD. I think formulating it as providing more accurate historical support data (maybe tying it to baseline calculations?) would be more understanable
| - [Documentation for interoperable and widely available features](#documentation-for-interoperable-and-widely-available-features) | ||
| - [W3C WebDX web-features mapping of BCD keys into baseline features](#w3c-webdx-web-features-mapping-of-bcd-keys-into-baseline-features) | ||
| - [Replacing all "true" and "null" versions with real version numbers in BCD](#replacing-all-true-and-null-versions-with-real-version-numbers-in-bcd) | ||
| - [Web Security docs for MDN](#web-security-docs-for-mdn) |
There was a problem hiding this comment.
maybe be a tad more specific about what OWD did to these docs
| - [openwebdocs/mdn-bcd-collector](https://github.com/openwebdocs/mdn-bcd-collector) | ||
| - [web-platform-dx/web-features](https://github.com/web-platform-dx/web-features) | ||
|
|
||
| Documentation about open web standards needs ongoing updating and maintenance as new web platform features are introduced and best practices change. We believe all of the above projects are essential information sources that web developers consult and trust on a daily basis. OWD believes that by contributing to these repositories, we have the biggest impact on open web platform documentation and we reach the majority of web developers worldwide. |
There was a problem hiding this comment.
web-features is mentioned in several places in the report, but is a new thing in 2024 - maybe this would be the right place to introduce what it is, and why OWD determined it's a useful conduit to its mission.
|
|
||
| Supporting this long tail of volunteers is a large part of OWD's work. PR reviews for the mdn/content repository are performed by members of the maintainer group, which consists of OWD staff, Mozilla, Google and Microsoft staff, W3C staff, and a select group of volunteer maintainers. | ||
|
|
||
| Special shout outs to volunteer reviewer [Josh-Cena](https://github.com/Josh-Cena), who alone took on 18.3% of reviews in 2024 for mdn/content, and to [Daniel D. Beck](https://github.com/ddbeck) who reviewed more than half (56.4%) of all web-features pull requests in 2024. A pleasure to work with both of you and your impact in 2024 on these two projects is very noteworthy! Thank you! |
There was a problem hiding this comment.
s/you/them/ ? (the report is not addressed to them afaik :)
|
|
||
| As part of this program, that continued from the first round in 2023, we completed key milestones: | ||
|
|
||
| - Open Web Docs (OWD) automated browser compatibility data updates using OWD’s [mdn-bcd-collector](https://github.com/openwebdocs/mdn-bcd-collector) project. Now, browser compatibility information is available to web developers for new browser releases faster than ever. |
There was a problem hiding this comment.
re faster than ever, can we be more specific? (e.g. one week after the release on average?)
| As part of this program, that continued from the first round in 2023, we completed key milestones: | ||
|
|
||
| - Open Web Docs (OWD) automated browser compatibility data updates using OWD’s [mdn-bcd-collector](https://github.com/openwebdocs/mdn-bcd-collector) project. Now, browser compatibility information is available to web developers for new browser releases faster than ever. | ||
| - OWD automatically detects added and removed browser features for 90.15% of the entire web platform when a new browser is released. The data is recorded in the open-source [BCD](https://github.com/mdn/browser-compat-data) project, which is used by tools commonly used by web developers, such as [CanIUse, MDN Web Docs, and used by](https://caniuse.com/) [Baseline](https://developer.mozilla.org/en-US/docs/Glossary/Baseline/Compatibility) and [web-features](https://github.com/web-platform-dx/web-features). |
There was a problem hiding this comment.
Suggested change
| - OWD automatically detects added and removed browser features for 90.15% of the entire web platform when a new browser is released. The data is recorded in the open-source [BCD](https://github.com/mdn/browser-compat-data) project, which is used by tools commonly used by web developers, such as [CanIUse, MDN Web Docs, and used by](https://caniuse.com/) [Baseline](https://developer.mozilla.org/en-US/docs/Glossary/Baseline/Compatibility) and [web-features](https://github.com/web-platform-dx/web-features). | |
| - OWD automatically detects added and removed browser features for 90.15% of the entire web platform when a new browser is released. The data is recorded in the open-source [BCD](https://github.com/mdn/browser-compat-data) project, which is used by tools commonly used by web developers, such as [CanIUse](https://caniuse.com/), MDN Web Docs, and is the key data source for [Baseline](https://developer.mozilla.org/en-US/docs/Glossary/Baseline/Compatibility) and [web-features](https://github.com/web-platform-dx/web-features). |
| - Open Web Docs (OWD) automated browser compatibility data updates using OWD’s [mdn-bcd-collector](https://github.com/openwebdocs/mdn-bcd-collector) project. Now, browser compatibility information is available to web developers for new browser releases faster than ever. | ||
| - OWD automatically detects added and removed browser features for 90.15% of the entire web platform when a new browser is released. The data is recorded in the open-source [BCD](https://github.com/mdn/browser-compat-data) project, which is used by tools commonly used by web developers, such as [CanIUse, MDN Web Docs, and used by](https://caniuse.com/) [Baseline](https://developer.mozilla.org/en-US/docs/Glossary/Baseline/Compatibility) and [web-features](https://github.com/web-platform-dx/web-features). | ||
| - OWD runs tests on mobile browsers and WebViews to have accurate compatibility data for these platforms and to point out differences between mobile and desktop browsers. | ||
| - We also made our tooling more generally available, so that new tools, such as [runtime-compat-data](https://runtime-compat.unjs.io/) can display compatibility across different JavaScript runtimes. We hope that our work on this data will contribute to better understanding of compatibility issues, to more interoperability, and better standardization on the web platform. |
There was a problem hiding this comment.
Suggested change
| - We also made our tooling more generally available, so that new tools, such as [runtime-compat-data](https://runtime-compat.unjs.io/) can display compatibility across different JavaScript runtimes. We hope that our work on this data will contribute to better understanding of compatibility issues, to more interoperability, and better standardization on the web platform. | |
| - We also made our tooling more generally available, so that new tools, such as [runtime-compat-data](https://runtime-compat.unjs.io/) can display compatibility across different JavaScript runtimes. We are proud that our work on this data contributes to better understanding of compatibility issues, to more interoperability, and better standardization on the web platform. |
|
|
||
| ## Executive summary | ||
|
|
||
| Open Web Docs is taking a look at how our efforts have helped to ensure the long-term health of web platform documentation on critical resources like MDN Web Docs, independently of any single vendor or organization. Founded in January 2021, the year 2024 marked Open Web Docs’ fourth year of operation! |
There was a problem hiding this comment.
Maybe, to contextualize this a bit more:
Suggested change
| Open Web Docs is taking a look at how our efforts have helped to ensure the long-term health of web platform documentation on critical resources like MDN Web Docs, independently of any single vendor or organization. Founded in January 2021, the year 2024 marked Open Web Docs’ fourth year of operation! | |
| Open Web Docs is taking a look at how our efforts, in 2024, have helped to ensure the long-term health of web platform documentation on critical resources like MDN Web Docs, independently of any single vendor or organization. Founded in January 2021, the year 2024 marked Open Web Docs’ fourth year of operation! |
| Previous Open Web Docs Impact and Transparency Reports: [2023](https://openwebdocs.org/content/reports/2023/), [2022](https://openwebdocs.org/content/reports/2022/), [2021](https://openwebdocs.org/content/reports/2021/). | ||
|
|
||
| <div class="callout"> | ||
| <p>Open Web Docs is a non-profit, strongly community-focused open source collective that uses its donations to employ a group of technical writers who are dedicated to writing and improving documentation for the web platform.</p> |
There was a problem hiding this comment.
Minor, but you might be able to drop the <p> HTML tagging here by just adding an empty line:
Suggested change
| <p>Open Web Docs is a non-profit, strongly community-focused open source collective that uses its donations to employ a group of technical writers who are dedicated to writing and improving documentation for the web platform.</p> | |
| Open Web Docs is a non-profit, strongly community-focused open source collective that uses its donations to employ a group of technical writers who are dedicated to writing and improving documentation for the web platform. |
Comment on lines
+37
to
+38
| - <a href="https://github.com/sponsors/openwebdocs">GitHub Sponsors</a> | ||
| - <a href="https://opencollective.com/open-web-docs">Open Collective</a> |
There was a problem hiding this comment.
MD tagging should work for those links, right?
|
|
||
| ## Sovereign Tech Fund | ||
|
|
||
| Open Web Docs is very proud to have received a second round investment from the Sovereign Tech Fund at the beginning of 2024. The [Sovereign Tech Fund (STF)](https://www.sovereign.tech/programs/fund) supports the development, improvement, and maintenance of open digital infrastructure in the public interest. The [Sovereign Tech Fund’s Contribute Back Challenges](https://www.sovereign.tech/programs/challenges) selected Open Web Docs as a partner to implement improved tooling and maintenance of the [mdn/browser-compat-data](https://github.com/mdn/browser-compat-data) and further development of the [openwebdocs/mdn-bcd-collector](https://github.com/openwebdocs/mdn-bcd-collector) tool. |
There was a problem hiding this comment.
Suggested change
| Open Web Docs is very proud to have received a second round investment from the Sovereign Tech Fund at the beginning of 2024. The [Sovereign Tech Fund (STF)](https://www.sovereign.tech/programs/fund) supports the development, improvement, and maintenance of open digital infrastructure in the public interest. The [Sovereign Tech Fund’s Contribute Back Challenges](https://www.sovereign.tech/programs/challenges) selected Open Web Docs as a partner to implement improved tooling and maintenance of the [mdn/browser-compat-data](https://github.com/mdn/browser-compat-data) and further development of the [openwebdocs/mdn-bcd-collector](https://github.com/openwebdocs/mdn-bcd-collector) tool. | |
| Open Web Docs is very proud to have received a second round of investment from the Sovereign Tech Fund at the beginning of 2024. The [Sovereign Tech Fund (STF)](https://www.sovereign.tech/programs/fund) supports the development, improvement, and maintenance of open digital infrastructure in the public interest. The [Sovereign Tech Fund’s Contribute Back Challenges](https://www.sovereign.tech/programs/challenges) selected Open Web Docs as a partner to implement improved tooling and maintenance of the [mdn/browser-compat-data](https://github.com/mdn/browser-compat-data) and further development of the [openwebdocs/mdn-bcd-collector](https://github.com/openwebdocs/mdn-bcd-collector) tool. |
|
|
||
| Open Web Docs is very proud to have received a second round investment from the Sovereign Tech Fund at the beginning of 2024. The [Sovereign Tech Fund (STF)](https://www.sovereign.tech/programs/fund) supports the development, improvement, and maintenance of open digital infrastructure in the public interest. The [Sovereign Tech Fund’s Contribute Back Challenges](https://www.sovereign.tech/programs/challenges) selected Open Web Docs as a partner to implement improved tooling and maintenance of the [mdn/browser-compat-data](https://github.com/mdn/browser-compat-data) and further development of the [openwebdocs/mdn-bcd-collector](https://github.com/openwebdocs/mdn-bcd-collector) tool. | ||
|
|
||
| As part of this program, that continued from the first round in 2023, we completed key milestones: |
There was a problem hiding this comment.
Suggested change
| As part of this program, that continued from the first round in 2023, we completed key milestones: | |
| As part of this program, we continued the work started during from the first round, in 2023, by completing these key milestones: |
|
|
||
| ### Collecting browser compatibility data whenever browsers release a new beta version | ||
|
|
||
| This project has initially been funded by the [Sovereign Tech Fund](#sovereign-tech-fund) with the goal to provide web developers with the latest information about available web platform features whenever a new browser version is released and continues thanks to OWD's main sponsors Google and Microsoft. In 2024, we observed 11 releases from Chrome, 12 from Firefox, and 7 from Safari. We systematically collected compatibility data 30 times in 2024. |
There was a problem hiding this comment.
Since you mention Microsoft, it feels odd not mentioning Edge in the number of observed releases:
Suggested change
| This project has initially been funded by the [Sovereign Tech Fund](#sovereign-tech-fund) with the goal to provide web developers with the latest information about available web platform features whenever a new browser version is released and continues thanks to OWD's main sponsors Google and Microsoft. In 2024, we observed 11 releases from Chrome, 12 from Firefox, and 7 from Safari. We systematically collected compatibility data 30 times in 2024. | |
| This project has initially been funded by the [Sovereign Tech Fund](#sovereign-tech-fund) with the goal to provide web developers with the latest information about available web platform features whenever a new browser version is released and continues thanks to OWD's main sponsors Google and Microsoft. In 2024, we observed 11 releases from Chrome (applying to Edge too), 12 from Firefox, and 7 from Safari. We systematically collected compatibility data 30 times in 2024. |
|
|
||
| ### Replacing all "true" and "null" versions with real version numbers in BCD | ||
|
|
||
| In [mdn/browser-compat-data](https://github.com/mdn/browser-compat-data), we used to set the version number to "true" whenever we know that a web platform feature is supported in a browser but we don't know which was the first version that introduced support. Also, when a features' support was entirely unknown, we used to set the version number to "null". This meant that the compatibility data was quite incomplete and not always useful to data consumers. Especially the calculation of baseline was not possible with incomplete data. |
There was a problem hiding this comment.
Felt like this was a bit hard to parse, here's an alternate version:
Suggested change
| In [mdn/browser-compat-data](https://github.com/mdn/browser-compat-data), we used to set the version number to "true" whenever we know that a web platform feature is supported in a browser but we don't know which was the first version that introduced support. Also, when a features' support was entirely unknown, we used to set the version number to "null". This meant that the compatibility data was quite incomplete and not always useful to data consumers. Especially the calculation of baseline was not possible with incomplete data. | |
| Previously, the [mdn/browser-compat-data](https://github.com/mdn/browser-compat-data) project used to have incomplete browser version numbers. Features that were supported but for which we didn't know the first browser version that introduced support was, had a version number set to "true". And features for which support was entirely unknown had a version number set to "null". This meant that the compatibility data was incomplete and not always useful to consumers. In particular, the calculation of the Baseline status was not possible with incomplete data. |
|
|
||
| In [mdn/browser-compat-data](https://github.com/mdn/browser-compat-data), we used to set the version number to "true" whenever we know that a web platform feature is supported in a browser but we don't know which was the first version that introduced support. Also, when a features' support was entirely unknown, we used to set the version number to "null". This meant that the compatibility data was quite incomplete and not always useful to data consumers. Especially the calculation of baseline was not possible with incomplete data. | ||
|
|
||
| Thanks to a 2024 project led by [Queen Vinyl Da.i'gyu-Kazotetsu](https://github.com/queengooborg) and [Florian Scholz](https://github.com/Elchi3), BCD no longer has "true" and "null" values. All data in BCD now comes with a real version number or at least a [ranged version number](https://github.com/mdn/browser-compat-data/blob/main/schemas/compat-data-schema.md#ranged-versions-). |
There was a problem hiding this comment.
Suggested change
| Thanks to a 2024 project led by [Queen Vinyl Da.i'gyu-Kazotetsu](https://github.com/queengooborg) and [Florian Scholz](https://github.com/Elchi3), BCD no longer has "true" and "null" values. All data in BCD now comes with a real version number or at least a [ranged version number](https://github.com/mdn/browser-compat-data/blob/main/schemas/compat-data-schema.md#ranged-versions-). | |
| Thanks to a 2024 project led by [Queen Vinyl Da.i'gyu-Kazotetsu](https://github.com/queengooborg) and [Florian Scholz](https://github.com/Elchi3), BCD no longer has "true" and "null" values. All data in BCD now comes with, at the very least, a [ranged version number](https://github.com/mdn/browser-compat-data/blob/main/schemas/compat-data-schema.md#ranged-versions-), or a real version number. |
|
|
||
| One result of this was an overhaul of the Content Security Policy documentation on MDN. This included a rewrite of the [CSP guide](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) to align guidance with [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html) and [web.dev](https://web.dev/articles/strict-csp), to document some of the other protections offered by a CSP in addition to resource loading controls, and to explain better how a CSP can help protect against XSS attacks. We also [rewrote and reorganized the reference documentation for fetch directive syntax](https://github.com/orgs/mdn/discussions/756) to fix many errors and make the syntax easier to understand. | ||
|
|
||
| We've also started writing guide pages about attacks and their mitigations. The first of these was a [guide about cross-side scripting (XSS)](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/XSS) explaining what it is and how to protect against it in both client- and server-side code, using web platform features such as CSP and [trusted types](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/XSS#trusted_types). We've also written a guide about [clickjacking](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/Clickjacking). The next part of this work will be a guide to [cross-site leaks](https://xsleaks.dev/), including mitigations such as [Cross-Origin-Resource-Policy (CORP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Resource-Policy) and [Cross-Origin-Opener-Policy (COOP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy). |
There was a problem hiding this comment.
Suggested change
| We've also started writing guide pages about attacks and their mitigations. The first of these was a [guide about cross-side scripting (XSS)](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/XSS) explaining what it is and how to protect against it in both client- and server-side code, using web platform features such as CSP and [trusted types](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/XSS#trusted_types). We've also written a guide about [clickjacking](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/Clickjacking). The next part of this work will be a guide to [cross-site leaks](https://xsleaks.dev/), including mitigations such as [Cross-Origin-Resource-Policy (CORP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Resource-Policy) and [Cross-Origin-Opener-Policy (COOP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy). | |
| We've also started writing guide pages about attacks and their mitigations. The first of these was a [guide about cross-side scripting (XSS)](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/XSS) explaining what it is and how to protect against it in both client- and server-side code, using web platform features such as CSP and [trusted types](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/XSS#trusted_types). We've also written a guide about [clickjacking](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/Clickjacking). The next part of this work will be a guide to [cross-site leaks](https://xsleaks.dev/), including mitigations such as [Cross-Origin-Resource-Policy (CORP)](https://developer.mozilla.org/docs/Web/HTTP/Headers/Cross-Origin-Resource-Policy) and [Cross-Origin-Opener-Policy (COOP)](https://developer.mozilla.org/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy). |
It would be good to do a global search/replace once the article is final, to remove the en-us locale parts of these URLs.
|
|
||
| We've also started writing guide pages about attacks and their mitigations. The first of these was a [guide about cross-side scripting (XSS)](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/XSS) explaining what it is and how to protect against it in both client- and server-side code, using web platform features such as CSP and [trusted types](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/XSS#trusted_types). We've also written a guide about [clickjacking](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/Clickjacking). The next part of this work will be a guide to [cross-site leaks](https://xsleaks.dev/), including mitigations such as [Cross-Origin-Resource-Policy (CORP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Resource-Policy) and [Cross-Origin-Opener-Policy (COOP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy). | ||
|
|
||
| This project is led by [Will Bamberg](https://github.com/wbamberg). We would like to thank [Daniel Appelquist](https://github.com/torgo) for chairing the SWAG CG and [Aaron Shim](https://github.com/aaronshim) and [Artur Janc](https://github.com/arturjanc) from the Google Security team who sponsored us with $20,000 to support this effort and who participate regularly in SWAG calls to give advice and reviews. |
There was a problem hiding this comment.
If possible, can we link to this particular project financial contribution on opencollective? It's a good example of directed funding which other sponsors might want to imitate.
estelle
reviewed
Jan 22, 2025
|
|
||
| ## Executive summary | ||
|
|
||
| Open Web Docs is taking a look at how our efforts have helped to ensure the long-term health of web platform documentation on critical resources like MDN Web Docs, independently of any single vendor or organization. Founded in January 2021, the year 2024 marked Open Web Docs’ fourth year of operation! |
There was a problem hiding this comment.
Suggested change
| Open Web Docs is taking a look at how our efforts have helped to ensure the long-term health of web platform documentation on critical resources like MDN Web Docs, independently of any single vendor or organization. Founded in January 2021, the year 2024 marked Open Web Docs’ fourth year of operation! | |
| Open Web Docs' work in 2024 helped ensure the long-term health of web platform documentation on critical resources like MDN Web Docs, independently of any single vendor or organization. Founded in January 2021, 2024 marked Open Web Docs’ fourth year of operation! |
|
|
||
| Open Web Docs is taking a look at how our efforts have helped to ensure the long-term health of web platform documentation on critical resources like MDN Web Docs, independently of any single vendor or organization. Founded in January 2021, the year 2024 marked Open Web Docs’ fourth year of operation! | ||
|
|
||
| Open Web Docs (OWD) is an [Open Source Collective](https://opencollective.com/open-web-docs) that employs technical writers to publicly document open web technologies. OWD currently employs two full time writers, one compat data engineering contractor, and OWD's director to run the program. Everyone at OWD has extensive experience with Web standards documentation, MDN Web Docs, and browser compatibility data. The OWD team writes new documentation, updates existing documentation, and improves documentation infrastructure together with other organizations such as Mozilla, Google, Microsoft, W3C, Igalia, and other external contributors and volunteers. |
There was a problem hiding this comment.
Suggested change
| Open Web Docs (OWD) is an [Open Source Collective](https://opencollective.com/open-web-docs) that employs technical writers to publicly document open web technologies. OWD currently employs two full time writers, one compat data engineering contractor, and OWD's director to run the program. Everyone at OWD has extensive experience with Web standards documentation, MDN Web Docs, and browser compatibility data. The OWD team writes new documentation, updates existing documentation, and improves documentation infrastructure together with other organizations such as Mozilla, Google, Microsoft, W3C, Igalia, and other external contributors and volunteers. | |
| Open Web Docs (OWD) is an [Open Source Collective](https://opencollective.com/open-web-docs) that employs engineers to publicly document open web technologies. OWD currently employs two full time technical writers, one compat data engineering contractor, and OWD's director to run the program. Everyone at OWD has extensive experience with Web standards documentation, MDN Web Docs, and browser compatibility data. The OWD team writes new documentation, updates existing documentation, and improves documentation infrastructure together with other organizations such as Mozilla, Google, Microsoft, W3C, Igalia, and other external contributors and volunteers. |
suggest stating we are all engineers somehow, because the experience makes our team uniquely capable. others may have a better way of adding this tidbit.
|
|
||
| - Was again the organization that contributed the greatest number of pull requests (PRs) merged to the [mdn/content](https://github.com/mdn/content) (14.1%) and [mdn/browser-compat-data](https://github.com/mdn/browser-compat-data) (52.4%) repositories. | ||
| - Provided 27% of all pull request reviews to the mdn/content repository and 52% of reviews to mdn/browser-compat-data. | ||
| - Started to become a maintainer of the [web-platform-dx/web-features](https://github.com/web-platform-dx/web-features) repo and contributed 14.8% of merged pull requests. |
There was a problem hiding this comment.
Suggested change
| - Started to become a maintainer of the [web-platform-dx/web-features](https://github.com/web-platform-dx/web-features) repo and contributed 14.8% of merged pull requests. | |
| - Became a maintainer of the [web-platform-dx/web-features](https://github.com/web-platform-dx/web-features) repo and contributed 14.8% of merged pull requests. |
we didn't just "start". we are!
| - Provided 27% of all pull request reviews to the mdn/content repository and 52% of reviews to mdn/browser-compat-data. | ||
| - Started to become a maintainer of the [web-platform-dx/web-features](https://github.com/web-platform-dx/web-features) repo and contributed 14.8% of merged pull requests. | ||
| - Completed major technical writing and documentation engineering projects which were determined and guided by OWD’s [Steering Committee](https://github.com/openwebdocs/project/blob/main/steering-committee/membership-expectations.md). This included among other things: | ||
| - [Collecting browser compatibility data whenever browsers release a new beta version](#collecting-browser-compatibility-data-whenever-browsers-release-a-new-beta-version) |
There was a problem hiding this comment.
Suggested change
| - [Collecting browser compatibility data whenever browsers release a new beta version](#collecting-browser-compatibility-data-whenever-browsers-release-a-new-beta-version) | |
| - [Collecting browser compatibility data for every browser release, including all beta releases](#collecting-browser-compatibility-data-whenever-browsers-release-a-new-beta-version) |
| - Started to become a maintainer of the [web-platform-dx/web-features](https://github.com/web-platform-dx/web-features) repo and contributed 14.8% of merged pull requests. | ||
| - Completed major technical writing and documentation engineering projects which were determined and guided by OWD’s [Steering Committee](https://github.com/openwebdocs/project/blob/main/steering-committee/membership-expectations.md). This included among other things: | ||
| - [Collecting browser compatibility data whenever browsers release a new beta version](#collecting-browser-compatibility-data-whenever-browsers-release-a-new-beta-version) | ||
| - [Documentation for interoperable and widely available features](#documentation-for-interoperable-and-widely-available-features) |
There was a problem hiding this comment.
Suggested change
| - [Documentation for interoperable and widely available features](#documentation-for-interoperable-and-widely-available-features) | |
| - [Documenting all interoperable and widely available browser features](#documentation-for-interoperable-and-widely-available-features) |
|
|
||
| This project has initially been funded by the [Sovereign Tech Fund](#sovereign-tech-fund) with the goal to provide web developers with the latest information about available web platform features whenever a new browser version is released and continues thanks to OWD's main sponsors Google and Microsoft. In 2024, we observed 11 releases from Chrome, 12 from Firefox, and 7 from Safari. We systematically collected compatibility data 30 times in 2024. | ||
|
|
||
| For Chrome 122-132, Firefox 123-134, and Safari 17.4-18.3 we were able to update browser compat data within the beta cycles of the browser releases, so that web developers were provided with updated information at the time these browsers released the stable version. |
There was a problem hiding this comment.
Suggested change
| For Chrome 122-132, Firefox 123-134, and Safari 17.4-18.3 we were able to update browser compat data within the beta cycles of the browser releases, so that web developers were provided with updated information at the time these browsers released the stable version. | |
| For Chrome 122-132, Firefox 123-134, and Safari 17.4-18.3, we were able to update browser compatibility data within the beta cycles of each browser release. This enabled us to provide web developers with updated information as every stable browser version was released. |
|
|
||
| For Chrome 122-132, Firefox 123-134, and Safari 17.4-18.3 we were able to update browser compat data within the beta cycles of the browser releases, so that web developers were provided with updated information at the time these browsers released the stable version. | ||
|
|
||
| 2024 was the first year we systematically collected web platform compatibility data and we want to continue this effort and make it as efficient as possible for the years and browser releases to come. The maintenance of the mdn-browser-compat-data project has highly benefited from this and the data is much more reliable allowing data consumers, especially the web-features and baseline projects, to be most up-to-date and accurate. |
There was a problem hiding this comment.
Suggested change
| 2024 was the first year we systematically collected web platform compatibility data and we want to continue this effort and make it as efficient as possible for the years and browser releases to come. The maintenance of the mdn-browser-compat-data project has highly benefited from this and the data is much more reliable allowing data consumers, especially the web-features and baseline projects, to be most up-to-date and accurate. | |
| 2024 was the first year we systematically collected web platform compatibility data. We want to continue this effort and make it as timely and efficient as possible for every browser release for all the years to come. The maintenance of the mdn-browser-compat-data project benefits greatly from these efforts, and the data is accurate, reliable, and complete, which allows the consumers of the data, especially MDN, web-features, and the Baseline projects, to be up-to-date and accurate. |
|
|
||
| 2024 was the first year we systematically collected web platform compatibility data and we want to continue this effort and make it as efficient as possible for the years and browser releases to come. The maintenance of the mdn-browser-compat-data project has highly benefited from this and the data is much more reliable allowing data consumers, especially the web-features and baseline projects, to be most up-to-date and accurate. | ||
|
|
||
| The project is led by [Florian Scholz](https://github.com/Elchi3) and representatives of browser projects have been reviewing data. Thank you: [Philip Jägenstedt](https://github.com/foolip) (Chromium/Google), [Rachel Andrew](https://github.com/rachelandrew) (Chromium/Google), [Chris Mills](https://github.com/chrisdavidmills) (Chromium/Google), [Patrick Brosset](https://github.com/captainbrosset/) (Chromium/Microsoft), [Jon Davis](https://github.com/jdatapple) (WebKit/Apple), [Jen Simmons](https://github.com/jensimmons) (WebKit/Apple), [Ruth John](https://github.com/Rumyra) (Gecko/Mozilla), [Brian Smith](https://github.com/bsmth) (Gecko/Mozilla), [Hamish Willee](https://github.com/hamishwillee) (Gecko/Mozilla), [Claas Augner](https://github.com/caugner) (Gecko/Mozilla). |
There was a problem hiding this comment.
Suggested change
| The project is led by [Florian Scholz](https://github.com/Elchi3) and representatives of browser projects have been reviewing data. Thank you: [Philip Jägenstedt](https://github.com/foolip) (Chromium/Google), [Rachel Andrew](https://github.com/rachelandrew) (Chromium/Google), [Chris Mills](https://github.com/chrisdavidmills) (Chromium/Google), [Patrick Brosset](https://github.com/captainbrosset/) (Chromium/Microsoft), [Jon Davis](https://github.com/jdatapple) (WebKit/Apple), [Jen Simmons](https://github.com/jensimmons) (WebKit/Apple), [Ruth John](https://github.com/Rumyra) (Gecko/Mozilla), [Brian Smith](https://github.com/bsmth) (Gecko/Mozilla), [Hamish Willee](https://github.com/hamishwillee) (Gecko/Mozilla), [Claas Augner](https://github.com/caugner) (Gecko/Mozilla). | |
| The BCD Automation project is led by [Florian Scholz](https://github.com/Elchi3) and representatives of browser projects have been reviewing data. Thank you: [Philip Jägenstedt](https://github.com/foolip) (Chromium/Google), [Rachel Andrew](https://github.com/rachelandrew) (Chromium/Google), [Chris Mills](https://github.com/chrisdavidmills) (Chromium/Google), [Patrick Brosset](https://github.com/captainbrosset/) (Chromium/Microsoft), [Jon Davis](https://github.com/jdatapple) (WebKit/Apple), [Jen Simmons](https://github.com/jensimmons) (WebKit/Apple), [Ruth John](https://github.com/Rumyra) (Gecko/Mozilla), [Brian Smith](https://github.com/bsmth) (Gecko/Mozilla), [Hamish Willee](https://github.com/hamishwillee) (Gecko/Mozilla), [Claas Augner](https://github.com/caugner) (Gecko/Mozilla). |
|
|
||
| As of writing this report, there are about 15,000 browser-compat-data keys that describe features of the web platform. In 2024, the W3C WebDX web-features project went on a mission to map all of these keys into [web-features](https://github.com/web-platform-dx/web-features) to build a shared catalog of features of the web platform. | ||
|
|
||
| By creating a common nomenclature for web platform features, web-features intends to support communication between web developers, browser vendors, standardization bodies, and other ecosystem participants. From Array to Cascade Layers to Offscreen Canvas, web-features identifies, defines, and categorizes capabilities of the web platform that web developers care about. |
There was a problem hiding this comment.
Suggested change
| By creating a common nomenclature for web platform features, web-features intends to support communication between web developers, browser vendors, standardization bodies, and other ecosystem participants. From Array to Cascade Layers to Offscreen Canvas, web-features identifies, defines, and categorizes capabilities of the web platform that web developers care about. | |
| By creating a common nomenclature for web platform features, the web-features project supports improved communication between web developers, browser vendors, standardization bodies, and other ecosystem participants. From Array to Cascade Layers to Offscreen Canvas, the web-features project identifies, defines, and categorizes the capabilities of the web platform that web developers care about. |
Comment on lines
+129
to
+131
| This work has been fantastic team work with a group of people contracted by Google, including Open Web Docs, [James Stuckey Weber](https://github.com/jamesnw/) from [Oddbird](https://www.oddbird.net/), [Dietrich Ayala](https://github.com/autonome), [Daniel D. Beck](https://github.com/ddbeck), and [Kadir Topal](https://github.com/atopal). It was great fun and memories from the [BCD migration from wiki tables to JSON data](https://hacks.mozilla.org/2018/02/mdn-browser-compatibility-data/) came back as we were [tracking our progress](https://github.com/web-platform-dx/web-features/issues/788) over the last few months. | ||
|
|
||
| We also provided synchronization of browser-compat-data keys between the mdn/browser-compat-data and web-platform-dx/web-features repositories and made sure that the two projects sync up nicely and complement each other effectively. |
There was a problem hiding this comment.
Suggested change
| This work has been fantastic team work with a group of people contracted by Google, including Open Web Docs, [James Stuckey Weber](https://github.com/jamesnw/) from [Oddbird](https://www.oddbird.net/), [Dietrich Ayala](https://github.com/autonome), [Daniel D. Beck](https://github.com/ddbeck), and [Kadir Topal](https://github.com/atopal). It was great fun and memories from the [BCD migration from wiki tables to JSON data](https://hacks.mozilla.org/2018/02/mdn-browser-compatibility-data/) came back as we were [tracking our progress](https://github.com/web-platform-dx/web-features/issues/788) over the last few months. | |
| We also provided synchronization of browser-compat-data keys between the mdn/browser-compat-data and web-platform-dx/web-features repositories and made sure that the two projects sync up nicely and complement each other effectively. | |
| OWD provided synchronization of browser-compat-data keys between the mdn/browser-compat-data and web-platform-dx/web-features repositories, ensuring the two projects sync up nicely and complement each other effectively. | |
| This project was a fantastic collaboration between the group of people contracted by Google, including Open Web Docs, [James Stuckey Weber](https://github.com/jamesnw/) from [Oddbird](https://www.oddbird.net/), [Dietrich Ayala](https://github.com/autonome), [Daniel D. Beck](https://github.com/ddbeck), and [Kadir Topal](https://github.com/atopal). Memories from the [BCD migration from wiki tables to JSON data](https://hacks.mozilla.org/2018/02/mdn-browser-compatibility-data/) came back as we were [tracking our progress](https://github.com/web-platform-dx/web-features/issues/788) over the last few months. It was great fun! |
wbamberg
reviewed
Jan 23, 2025
|
|
||
| Supporting this long tail of volunteers is a large part of OWD's work. PR reviews for the mdn/content repository are performed by members of the maintainer group, which consists of OWD staff, Mozilla, Google and Microsoft staff, W3C staff, and a select group of volunteer maintainers. | ||
|
|
||
| Special shout outs to volunteer reviewer [Josh-Cena](https://github.com/Josh-Cena), who alone took on 18.3% of reviews in 2024 for mdn/content, and to [Daniel D. Beck](https://github.com/ddbeck) who reviewed more than half (56.4%) of all web-features pull requests in 2024. A pleasure to work with both of you and your impact in 2024 on these two projects is very noteworthy! Thank you! |
There was a problem hiding this comment.
Suggested change
| Special shout outs to volunteer reviewer [Josh-Cena](https://github.com/Josh-Cena), who alone took on 18.3% of reviews in 2024 for mdn/content, and to [Daniel D. Beck](https://github.com/ddbeck) who reviewed more than half (56.4%) of all web-features pull requests in 2024. A pleasure to work with both of you and your impact in 2024 on these two projects is very noteworthy! Thank you! | |
| Special shout outs to volunteer reviewer [Joshua Chen](https://github.com/Josh-Cena), who alone took on 18.3% of reviews in 2024 for mdn/content, and to [Daniel D. Beck](https://github.com/ddbeck) who reviewed more than half (56.4%) of all web-features pull requests in 2024. A pleasure to work with both of you and your impact in 2024 on these two projects is very noteworthy! Thank you! |
(I asked Josh how he would like me to name him for the Fetch bit)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
First draft. Needs more content still. See "TBD"s.