Содержание
Этот файл содержит невидимые символы Юникода, которые могут быть отображены не так, как показано ниже. Если это намеренно, можете спокойно проигнорировать это предупреждение. Используйте кнопку Экранировать, чтобы показать скрытые символы.
Этот файл содержит неоднозначные символы Юникода, которые могут быть перепутаны с другими в текущей локали. Если это намеренно, можете спокойно проигнорировать это предупреждение. Используйте кнопку Экранировать, чтобы подсветить эти символы.
Privacy
Privacy review is an integral part of the launch process which requires early involvement in the development cycle. Privacy reviews are based on https://www.w3.org/TR/security-privacy-questionnaire/ to ensure that features are launching with privacy in consideration.
Some features need to follow Google internal review process to comply with Google’s privacy policy. Use this guideline to determine the review process.
It is recommended to involve privacy at the design stage to get earlier feedback and make the rest of the review easier.
Both experiment and ship require privacy review. However, if there aren’t privacy impacting changes between experiment and ship, the same approval can be reused for shipping.
Security
Security review is as important as privacy. This review follows the same questions as privacy review - https://www.w3.org/TR/security-privacy-questionnaire/. A single document addressing questions for both security and privacy will make the review easier for feature owners.
It is recommended to involve security at the design stage or even earlier to discuss any design related risks. Create bugs to track the security mitigations and resolve them before requesting a review.
Both experiment and ship require security review. However, if there aren’t security impacting changes between experiment and ship, the same approval can be reused for shipping.
Enterprise
Enterprise review is focused on ensuring that breaking changes are done in an "enterprise-friendly" way.
Breaking changes must have an "escape hatch" policy, which rolls the behavior back to the way it used to be when they're first introduced. This allows managed business-critical environments to continue to function, even if the change was a surprise to them. This helps improve our velocity, as it removes any pressure to roll back changes, even in these cases.
Frequently, the enterprise policy is temporary— it only needs to exist for 3 milestones after the change happens for minor changes, or 1 year for major, highly disruptive changes. You do not need to support the old behavior indefinitely (unless you believe there's a good reason to do so).
How to add a policy: https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md
We also must communicate these kinds of changes to enterprise admins. Chromestatus does most of the work for you automatically, but there are two things we need your help with:
-
Ensure that the summary of the feature includes the name of the enterprise policy used to control this change. This is used to communicate to IT admins.
-
Ensure that the summary, with enterprise policy, is accurate and complete at least 3 milestones before the change is promoted to stable. This gives admins time to plan for upcoming changes and to schedule any needed work for their web apps. Testing Testing ensures test coverage through unit tests, web platform tests (WPT), and other tests are all completed when requesting review. These are good practices for a sustainable development and for landing features in stable safely. This is a required gate to ship a feature to production.
Debuggability
Debugging support through Chrome DevTools is one of the most effective ways to help developers learn about, accept, and adopt a new Web Platform feature. It is therefore in the interest of developers, the Web Platform feature team, and the Chrome DevTools team that the rollout of new Web Platform features is accompanied or followed by adequate tooling support.
It is recommended to enable debuggability during the experimental stage.
When in doubt, please check out https://goo.gle/devtools-checklist for details.
Testing
Testing ensures test coverage through unit tests, web platform tests (WPT), and other tests are all completed when requesting review. These are good practices for a sustainable development and for landing features in stable safely. This is a required gate to ship a feature to production.
API Owners
API owners do a final validation of an experiment or ship intents to ensure features aren’t conflicting with Blink’s values. API owners check if other gates in chromestatus were approved before they could LGTM the feature. Apart from gates, API owners review ergonomic, interoperability and compatibility, and activation to ship a feature. However for experiments, debuggability, experiment duration, and partners are important discussion topics to receive final LGTM.