When planning a deprecation, it may be difficult for browser vendors to anticipate all the ways a given API is used. This also means it may be hard to anticipate what breakage may be caused by this deprecation.
Web developers that have configured the Reporting API receive deprecation reports that notify them of (past and) upcoming deprecations in a given web app. What if the deprecation report could help developers not just receive info, but also share feedback on a given deprecation, and may help uncover use cases so far unknown to the browser vendor?
Proposed mitigation ☑️
Because deprecation reports can be generated (months?) AHEAD of a deprecation, the following mechanism could help uncover potential breakage earlier.
Extend the deprecation report body with one new field:
feedbackLink: link to the blink-dev thread where the deprecation is being discussed (or in the future, when other browsers adopt the Reporting API and are able to generate deprecation reports, to the relevant Firefox or Safari discussion).
Open question ⁉️
With this mitigation, the feedback link is just a raw link. Is it a sufficient call-to-action for developers to know what to do with it, and meaningfully engage on a deprecation thread?
=> Alternative
Instead of a new field, leverafe the existing message field in deprecation reports.
Append to it something like:
"If this API cover a key use case for your web application and if the proposed migration paths isn't an solution for you, please join <...> and share your use case."
Also see: Report body: disambiguate deprecation timelines
Problem today 💥
When planning a deprecation, it may be difficult for browser vendors to anticipate all the ways a given API is used. This also means it may be hard to anticipate what breakage may be caused by this deprecation.
Web developers that have configured the Reporting API receive deprecation reports that notify them of (past and) upcoming deprecations in a given web app. What if the deprecation report could help developers not just receive info, but also share feedback on a given deprecation, and may help uncover use cases so far unknown to the browser vendor?
Proposed mitigation ☑️
Because deprecation reports can be generated (months?) AHEAD of a deprecation, the following mechanism could help uncover potential breakage earlier.
Extend the deprecation report body with one new field:
feedbackLink: link to the blink-dev thread where the deprecation is being discussed (or in the future, when other browsers adopt the Reporting API and are able to generate deprecation reports, to the relevant Firefox or Safari discussion).Open question ⁉️ With this mitigation, the feedback link is just a raw link. Is it a sufficient call-to-action for developers to know what to do with it, and meaningfully engage on a deprecation thread?
=> Alternative Instead of a new field, leverafe the existing
messagefield in deprecation reports. Append to it something like: "If this API cover a key use case for your web application and if the proposed migration paths isn't an solution for you, please join <...> and share your use case."