[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: WS-TX TC Issues Process
I’ve updated the template based on
our discussion on Thursday’s call. I added in the issue raising
email: 1.
A statement at the top to
discourage discussion of the issue until it is assigned a number
2.
A link to the target
document
3.
The PDF line number(s)
Best
regards,
Colleen
-------------------------- Issues life cycle Raising an issue: - Issue is raised in email, with a description, indication
of which document and draft the issue targets, and a proposed resolution if
possible (one issue per email) - Issue is assigned a number (in sequence), logged, and
assigned a status of “review” (see below) by the issues list
coordinators - TC member raising the issue is assigned as initial owner - Issue is discussed via the TC list and in conference calls
/ f2f meetings as determined by the co-chairs, based on priorities set by the
TC - Ownership of the issue may be transferred to another TC
member if appropriate. Originator will be maintained in history. Issue status: · Review
Opened, but not yet accepted by the
TC. The co-chairs will schedule it on a meeting agenda as appropriate to
determine whether it is accepted or dropped. We’ve agreed to set a
low bar for issues, so this status is not intended to imply that a lengthy
discussion of each issue is required to determine if it is accepted or
not. This status implies that the TC has not reviewed to verify that the
issue is not a duplicate, etc. · Dropped TC determined it is a duplicate / is
not an issue / no action is required / or originator withdrew the issue.
The reason it is dropped should be documented in the issue history. · Active
Accepted by the TC as an
issue. In discussion. · Deferred
Accepted by the TC as an
issue. Discussion deferred (based on priorities, how this issue relates
to others, etc.). · Pending
TC has agreed on a resolution.
Conference call or F2F minutes should reflect the agreement and decision.
In the editors’ queue to be applied to the target document. · Done Editors have applied the agreed
resolution to the document. The change needs to be reviewed and accepted
by the TC. · Resolved Applied change has been reviewed by
the TC. · Closed TC has voted to approve the change
by voting to accept the draft to which the change was applied. ------------------------------------ Submitting an issue ------------------------------------ Send an email proposing the issue using the following
template: Subject: NEW Issue: [descriptive title] To: ws-tx@lists.oasis-open.org; Cc: coevans@microsoft.com; peter.furniss@choreology.com PLEASE DO NOT REPLY TO THIS EMAIL OR START
A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER. The issues coordinators will notify the
list when that has occurred. Target document and draft: Protocol: Coord / AT / BA Artifact: spec / SOAP / WSDL / schema / policy / all Draft: [For example: Coord spec working draft 1] Link to the document referenced: Section and PDF line number: [Include line numbers where possible. For
example: Section 3.1.2 CreateCoordinationContextResponse, Line 285] Issue type: [design or editorial] Related issues: [numbers of related issues, if any] Issue Description: [concise summary of the issue] Issue Details: [detailed description if helpful or required] Proposed Resolution: [proposed resolution and text if appropriate (including
section and line numbers indicating where the text would be inserted or what it
would replace)] Peter or I will pick the issue up and give it a number (in
sequence), assigning the individual who submitted the email as owner of the
issue. We will send an email to the list with the issue number once it is
assigned. Subsequent mail threads should use the Issue xxx: format
in the subject line, where ‘xxx’ is the issue number. Please include only one issue per email and do not engage in
discussing the issue until it is assigned a number so we don’t have
multiple impossible to distinguish ‘NEW Issue’ threads on the list. ------------------------------------------ Issues tracking mechanism ------------------------------------------ I propose a tracking mechanism using XML/XSL, based on the
WS-RX TC list which was derived from the W3C WS-Addressing WG: http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml We’ll request this location from OASIS for WS-TX: http://docs.oasis-open.org/ws-tx/issues/WSTransactionIssues.xml The issues list coordinators will update the tracking
document after every call or f2f. At the issue level, the following will be tracked: · Issue number · Target
document / artifact · Status · Description · Details · Related
Issues · Origin
(originator and link to originating email) · Owner · Proposal
“x” (one for each proposal) · Resolution
(e.g., Proposal “x” accepted on [link to conf call / f2f meeting
notes detailing the acceptance] |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]