Process for addressing public comments - w3c/wcag2ict GitHub Wiki

The W3C has a published Process for Formally Addressing an Issue. This process uses the guidance there and sets some expectations for our Task Force (TF) and timing of responding to issues. It ultimately leaves exact timing of responses up to the group to decide. Since AG WG doesn't have a specific written process, the following is a boilerplate process, subject to agreement with the TF participants.

The WCAG2ICT Task Force process for addressing public comments is as follows:

Whenever the TF has a draft under public review, time will be allotted in weekly meetings to address any public comments received. TF facilitator will be monitoring for those, but if a TF participant wishes to manually check, see the WCAG2ICT comments mailing list archives.  Comments also may appear in the GitHub issues list for our WCAG2ICT repository which TF facilitator will to tag with "public comment".   Responding to public comments:

  1. [Within 2-3 days of receipt] The TF facilitator will make an initial generic response to the sender. 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). The response will be drafted in a comment on this issue, marked, DRAFT RESPONSE until the Task Force reaches consensus."

  2. [Within 1 week of receipt] The TF 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:

    • [Within 1 week of receipt] 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. Also add a label on the issue as to which draft this comment was on (FPWD, 2nd draft, etc.) to help with filtering.

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

    • [Time determined by assignee] Draft an answer and potentially propose changes to the draft to address the issue (In the issue, labeled DRAFT RESPONSE and if there's a draft PR, include a link to it.)

    • [Within 2 weeks draft response completion] The TF reviews and approves the answer and, if any, proposed changes to the document.

    • Once the TF has approved the response, add the response to the GitHub issue and add a label "TF answer completed". If the issue was originally submitted via the comments email list, also send an email addressed to the sender and copy the [email protected].

    • 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. We may also add a label so we know we've addressed, but are waiting for confirmation.
  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).