Project task: Set up and track horizontal review of the draft

[maryjom]

Questions

First need to figure out some things. Reading the wiki content on horizontal review answers some of the following questions:

• Horizontal review guidance indicates a self review may suffice (I bolded that text below). If so, what are the criteria this should be self-reviewed against?

  As a specification is being prepared for, and moved along the Recommendation Track, the group responsible for the specification MUST solicit a horizontal review from each of the horizontal review groups (in many cases, submitting a self-review to the reviewing group will satisfy this requirement). However, the guidance does not link to any criteria for that self-review.

NOTE: If we determine we can self-review, we can stop here and simply document the criteria and results we reviewed against.

If we really do have to send this out for horizontal review, there's more questions:

• Determine which version of the editor's draft goes out for horizontal review (FPWD version or the second publication we're about to send out.)
  Based on the W3C guidance, it might be best to send out the newer publication as having a number of substantive changes prompts another horizontal review.
• Can the version we send to the AG WG for review prior to publication be what we send for horizontal review, or must the AG WG approve the version that goes out for horizontal review?
  No, this can't be done early. It has to coincide with an actual draft publication.
• Can the horizontal review be done in parallel with the next public review, or are we supposed to hold up this next publication until horizontal review is done? (Since we didn't send out the FPWD for horizontal review.)
  Looks like when we publish the next draft we can send it out for horizontal review.

  When the First Public Working Draft of a specification is published, the Team must ensure that a notification is sent to [email protected].

• How long must we give for horizontal review?
  Document says a minimum of 60 days. Assume this is calendar days, not working days. Correct?
• Does TF facilitator draft the email that will get sent out for the horizontal review, or does AG WG leadership?
  Guidance says that the email is sent by the working group publishing the draft for review, but I imagine it's up to the working group as to who drafts the email contents.
• Is there a template for the horizontal review email?
  Guidance doesn't point to any template, but there may be one in existence somewhere. Who would know this? Shawn?

Horizontal Review steps to complete

1. • Draft the horizontal review email

2. Send notifications of horizontal review to:

   • Accessible Platform Architectures Working Group
   • Internationalization Working Group
   • Privacy Interest Group
   • Technical Architecture Group

3. Received a receipt acknowledgement from:

   • Accessible Platform Architectures Working Group
   • Internationalization Working Group
   • Privacy Interest Group
   • Security
   • Technical Architecture Group

4. Review period

   • 60 day review period begins 2 July 2024
   • 60 day review period ends @@add date (In our request we gave until 6 Aug 2024, but if 60 days is needed that ends on 2 September 2024.

5. List of resolved issues received from horizontal reviewers (check if answered and resolution was accepted)

   • @@add issue number here and add documentation of agreement (link)

   TAG

   • Responded they had no issues to open

   Security

   • Issue 508: Ideas for writing up security considerations (received on 10 September)

   Privacy

   • Issue 446: Privacy Considerations (received on 18 July, text agreed with issue author on 22 July in a comment in the Google doc, reached TF resolution on 8 August, and merged into the editor's draft on 16 July)

   Internationalization

   • Issue 463: Programmatically determine the language of text (received on 2 August) - Agreed to changes in Issue 463 comment

   Accessibility

   • Issue 464: Suggest slight clarification of audience and outcomes (received on 6 August) - Changes agreed to in Issue 464 comment.
   • Issue 465: Seeking clarity for key term 'underlying platform software' (received on 6 August) - Changes agreed to in Issue 465 comment.
   • Issue 466: Closed functionality list - suggested additions (received on 6 August) - Changes agreed to in Issue 466 comment

6. List of unresolved issues received

   • @@add issue number here and with evidence that a determined effort was made to find a resolution.

[daniel-montalvo]

Thanks for putting this together, @maryjom . Answers below.

Questions

First need to figure out some things. Reading the wiki content on horizontal review answers some of the following questions:

• Horizontal review guidance indicates a self review may suffice (I bolded that text below). If so, what are the criteria this should be self-reviewed against?

  As a specification is being prepared for, and moved along the Recommendation Track, the group responsible for the specification MUST solicit a horizontal review from each of the horizontal review groups (in many cases, submitting a self-review to the reviewing group will satisfy this requirement). However, the guidance does not link to any criteria for that self-review.

• Accessibility
• Internationalization
• Security, privacy, and TAG

Most of these are in the GitHub issues template and are required to open a Horizontal Review issue.

NOTE: If we determine we can self-review, we can stop here and simply document the criteria and results we reviewed against.

If we really do have to send this out for horizontal review, there's more questions:

• Determine which version of the editor's draft goes out for horizontal review (FPWD version or the second publication we're about to send out.)
  Based on the W3C guidance, it might be best to send out the newer publication as having a number of substantive changes prompts another horizontal review.

+1 to sending the newer one, which is the complete one, as it contains all 2.1 and 2.2 SCs guidance

• Can the version we send to the AG WG for review prior to publication be what we send for horizontal review, or must the AG WG approve the version that goes out for horizontal review?

I think AGWG should approve publishing the second draft, and then we can send it for wide review.

No, this can't be done early. It has to coincide with an actual draft publication.

• Can the horizontal review be done in parallel with the next public review, or are we supposed to hold up this next publication until horizontal review is done? (Since we didn't send out the FPWD for horizontal review.)
  Looks like when we publish the next draft we can send it out for horizontal review.

  When the First Public Working Draft of a specification is published, the Team must ensure that a notification is sent to [email protected].

Since W3C Process does not require Notes to go through HR, I think we can do wide review and HR in parallel.

• How long must we give for horizontal review?
  Document says a minimum of 60 days. Assume this is calendar days, not working days. Correct?

Yes.

• Does TF facilitator draft the email that will get sent out for the horizontal review, or does AG WG leadership?
  Guidance says that the email is sent by the working group publishing the draft for review, but I imagine it's up to the working group as to who drafts the email contents.

Yes, it's upt to us (meaning Chuck, you, and myself) who drafts it, but it goes out on behalf of AGWG.

• Is there a template for the horizontal review email?
  Guidance doesn't point to any template, but there may be one in existence somewhere. Who would know this? Shawn?

For specifications this is an automated process. The email gets sent based on what Team has already submitted for publication. For Notes this has to be a manual process. We can just base on one of the requests that are sent to Public review announce.

[pday1]

The Accessibility checklist calls out high-level requirements (including some from WCAG 2.0). I would assume that the final rendered HTML (after all the markdown conversion and includes) should meet WCAG, so I would hope that we meet all the entries in this checklist.

[daniel-montalvo]

@pday1 The W3C Publication Rules tests make sure that this is the case. Any document that is published to W3C's TR space needs to pass these tests, so there is nothing you as editors have to worry about at this point. I'll make sure these are passed before publication.

[pday1]

I also had a look through the internationalisation and security checklists and cannot see anything obvious that we would fail on. Then again, I'm not really an expert in either of these subjects, so could be proved wrong in the next few weeks!

[daniel-montalvo]

Please see related #430 where we'll track comments from the Horizontal Groups.

[maryjom]

Closing the issue regarding setting up the horizontal review. The rest of the horizontal review tasks are tracked in Issue 430.