- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Sat, 9 Feb 2019 15:55:32 -0800
- To: "public-dxwg-wg@w3.org" <public-dxwg-wg@w3.org>
It is important that we take care with our recording of comments and the responses from the working group. This is complicated greatly by the mix of comment methods between the comments mailing list and github. It is also complicated by the fact that we have multiple deliverables and subgroups. We would therefore like to better organize our treatment of comments and our record keeping so that we will be able to show W3C management a true picture of our outreach. This also becomes especially important as we move toward candidate recommendation status. To begin with, all comments and suggestions are to be considered and discussed by the working group. That doesn't mean that all comments will result in changes, but all must received a considered response from the group. Often comments indicate that more explanation is needed, and the group should respond with analysis and clarification, quite possibly adding clarification to the deliverable itself. (Note: co-chairs to add comments to plenary meeting agenda as project management points; subgroups to include them for in-depth discussion.) Comments should get an initial "thank you" that will let the commenter know that they've been heard. Each deliverable must have a designated "responder" who takes care of this. The working group should discuss the comment until it is clear if changes are needed or if a clarification should be sent. Before responding to a comment, a draft response needs to be approved by the working group so that the group's involvement is recorded in the minutes of the plenary where the response is approved. For our own record-keeping, we need a place where comments are recorded, such as a github wiki page where we can link to github or email comments. We suggest the following for our record-keeping: 1. name of commenter 2. community represented, if named 3. link to comment 4. summary of comment(s) 5. Link to meeting (resolution, if possible) approving response 6. Link to response (email or github) 7. Link to change (or "no change") For #4, each comment should have a few bullet points to indicate the salient content of the comment (e.g. suggests change from ex:term1 to nn:term2). Because we're coming to this a bit late, let's concentrate on current and future comments, and we can fill in the past ones when/if convenient or necessary. We'll put this on the next plenary agenda where we can finalize how we want to work with comments. -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 (Signal) skype: kcoylenet/+1-510-984-3600
Received on Saturday, 9 February 2019 23:55:58 UTC