Procedure for Processing Comments

Processing Comments for WCAG 3 First Public Working Draft This the procedure we want to follow for effectively responding to the comments by email and the Github Issues filed for WCAG3. This procedure will be adjusted to meet the volume and complexity of comments. This procedure will continue to evolve as we get more experience with the comments.

Useful links

DRAFT Answer Templates

Triage Response: Thank you for your comment. Project members are working on your comment. You may see discussion in the comment thread and we may ask for additional information as we work on it. We will mark the official response when we are finished and close the issue.
Email Response: Thank you for your email comments We have moved your comment into [link]Github Issue #[#] to manage and discuss it. You can follow the discussion there if you want. When we have a resolution, we will email you our response.
We did it. Thank you for your response, we have implemented your suggestion for the next draft. Please see [link to pull request]
Thanks for PR, but can't use it Thank you for your response, we have implemented your suggestions for the next draft. We appreciate the pull request, but because of W3C rules on intellectual property, we can't accept a PR from people who haven't joined the working group or community group.
Overtaken by events. Thank you for your comment. We have closed this issue because we believe this issue has been addressed or is no longer relevant. Please see [link to relevant pull request or master]. If you believe this issue should be reopened, please open a new issue and reference this issue. If you have trouble, contact a WCAG 3 editor.
Not changing After careful review and discussion, we have decided to not to implement your suggestion for the following reasons: [list reasons]
Not in the next draft Thank you for your comment. This is an interesting idea that the group will consider in a future draft, but it is not in scope for the next draft.
Thanks for the compliment Thank you for your comments. It is helpful to know what people like as well as what they want changed. We appreciate the time it took to write this.

Triage

Use Github Filter for Triage link to bring up a list of comments that need triage
Select the issue name to open the first issue
Read the issue - if the assignment is obvious, go to step #2. Otherwise, assign a label "action: editor triage".
Assign labels - see Label Assignments section.
Copy the Triage response comment into the Github Issue : Thank you for your comment. Project members are working on your comment. You may see discussion in the comment thread and we may ask for additional information as we work on it. We will mark the official response when we are finished and close the issue.
Select the Comment button (not the Close Issue button).
If the issue is not in English, use a translation tool to copy an English version into a comment. Start it with "Copied from Translation Tool".

If you have questions, please email the Silver Editors email list.

Label Assignments

There are 4 types of labels we are using:

action (green) - what is needed before work can start
status (purple) - indicates that the work is in process
subgroup (light blue) - who the issue is assigned to
section (dark blue) - what section of the document the issue is about

There are other W3C-generated issue labels, but don't assign those labels. They are used for special purposes to refer issues out to other W3C working groups. We don't want to do that yet.

Labels for Triage

For most issues, you will assign two labels: "status: assigned to subgroup" (purple) and the (light blue) "subgroup: [whichever you think it should be]" or subgroup: editors if it doesn't belong to a subgroup.
Please assign all conformance related issues to the editors, not the conformance options subgroup.
Subgroup Editors: If you assign to the editors and you know that it refers to a particular section of a document, you can add a label to that section.
If the comment has a number of topics in one issue, use the green label "action: break into separate issues"
If the comment is a typo or minor editorial change, use the green label "action: editorial - fix". Don't accept pull requests.
If the comment doesn't ask for changes, use the purple label "status: comment - no change"
If the comment is asking/suggesting new guidelines, use the purple label "status: enhancement"
If you aren't sure, assign a label "action: editor triage".
If the comment is from a participant in Silver Task Force or Community group add a label "internal comment"
If commenter is asking a question that we need to answer use action: answer question
Topic Labels
- Use section: [document section] - for comments on specific sections of the document.
- Use section: usability issue for comments related to ease of use or use by people with disabilities
- Use section: Requirements for issues on the WCAG3 Requirements document
- Use section: other documents for issues related to documents outside the FPWD. Howto and Method comments should already be assigned to the subgroups
- Use "section: other" for issues that cross sections or are generic

Responding to Issues

Labels for Processing Issues

If it is a simple question that needs the "sense of the group" or it is ready for group discussion, use the green label action: discuss@meeting
If we do not have the expertise to address this issue and need outside assistance , use the green label action: expert help

Responses to Use for Answering Issues

Thank the poster for participating/contributing.
Ask a clarifying question, if necessary
Responses

