Merge pull request #71 from patcg/recommendation-process-update

Recommendation process update

.editorconfig

@@ -0,0 +1,5 @@
+[*.html]
+indent_style = space
+indent_size = 2
+end_of_line = lf
+charset = utf-8

charter.html

@@ -269,7 +269,7 @@ <h3>Timeline</h3>
         </section>
       </section>
 
-        <section id="success-criteria">
+    <section id="success-criteria">
           <h2>Success Criteria</h2>
           <p>The WG will progress its normative specifications through the following
     standardization process:
@@ -281,20 +281,18 @@ <h2>Success Criteria</h2>
       Recommendation Snapshot</a>, and <a href="https://www.w3.org/2021/Process-20211102/#candidate-recommendation-draft">Candidate
       Recommendation Draft</a>. The WG does not intend to publish specifications as <a href="https://www.w3.org/2021/Process-20211102/#RecsPR">Proposed Recommendations</a>.
 
-          <p>To reach the Candidate Recommendation Snapshot stage, each normative
-            specification is expected to have <a href="https://www.w3.org/Consortium/Process/#implementation-experience">at
-              least two independent implementations</a> of every feature defined in the specification.
-            Interoperability of implementations will be verified by passing open test suites.
+    <p>There should be testing plans for each specification, starting from the earliest drafts.</p>
 
-          <p>Each normative specification should contain separate sections detailing security and privacy implications for implementers, Web authors, and end users.</p>
-
-          <p>There shall be a testing plan and open test suite developed that covers all functional
-          aspects of normative specifications developed by the WG.
-
-    <p>Normative specifications which have user-facing features should contain a section on accessibility that describes the benefits and impacts, including ways specification features can be used to address them, and recommendations for maximizing accessibility in implementations.</p>
-
-    <p>In considering features, the group will state, during the development of those features or in the text of the document, privacy implications. Proposals should clearly state privacy issues, how they intend to address those issues, and the advertising use cases addressed in each deliverable.</p>          
-        </section>
+    <p>To promote interoperability, all changes made to specifications in Candidate Recommendation or to features that have deployed implementations should have tests. Testing efforts should be conducted via the Web Platform Tests project.</p>
+
+    <p>Each specification should contain sections detailing security and privacy implications for implementers, Web authors, and end users, as well as recommendations for mitigation. There should be a clear description of the residual risk to the user or operator of that protocol after threat mitigation has been deployed.</p>
+
+    <p>Each specification should contain a section on accessibility that describes the benefits and impacts, including ways specification features can be used to address them, and recommendations for maximizing accessibility in implementations.</p>
+
+    <p>All new features should have expressions of interest from at least two potential implementors before being incorporated in the specification.</p>
+
+    <p>In considering features, the group will state, during the development of those features or in the text of the document, privacy implications. Proposals should clearly state privacy issues, how they intend to address those issues, and the advertising use cases addressed in each deliverable.</p>
+    </section>
 
       <section id="coordination">
         <h2>Coordination</h2>
@@ -308,7 +306,7 @@ <h2>Coordination</h2>
           <a href="https://www.w3.org/Consortium/Process/#RecsCR" title="Candidate Recommendation">CR</a> and is encouraged
           to proactively notify the horizontal review groups when major changes occur in a specification following a review.
           Additionally, the technologies this Working Group will be considering will be relevant for other standards development organizations
-          such that the group is encouraged to coordinate with the appropriate groups at the WHATWG, Ecma, and IETF as needed.
+          such that the group is encouraged to coordinate with the appropriate groups at IETF, and others as needed.
         </p>
 
         <p>
@@ -353,14 +351,11 @@ <h3 id="w3c-coordination">W3C Groups</h3>
 
         <section>
           <h3 id="external-coordination">External Organizations</h3>
-          <dl>
-            <dt><a href="https://whatwg.org/">Web Hypertext Application Technology Working Group (WHATWG)</a></dt>
-            <dd>WHATWG is a likely venue for standardization of new features. In particular, WHATWG standards include <a href="https://infra.spec.whatwg.org/">core web platform infrastructure</a> upon which new advertising features could be built.</dd>
-          </dl>
-          <dl>
-            <dt><a href="https://www.ietf.org">IETF</a></dt>
-            <dd>A number of IETF working groups are likely venues for standardization of protocol components that advertising features depend on and research groups are investigating issues that will feed into the designs this group will consider.</a>
-        </section>
+		  <dl>
+			<dt><a href="https://www.ietf.org">IETF</a></dt>
+			<dd>A number of IETF working groups are likely venues for standardization of protocol components that advertising features depend on and research groups are investigating issues that will feed into the designs this group will consider. The main group we will need to coordinate with is the <a href="https://datatracker.ietf.org/wg/ppm/">Privacy Preserving Measurement</a> group</a>
+		  </dl>
+      </section>
       </section>
       <section class="participation">
         <h2 id="participation">