This document describes the process used by the W3C Web Services Architecture Working Group in handling submitted issues tracked in the Issues Document. Issues to be considered by or regarding the documents produced but the Web Services Architecture Working Group should be reported to email@example.com (public archives). Discussion of open issues by members of the W3C Web Services Architecture Working Group should be held on the public mailing list firstname.lastname@example.org.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this series of documents is maintained at the W3C. .
This is a document of the Web Services Architecture Working Group which is part of the Web Services Activity. This document describes the processes and procedures to be used by the Web Services Architecture Working Group (WSAWG) for capturing, processing and closing issues. This document describes the intent of the WG to process issues in good faith, however, the Web Services Architecture Working Group is not bound to conform to the processes and procedures described in this document.
Comments on, and discussions of this document can be sent on the archived, public mailing list email@example.com.
2.1 Initial Capture and Acknowledgment
22.214.171.124 Item Number
2.2 Development: Post-Classification Action
3 Change Log
The Web Services Architecture Working Group is responsible for handling issues raised regarding Web Service Architecture and the documents produced by this WG. Due to the architectural nature of these issues, they affect not only a large number of W3C Working Groups, but also software developers, content developers, and writers and users of specifications outside the W3C that have to interface with W3C specifications. This process is designed to provide reliable communications between all of these stakeholders.
The WG is required by the W3C process to seek to resolve issues by consensus. We will seek, where possible, to satisfy the commentator, or in the cases where we cannot satisfy the commentator we will seek at least to ensure that the comments and our responses are documented fully. The Working Group will respond to commentators, answer questions, maintain an Issues Document that contains clarifications/corrections to the spec, and capture requests for future enhancements. The remainder of this document describes the process for doing this.
The Issues Document is a working document of the Web Services Architecture Working Group. It is not the permanent record of decisions and communications. The permanent records are the public archives of two email lists used in the process: firstname.lastname@example.org and email@example.com. The editors of the Issues Document will make their best effort to provide valid links to these archives.
The following procedure will be followed for addressing issues received by the WG. The Issues Editors will review the public archive http://lists.w3.org/Archives/Public/www-wsa-comments/ to identify points which require response from the WG. An item will be added to the Issues List for each point that needs to be tracked.
Items captured as issues are then developed by a member of the WG to prepare a proposal. The proposal is presented to the original commentator. When consensus has been reached on an issue, the final resolution is described and the issue is closed.
Any reference to "editors" below, is a reference to the Issues Editors.
Issues relating to the work of the Web Services Architecture Working Group and related deliverables will be captured from public archives http://lists.w3.org/Archives/Public/www-wsa-comments/ by the editors.
Note that questions and comments that do not require tracking will not be added to the issues list. Questions that do not require tracking include duplicates, those that have already been answered by the WG, or are outside the scope to the WG. This determination is at the discretion of the editors. Untracked questions and comments must still be responded to as described below.
Each new issue will be detailed with the following data:
The name and email of the originator captured in the form <a href="mailto:firstname.lastname@example.org">Dave Hollander</a> .
Short description of issue, including link to email origin of the issue. The description should paraphrase the originator's parameters comment to help assure the issue has been understood.
One of: Unassigned, Active, Closed, Postponed
Initially, the status is Unassigned until the WG addresses the issue.
The editors will send a email to the commentator to acknowledge receipt of each comment. Included in the email will be issue number or explanation of why the comment does not need to be tracked. These responses are copied to the email@example.com mail list and to the firstname.lastname@example.org mail list with the issue-number in the title to initiate discussion.
The WG shall review, adopt or reject new issues and assign responsible member. Once the classification of a comment has been approved, the editors updates the comment with the classification, and changes the status to be IN_PROGRESS."
The issue development process is designed to assure that the originator is actively informed regarding the resolution of the issue. All communications between the WG and originator must be recorded in email@example.com.
The following is the process for resolving each classified comment:
The status changed to Active when the WG assigns a WG member to be responsible for the issue.
The Web Services Architecture WG member assigned to guide the issue through the process. Captured in the form <a href="mailto:firstname.lastname@example.org">Dave Hollander</a> .
Issues are closed when the proposal has been accepted by the originator either explictly or due to a lack of response within two weeks.
The following is the process for closing each issue:
The status changed to Closed when the proposed resolution has been accepted.
The status changed to Postponed when the issue is determined to be out of scope for the current WG efforts.
A brief description of the final resolution to the issue with a link to the email acceptance of the proposal. The description need not be included if resolved as proposed. If the originator did not respond to the proposal within two weeks, indicate that with the phrase: "NO RESPONSE"
Originators of Postponed issues are notified of the reason for delaying action on the issue and the pre-conditions of when the issue may be reexamined.