Feedback

A proposal begins with an explainer—a high-level technical overview of a proposed specification's functionality. Explainers are posted to start the feedback process, as there are always open questions and details that need clarification. This collaborative process is ongoing through the lifecycle of the proposal from early discussion of the idea through to iterating on revisions of a formal specification.

The explainers and supporting content are hosted on GitHub. GitHub enables anyone with a GitHub account to raise an Issue (ask questions or add comments) in the repository (repo) to start or participate in a discussion. Proposal authors, including Chrome product managers and engineers, are active in these discussions and GitHub provides options to be alerted for any new activity. With GitHub feedback, you can engage directly with the community interested in a specific proposal. Even without a GitHub account, you can still read all the community commentary for each proposal.

Discussion in the repository should be focused on how and why the proposal addresses the use case it sets out to solve. You can find the link to view and raise an issue for each proposal in the Feedback column of the tables in the Proposals section.

Each proposal may result in one or more features to build in Chromium. Proposal developers submit requests to begin each stage of feature development on the public blink-dev mailing list. These stages include: Intent to Prototype (I2P), Intent to Experiment (I2E), Intent to Ship (I2S), or Intent to Remove (I2R).

• Intent to Prototype (I2P): the developer would like to begin an initial implementation in Chromium. This often results in early functionality being available for developer testing. Useful feedback at this stage is likely best suited to GitHub as the aim at this stage is to validate proposal ideas with working code.
• Intent to Experiment (I2E): the developer would like to run scaled testing in the form of an origin trial. This allows sites to test early functionality on a portion of their own traffic. Useful feedback at this stage includes stating willingness to participate and if the proposed experiment meets your needs to validate behavior.
• Intent to Ship (I2S): the developer would like to deploy the completed feature to Chromium. This results in the functionality being available for all users. Useful feedback at this stage addresses outstanding issues to ensure the feature is ready for general availability.
• Intent to Remove (I2R): the developer would like to deprecate and remove functionality from Chromium. Useful feedback here includes highlighting if this removal impacts your use case in ways not captured by the development team.

Each stage has a standard template where the developer will provide a selection of relevant information. Certain stages require approval from Chromium project owners who will do this by providing a "Looks Good To Me" (LGTM) response on the post.

The mailing list is open to the public so you can follow along with the discussion on each milestone and join the list to ask additional questions. There is a high-level of activity on this list as it covers all functionality landing in the Chromium project, so you may wish to track individual features on the Chrome Status site.

Discussion on these threads should focus on the specifics of implementing the particular feature in Chromium; discussion on how the proposal itself functions is best suited for GitHub. You can find a link to view and contribute to each of these announcements in the Intents column in the tables in the Proposals section.

As individual proposals progress through implementation in Chromium, a proposal-specific mailing list may be created to allow for focused communication.

This allows for announcements and discussion of origin trial updates, necessary code updates , or known issues that may impact development. As with blink-dev, these lists are public. If you are directly tracking or working on one of these proposals, you should join the specific list to hear updates directly from the development teams.

Discussions on these threads should be focused on the ongoing implementation detail in Chromium as the intended audience is developers directly coding against the feature, as opposed to a general audience interested in broad announcements. You can find a link to read and contribute to these in the Mailing list column in the tables in the Proposals section.

This includes implementation bugs where Chromium's behavior does not match the proposed specification, but can also cover browser-specific functionality such as how the feature interacts with DevTools and user preferences, or it may just be to report an error. Issues can be raised at any point in the lifecycle of a Chromium feature, whether that's newly available for developer testing behind a flag or something discovered in a stable release.

Discussion in Chromium issues should be focused on the details of the envisaged implementation of the feature in Chromium; discussion on how the proposal itself functions should go to GitHub. You can find a link to view or raise issues in the Chromium component column of the tables in the Proposals section.

The W3C and IETF are international communities that develop open standards for the web and the Internet to ensure the long term growth of these open platforms. New web platform technologies, like Privacy Sandbox technologies, are proposed and discussed in various forums across these standards bodies. These forums are open to anyone who wants to actively participate in the design and development of the technologies.

Each standards body offers any interested party a variety of different membership and contribution options. There are Community Groups and Business Groups which include members from across the web ecosystem and relevant industries. Proposal authors will often present overviews and progress updates at associated meetings, providing an opportunity to ask direct questions and hear from other stakeholders. Meeting minutes for most groups are publicly available.

Discussion in standards bodies is wide-ranging, but generally focuses on how a proposal meets the needs of the ecosystem and its progress towards becoming an accepted standard. You can find a link to follow or join in the Standards groups column of the tables in the Proposals section.

This form may be the right place if you want to know:

• How particular situations may be affected by multiple proposals;
• If your use case is covered by a proposal.

While this is an opportunity for stakeholders to share feedback to the Chrome team directly, the themes or issues in your feedback may be aggregated for inclusion in the Chrome team’s public reports, without attribution.