Process for addressing public comments

The W3C has a published Process for Formally Addressing an Issue. This process uses the guidance there and makes the expectations for our TF and timing of responding to issues clearer.

Whenever we have a draft under public review, time will be allotted in weekly meetings to address any public comments received. I will be monitoring for those, but if you wish to manually check, here is a link to the WCAG2ICT comments mailing list archives: https://lists.w3.org/Archives/Public/public-wcag2ict-comments/.  Comments also may appear in the GitHub issues list for our WCAG2ICT repository which I plan to tag with "public comment".   As for responding to submitted comments, here's the process I propose, though I welcome feedback for improvements:

1. The facilitator will make an initial generic response to the sender within 2-3 days of receiving notification of the comment. The generic response will be similar to the following, as is appropriate to the comment(s):

   "Thank you for taking the time to review the WCAG2ICT public draft. Our task force will review your comment(s) and develop a response that we hope will address your concern(s)."

2. The facilitator will bring new issues submitted to the attention of the Task Force in the next weekly TF meeting.
3. Someone from the Task Force will self-assign to:

   • Open an issue in GitHub (if the submission came through the public comment email), and add in the text from the email submission, the contact email, and a link to the item in the public mailing list from where it originated.

     NOTE: If there are multiple comments listed in the email for multiple sections, we need to split the comments into multiple issues.

   • Draft an answer and potentially propose changes to the draft to address the issue (either via a PR or via our WIKI)

     NOTE: Please refrain from posting an answer on the issue until the Task Force has reviewed and approved the response.

   • Once the TF has approved the response, add the response to the GitHub issue and send an email to the sender (if the issue was originally submitted via the comments email list).

   • Await a response from the submitter whether this is acceptable or not.

     • If accepted: Take appropriate action to either further tweak changes to the WCAG2ICT document and/or close the issue, if accepted.
     • If not accepted: Try to further understand their concerns and attempt rework of response or document changes and, once again seek TF approval and send the response to the issue submitter once the TF approves the newer response.
     • If there is no response as of publication of the next public working draft, we will close the issue with a comment indicating they should reopen the issue if the new public working draft doesn’t address their concern.
4. The TF reviews and reaches consensus on the response and PR (if one was necessary to address the issue)
5. The response is either posted in the issue (when originated in GitHub) with and @ mention of the issue submitter’s id, or sent as a response via email (if the issue originated from the comments list email).