Alert the participant to any of the live public forums that will be relevant to their comments, like the Github issue discussion (link to issue) or Silver Email archive where meeting minutes and discussion are posted.
If appropriate, provide excerpts from WCAG3 or related published material.
Responses to Avoid
- Any value judgement on the content of the post. (Like “Good point! or “That wouldn’t work.”)
- Agreeing or disagreeing with any ideas.
- Comments indicating that we will or won’t consider something.
- Suggestions about any future actions the working group will take.

Migrating Emails to Github

Copy the email into new Github issue.
- Title the issue "Email: [subject of the email]" (see Issue 412 as an example)
- Start the issue with "Comment from Email:" and link that phrase to the email archive
Copy the link to the email from the email archive into the issue
- AGWG public comments archive
- general Silver archive
Reply to the email with a link to the Github issue.
- Select Respond from the email archive page.
- Copy the commenter email address into the To: and delete the list name
Triage the Issue:
- Assign the labels as detailed in the Labels section
- Paste the Triage message below into a Github Issue comment.

Email Response:

Thank you for your email comments. We have moved your comment into [link]Github Issue #[#] to manage and discuss it. You can follow the discussion there if you want. When we have a resolution, we will email you our response.

Email response multiple issues

Thank you for your email comments. We have moved your comments into Github Issues to manage and discuss them. You can follow the discussion there if you want. When we have a resolution, we will email you our response.

Triage Response:

Thank you for your comment. Project members are working on your comment. You may see discussion in the comment thread and we may ask for additional information as we work on it. We will mark the official response when we are finished and close the issue.

Process Draft Ideas

Triage

A group of 2-3 members of the leadership team or individuals assigned by the leadership team will be responsible for triaging issues (triage team).
Any comments that come in through email will be added to Github.
Each week the triage team will review, sort, label and assign new comments and issues. The triage process described below may evolve.
- The triage team will respond and close issues that have been completed or can be completed by an editor in the moment (e.g. typos).
- Editors will complete editorial-only tasks as they triage.
  - All editorial changes will be added to an editorial changes branch.
  - While a link to the current changes will go in the survey each week it will only contain typos and other small editorial changes.
  - The editorial branch will be periodically merged into the main branch
- Comments will be labeled by the action the triage team recommends (editorial do, editorial won't do, discuss in group, etc)
  - One color for actions, another for sections, another for guidelines, and one for other
  - The names will been edited to add "action:, section:, guideline:" so they sort alphabetically.
- Comments will also be labeled by subject or guideline name so that it is easier to bring up all the comments on a topic and compare them together.
- Leadership will give a list of comments by recommended disposition to the leadership each Monday and the Silver meeting on Tuesday.
- Leadership will assign any substantive comments to a member of the leadership team or the task force member best suited to draft a proposal or an answer.
  - Comments that lead to substantive changes will be in a separate survey question from the smaller issues

Drafting (change or rational of no change)

Subgroups or editors will work on issues assigned to them
- Draft responses and changes can be done in github, google docs or another tool. The tool will be selected by the subgroup so it is accessible to all participants.
  - All Github updates will be to a branch, not the main (master) branch. If working in GitHub, label the response "Draft Response:" at the beginning and make any changes on the new branch.
  - If working in another tool, work with an editor to get the proposal into Github
  - Once issues are ready for survey, they will be labeled "Ready for survey"
Issues should be chnaged from "assigned" to "ready to survey within 2 weeks of being assigned
- If an Issue can't be made ready to survey in that time frame, the subgroup leader or person assigned should alert the leadership team by email to public-silver-editors@w3.org. Please include recommendations of next steps such as re-assign, discuss in larger group, almost there extend the deadline)

Survey and Approval

Surveys and Discussion
- Each week, issues that are ready for review will be labeled "In weekly survey"
- This list will be sent in a one question survey on Wednesdays to Silver and AGWG. These groups will have an opportunity to review the queue and identify any issues responses or changes that are cause for concern. We request responses by Friday for planning purposes but the survey will be open until Tuesday.
- The survey results will be discussed at a joint meeting of the Silver Taskforce and AGWG working group at the first half hour of each AGWG meeting.
  - Discussions will focus on directions and concepts. The editors or subgroups are responsible for drafting language based on the discussion. The goal is to minimize wordsmithing in meetings.
- After discussion, if more work is needed, a summary of the changes needed and a link to the minutes will be included in the issue. The issue will be sent back to the person/group working on it.
Closing Issues
- Link to the pull request and survey in each issue
- Link to the relevant issues in the pull request using the "fixes" or "closes" syntax. Syntax documentation.
Once an issue passes a survey or the post survey discussion, it will be labeled "Ready for merge"
Editors will close the issues and merge the changes into the main branch