This specification outlines how to submit change requests to documents maintained by the TC and the process by which those change requests, also called issues, are resolved.
The submission and resolution process is broken into three parts:
Core Issues Process - Deals with the normative aspects of how to submit an issue, get it on the issues list and get the issue marked as resolved. This section also discusses normative requirements on the TC to resolve all open issues before voting on a committee specification. This is the heart of the issues process and has three steps - create an issue by sending in an e-mail, providing a brief window where the issue can be withdrawn or changed based on feedback and then resolving the issue with a vote of the TC.
Mechanics of Maintaining the Issues List - The second part deals with the mechanics of the issues process. Specifically, what information is to be minimally recorded in the issues list and the subject lines for e-mails to enable them to be automatically picked up by a mail sniffer and associated with the right issue.
Best Practices - Describes non-normative behavior meant to enable the TC to make progress on issues. Specifically, the creation of a fortnightly weekly issues call and 'house cleaning' issues motion, a format and process for sub-groups to use when motioning to resolve issues, a description of best behavior when submitting an issue for resolution and a discussion of the use of champions to push issues to resolution.
The specification also includes four appendixes. The first provides a brief summary of the issues process. The second describes some nifty macros provided by the issues process software that can be used in postings. The third is a list of requirements that motivated this document. The last is a list of changes made to this document.
The document is structured such that normative requirements are all placed into gray squares. All other text is non-normative.
Issues Process Document - DRAFT v1.6
1.1 Issue
Editor & Issue Process Document Editor
2 Mechanics of Maintaining the Issues
List
2.2.1 Format
for Submitting an Issue
2.2.2 Format
for Referencing an Issue
2.2.3 Format
for Proposing a Vote on an Issue
3.1 Submitting
Issues for Resolution
4 Appendix - Issues Process Summary
5 Appendix - Neat Issues Posting
Tricks
Issue - Encompasses any work item that needs to be tracked by the TC including: requirements, unresolved technical issues, requests for changes to specifications, etc.
The issues process consists of two mandatory elements - the creation of an issue and the resolution of an issue.
An issue is created by sending mail to the issues editor who then has up to seven days to add the issue to the issue list. From the time the issue is submitted until it is added to the issues list the submitter may withdraw or change the submission. Once the issue is added to the issues list the issue editor will assign the issue a unique ID and put it into the issues list. When an issue is created it automatically has the status of OPEN.
Besides OPEN the only other available status for an issue is RESOLVED. The only way to change an issue's status is by an approved motion. So when an issue is first created it is automatically OPEN and can only become RESOLVED if there is a successful motion to that affect.
If the TC adopts this specification then the TC will be prohibited from voting on the approval of a committee specification if any issues have the status of OPEN. This prohibition assures that all issues will be resolved.
This is a living document that will change as needed throughout the lifespan of the TC. Any normative changes to the document require a vote of the TC but non-normative changes can be made at the discretion of the issue process document editor.
The issue editor's job is to maintain the issues list. That is, to receive issues via e-mail, create new IDs for each issue, update the issues list, etc. Ideally just one person will perform this position but that person will have designated backups in case they aren't available. As the issue editor job is purely procedural there is no need to elect the issue editor, the chairs can appoint both the editor and any designated backups.
One of the issue editor's key goals must be to make themselves replaceable and to guarantee that the issues process is transparent. Therefore all processes, files and other mechanisms used to maintain the issues list needs to be fully documented and all source files and mechanism available so that everyone can see exactly how the issues process works and anyone can step in and perform the duties of the position.
The issue process document editor is the editor of this document and is responsible for its maintenance. The issue process document editor records any changes to the normative process agreed to by the TC and has the exclusive authority to make non-normative changes to the document. Since the issue process document editor position is purely procedural the chairs can appoint the editor without a TC vote.
|
· An issue editor MUST be appointed to maintain the issues list by the chairs. · The chairs MAY re-assign the position of issue editor at their discretion. · The chairs MAY assign alternate issue editors during times when the primary issue editor is not available. · The issue editor MUST edit the issues list following the rules specified in this document. · The issue editor MUST keep the issues list and all related materials necessary to maintaining the issues list checked into the OASIS document repository used by the TC. · An issue process document editor MUST be appointed to maintain the issues process document by the chairs. · The issue process document editor MUST maintain this document and assure that it faithfully reflects the normative decisions made by the TC as well as the actual process used to maintain the issues list. · The chairs MAY change, replace or name backups for the issue process document editor at their discretion. · Once this document is approved by the TC normative changes to the process described here MUST NOT occur without formal approval by the TC but non-normative changes MAY be made at the discretion of the issue process document editor. |
An issue begins life when a TC member submits an issue to the issues editor via e-mail.
Note: Originally we had people mail in their issues to the general mailing list and the issues editor would then create the issue and send an announcement to the general mailing list. The announcement would have a subject line as defined in this document so that any responses to the announcement mail would automatically be picked up by the issue tracking software and added as a link to that issue. In practice however people kept responding to the original mail requesting that the issue be created. Since an issue ID hadn’t been issued yet there was no way for the issue tracking software to pick up and track responses sent to the original request to create the issue.
The group then thought that they would create a dedicated mailing list where people could submit issues. The mailing list would let any TC member submit mail but only the issues editor could receive mails. However, the mailing list would be archived. This would provide a public record. But setting up a mailing list in this way proved beyond OASIS’s technical capabilities.
So the final agreement was that all requests to create new issues would be sent directly to the issues editor who would then send an announcement out to the mailing list. Although this mechanism does provide some latitude for abuse by the issues editor it was felt that the scope of abuse was small and anyone so abused would make sure everyone knew what had happened.
The issue editor may wait up to seven days before adding an issue to the issues list. During that time the issue editor or other interested party may contact the issue submitter to discuss any problems with the issue, such as it being a duplicate or not understandable.
During the period from when the issue is first submitted to when it is added to the issues list the issue submitter and only the issue submitter may amend the issue submission either changing or withdrawing it. It is the issue editor's sole discretion to determine how soon to add the issue to the issues list so long as the issue has been added within seven days of the original submission.
When an issue is posted to the list the issue editor will create a unique ID for the issue and an entry for the issue in the issues list. The issue editor will send an announcement to the main issue list when an issue is created.
The only normative aspect of an issue is its status, which is either OPEN or RESOLVED. When an issue is created its status is automatically set to OPEN. An issue's status can only be changed by a vote of the TC. It is possible for the TC to vote to change an issue's status to RESOLVED and then to later change it back to OPEN.
Anyone can propose a motion at any time to change the status of an issue. No special standing or status or procedure is needed to propose such a motion. Although a number of best practices will be proposed later in this document none of those best practices are normative therefore anyone, at any time and for any reason can propose a motion to alter the status of an issue. Note however that there is an expectation that members of the TC will follow the best practices and those who do follow the best practices will be seen most favorably by the group as a whole and the chairs in particular.
In order to guarantee that all issues will be resolved the TC is prohibited from voting on the creation of a committee specification if any issues are unresolved. A committee specification is the official approval a TC gives to a spec when declaring it completed.
It is expected that when the TC believes it is sufficiently close to a committee specification a vote will be held to amend this document so as to raise the bar to introducing a new issue. For example, the TC may change the process in this document such that a new issue cannot be raised unless approved by a vote of the TC.
|
· The issue editor MUST accept all issues submitted to them via e-mail and add them to the issues list. · The issue editor has sole discretion of when an issue is added to the issues list but the issue MUST be added no more than seven days after the issue was initially submitted. · During the period from when the issue is submitted to when it is added to the issue list the submitter MAY choose to withdraw or change their submission. · When an issue is added to the issues list the issue editor MUST assign the issue an ID that has not yet been assigned to any other issue. · When an issue is first added to the issues list the issue editor MUST send an announcement with the issue's description and issue number to the main TC mailing list. · The issue editor MAY add issues from sources other than the issues mailing list. · When an issue is first created its status MUST be set to "OPEN". · The status of an issue MUST NOT be changed unless an approved motion by the TC specifically instructs a change. · The TC MUST only set the value of the status of an issue to either OPEN or RESOLVED. · The TC MUST NOT approve the creation of a committee specification if any issues have a status other than RESOLVED. |
Under other circumstances we would use a bug tracking system such as Bugzilla to track various issues and their status. But OASIS does not officially support such a mechanism and setting one up would appear to cause any number of complications especially as the issues list is a normative document and therefore needs to be kept under the control of OASIS. As such the TC is forced to define its own mechanism to maintain, update and make available in a human readable form the issues list.
This section describes what information is to be recorded by the issues list and how to create e-mails that will be automatically tracked by the issues list.
Each issue in the issues list will contain the following information. Fields marked * are always present, regardless of where the issue is in its lifecycle. Other fields in addition to these may be present during temporary misalignment of the issues list and this document.
|
Field |
Description |
|
Issue ID* |
The ID for the issue |
|
Title* |
The issue’ |
|
Status* |
This provides the normative status of the issue, currently only two values are supported - OPEN and RESOLVED. |
|
Categories |
Different issues will be of interest to different sub-groups of the TC. To enable those sub-groups to track issues of interest they can ask the issue editor to place a value into the categories entry that they can then do searches on. The category field is defined as a comma delimited string so that if multiple sub-groups are interested in the same issue they can all place their identifiers into the category field. |
|
Date Added* |
The date the issue was added to the issues list. |
|
Origin |
Usually, a hyperlink to the source of the issue, typically the e-mail that caused the issue to be opened. If the issue came from a non-archived source, a text field saying what this was (e.g. “email direct to issue editor”. |
|
Submitter* |
The person or persons who caused the issue to be created. |
|
Date Submitted |
The date the issue was originally submitted (as opposed to the date when it was added to the issues list) |
|
Champion |
This value is non-normative and will be described in the best practices section of the document. |
|
Document |
An identifier to specify what group document the issue is requesting a change to. |
|
Description* |
This is a succinct description of the issue. The same considerations as described for setting the value of the title also apply here, e.g. the issue editor should listen to the consensus of the group is writing the short description but in the end it is up to the issue editor to decide what text is placed there. |
|
Proposed Resolution |
A solution to the issue, that has not yet been subject to a TC vote, but which prima facie could be voted as the resolution of the issue. May be a hyperlink if the text is substantial. The absence of this field does not imply that no proposal has been made. More than one link may be listed when there are multiple competing proposals. |
|
Resolution |
A short description of why the issue was closed. Typically this will be cut and pasted from the resolution motion or will be a hyperlink if the text is substantial. If the issue isn't resolved then this field will be absent. |
|
Links |
A set of hyperlinks to resources of relevance to the issue. As with title and Description the issue editor should set the values of the links as directed by the group but the editor has the final decision as to what will be pointed to. The links will include archived emails sent to any of the TC lists that have a subject line of the defined pattern (see below) |
|
Changes |
A list of changes made to the entry along with the date of the change and a brief description of the change |
Only two parts of an issue's entry are normative in the sense that they can control what the group may do, the Issue's ID and the status. All other values exist only for the convenience of the TC and therefore the exact values they are set to have no normative relevance. In order to avoid unproductive debate regarding non-normative values the issue editor is given unilateral control over all the non-normative values except champion, which is set as directed by the chairs.
|
· The issue list MUST minimally contain Issue ID, Title, Status, Categories (if any are defined), Submitter, Document, Description and if the issue is of status RESOLVED, Resolution. · The issue list MAY contain additional fields as the issues editor sees fit. · The title is a short description of the issue and SHOULD be specified based on feedback from the TC but the issue editor has the exclusive right to decide what the title will be. · The Status field describes the normative status of the issue and MUST contain the current value of that status. · The Categories field is used to provide non-normative classifications for an issue and SHOULD be specified based on feedback from the TC but the issue editor has exclusive right to decide what the category values will be. · The Document field MUST identify the document that the issue is requesting a change to, the value will be an identifier chosen by the editor to identify the relevant document. · The Description field provides a one-paragraph succinct summary of the issue and SHOULD be specified based on feedback from the TC but the issue editor has exclusive right to decide what the short description will be. · If the issue is resolved then the Resolution Motion SHOULD contain a hyperlink to the official record of the motion that caused the issue to be resolved. · If the issue is resolved then the Resolution Description SHOULD contain a brief description explaining why the issue was resolved, it is up to the sole discretion of the issue's editor to decide what will be placed in this filed but its value SHOULD be based on the text of the motion that caused the issue to be resolved. |
Because OASIS does not directly support the use of a bug tracking system such as Mozilla we have to use the only forum available to us to publicly post comments about an issue - e-mail.
It is expected that the TC will have access to software that can sniff the e-mail logs and generate HTML documents that associated relevant e-mails with particular issues. To enable the sniffer to work email subject lines need to follow the structures specified below. Those who do not properly structure their subject lines may not have their e-mail associated with the appropriate issue.
The issue editor will create new issues for all issues received directly via e-mail. In the worst case where the issue is completely indecipherable and if during the review period the submitter refuses to clarify the mail then the issue editor will create a new issue, put in an ID, put in a link to the e-mail and set the other values as best as possible. It will be up to the TC to figure out the issues meaning and to eventually vote that its status be changed to RESOLVED.
The title of an e-mail that is proposing a new issue should be 'New Issue' followed by a dash followed by the proposed title of the issue. This makes it easier for the issue editor to spot new issues in their mailbox.
Minimally the body of the e-mail should contain a short description. The e-mail may also contain suggested categories, champions and links. It is worth noting that only the chairs may appoint champions so by including a champion in the body one is making a suggestion to the chairs. As always it is up to the discretion of the issue editor to decide what values to put into the various fields for the issue.
Since only the issue editor will receive the email, the email should not include any general discussion or supporting material. Such should be sent as follow-up to the announcement message, where it will be received by all those subscribed to the discussion list, and where the issue list building software can recognize follow-ups by the presence of the issue ID. It is not advisable to cross-post such an email to other lists as the software will not necessarily pick up the follow-ups in the absence of the issue ID in the subject line.
E-mails sent to the issues editor requesting the creation of a new issue SHOULD take the following form:
|
Subject Line: New Issue - Suggested Title (10 words or less) Body: Categories: A comma delimited list of suggested category names. May be absent. Document: The document the issue is about, e.g. use cases, language specification, etc. Description: A succinct summary of the issue. Champion: Name and e-mail address of proposed champions, may be absent. Use Cases: Links to any relevant use cases, may be absent Links: References to any relevant existing archived e-mails or other resources, may be absent.
· The issue editor MUST add issues received by the issue editor via e-mail to the issues list even if the submission does not match the required submission format. · The email to create a new issue SHOULD NOT contain extensive discussion beyond the description. |
When discussing an issue in any of the group's mailing lists one can use a special subject line to identify that the mail should be included in a list of relevant mails about an issue.
The subject line will look like "Issue - 2 - Why fixing this really matters", or be a follow-up to such a subject (i.e. the subject may contain “Re:” and [<groupname>] before the Issue – ID -).
Note that only a single ID may be referenced. It is tempting to allow for more than one ID to be specified but this all but guarantees horrendous cross-issue postings that will quickly render the linking mechanism useless.
Also please note that the issue editor is under no obligation to hunt down e-mails about an issue and get them cross-linked into the issues list. Link relevant e-mails, even using an automated tool, to issues they are related to is a convenience, not a normative function of the TC.
|
· An email discussing an issue sent to any of the TC lists with the subject line structured specified below, WILL normally cause an entry to be added to the Links field of the issue linking to the archived copy of the email: Subject Line: Issue - [Issue ID] - [Random Text – usually the title] |
When someone wants to call for a vote on an issue they should send out an e-mail with a subject line like “Issue – 2 – Proposal for Motion”. The body of the e-mail should then provide a brief description of the issue, an explanation of the alternatives that were considered for resolving the issue and why the proposed alternative is best followed by the wording of the motion that is to be made.
|
· When submitting an e-mail to propose a vote on an issue the subject line of the e-mail SHOULD be: Subject Line: Issue – [Issue ID] – Proposal for Motion · The body of an e-mail requesting a vote on an issue SHOULD contain a brief description of the issue, a brief description of the alternatives considered for solving the issue and why the one to be proposed is best and finally the exact wording of the motion. |
This section documents best practices. While the group is encouraged to follow the behaviors outlined in this section nothing in this section is normative and therefore nothing in this section puts any mandates on the group's behavior.
When proposing a motion to resolve an issue the person making the motion should first send out a motion proposal as described in section Format for Submitting an Issue. If such a mail is sent out at least one week prior to a TC meeting then the chairs will make sure to include the motion in that meeting’s business. If the mail is sent out less than one week prior to a TC meeting then the chairs may choose to delay bringing the issue up until the TC meeting immediately following the next TC meeting. If the chairs do decide to include an issue that was provided less than a week before the meeting and anyone objects to having the motion because of a lack of time for review then the chairs will delay bringing up a motion on the issue until the next TC meeting.
The reader is reminded that none of the previous is normative but rather reflects the intentions of the chairs.
It is recommended that the TC make available a telephone bridge at a regular time every fortnight for one hour where interested members of the TC can come together to discuss submitted issues.
The first agenda item of the call will be to identify people to review issues in order to assure that an issue is not a duplicate and is well-formed.
Should an issue, in the opinion of the voluntary reviewer(s), be either a duplicate or mal-formed the reviewer(s) will contact the issue's creator directly and discuss the situation. The goal is to get any problems with a submitted issue resolved within the seven-day submission window so the submitter can make changes or withdraw the issue before the issue is added to the issues list.
The second agenda item on the call will be to find volunteers to put forward and second a motion to set the status of issues to RESOLVED that in the opinion of those present on the call should be resolved due to inactivity, the issue being a duplicate, the issue being completed, the issue being out of scope, etc. The actual criteria to be used are at the sole description of whoever is putting forward the motion.
The motion will be a block motion that will include all the issues to be RESOLVED. The form of the motion will look something like:
Move to set the status of the following issues to resolved:
[Issue ID] - [Issue Title] - (Issue Inactive | Duplicate of [Issue ID] | Withdrawn | Out of Scope | Work Concluded | Indecipherable)+ - Link to Issue Entry
The block motion will then be written up by the volunteers and forwarded to the chairs to be put on the agenda for a group conference call. The block motion should be made available for at least two full weeks for review by the group before being put forward for a vote.
The reader is encouraged to keep in mind that all of the previous behavior occurs on a voluntary basis and block motions can be motioned by anyone at anytime and for any reason. If the volunteers decide to not follow the agenda or to include items in the block motion that do not meet the previous criteria or to not wait the recommended two week review period that is their business.
The reader is also reminded that per Robert's Rules of Order article IV section 24 of the 1915 edition a motion may be divided. In this case that means that if someone objects to a particular issue being marked as RESOLVED that person can move that the motion be divided and that the particular issue in dispute be broken out for a separate vote. This allows the majority of the entries, which are expected to be non-controversial, to be voted on without being held up by individual contentious issues.
It is quite likely that sub-groups will form consensus views regarding the disposition of certain issues. Those sub-groups will then likely want to find volunteers to write a block motion to be motioned and seconded that collects all the issues they want to have set as RESOLVED. Sub-groups putting forward block motions are encouraged to follow the same format as the issues group and to also make their motions available for two weeks before putting them to an actual vote.
The reader is reminded, as discussed in the previous section, that the motion format is optional and that motions can always be sub-divided. The reader is also reminded that sub-groups have no normative existence; this is why they have to find volunteers to write and move motions.
The ideal is that when an issue is proposed the group examines it, discusses it and then resolves it.
In reality the process can use a bit of help. To this end the chairs can choose to appoint volunteers as champions for a particular issue. The champion(s) has no normative capabilities of any kind expressed or implied. In typical management fashion they have responsibility but no power.
The job of the champion(s) is to drive an issue to resolution. The exact means of doing so typically involves e-mail threads and direct discussion with interested parties but the details are left to the champion(s).
For record keeping purposes the issues list contains a field called champions that records the name and e-mail addresses for the champion or champions assigned to a drive a particular issue to resolution.
Champions are encouraged to start e-mail threads about issues and if necessary to call for non-normative teleconferences where interested parties can get together and try to create a mutually acceptable resolution to an issue.
It cannot be stressed enough that champions have no normative role to play. They are a convenience used by chairs to help drive issues to close. In essence they are the person who the chair can ask 'so what's going on with this issue and why isn't it resolved yet?'
Chairs are under no obligation to find a volunteer to champion an issue. But if a champion is suggested when an issue is opened or if someone does volunteer then the chairs are generally expected to accept the person or persons who have volunteered as champions. If no one has volunteered then the chairs are typically expected, but again - not required, to ask for volunteers. Ideally each OPEN issue should have at least one champion assigned to drive it.
Step 1 - Send your issues directly to the issues editor, Peter Furniss (Peter.Furniss@choreology.com). It would be helpful if your e-mail was of the form:
Subject Line: New Issue - [A short title for the issue]
Body:
Categories: [If you aren’t sure what value to put here then don’t worry about this field]
Document: [What document the issue is about – e.g. the main BPEL TC document or a sub-group document?]
Description: [A short summary of the issue.]
Use Cases: [Zero or more references pointing to Use Cases that are relevant to the issue.]
Links: [Zero or more references pointing to resources that are generally related to the issue.]
Empty fields can be omitted. The issues process list does provide support for a limited set of HTML tags as well as a number of time saving macros such as a Macro to put in a link to another issue. Please see Appendix - Neat Issues Posting Tricks for more details.
Step 2 - If there is a problem with your submission the issues editor will contact you. Once any problems are resolved an announcement will be sent to the main list announcing your issue and giving the issue number. The announcement message has its reply-to field set to the main list.
Step 3 - A mail sniffer is available that checks the subject lines of mail sent to any of the group's mailing lists. Any mail with the subject line "Issue - [An issue number] - [Whatever You Want]", possibly preceded by one or more “Re:” or “[<groupname>] will be picked up and linked to the issue.
Step 4 - If you want to change anything about the issue, such as its title, description, categories, etc. then send mail to the Issues Editor.
Step 5 - When the time comes to resolve the issue send an e-mail with the subject line “Issue – [Issue ID] – Proposal for Motion” to the mailing least at least one week before the next TC meeting (teleconference or face-to-face). If the e-mail is sent less than one week before the next meeting then the chairs may choose not to bring the issue up and postpone it until the meeting after the next meeting. If the e-mail is sent less than one week before the next meeting and the chairs do decide to bring it up for a vote at the next TC meeting and anyone objects that there hasn’t been enough time to review the issue then the chairs will delay the issue until the next TC meeting. In other words, please, post a ‘Proposal for Motion’ e-mail at least a week before the next TC meeting.
The body of the email will be saved as a text file and then processed by scripts that convert it to html for incorporation in the issues list (email received in html is flattened to text first). The closer the body of the email is to the form needed by these scripts, the less work needs to be done by the editor in hand-editing. Submitters are not required to use the constructs described here, but they may find them useful.
The following conversions are performed (on all fields, though some are only useful for the Description).
If a field name is immediately followed by HTML (e.g. Description:HTML), the field is assumed to be in HTML and no further processing is done on it – that field is copied directly. In consequence, any hyperlinks need to be absolute.)
A blank line is converted to <p>, forcing a paragraph break. Other line breaks are preserved but no html is added, so they disappear when viewing the issues list.
The html tags blockquote, pre, p, b, i, li, ul, ol, br, table, table border=1, tr, td and the corresponding end tags are recognized and preserved. (Attributes on these, other than the table border=1, will block recognition). Any other angle brackets are converted to <, > entities (so bits of xml will appear correctly). Ampersands are converted to & unless they are part of existing html entities.
There are four special “reference” constructs that generate hyperlinks without you having to get everything right – especially useful in Use Cases and Links, but usable elsewhere. (text in <angle brackets> is meta-syntax – those are semi-colons between the fields)
[MSG=<text>;<group>/<yyyymm>/<msgnumber>]
makes a hyperlink to oasis message archived for group <group>, month <yyyymm>, message number <msgnumber> with <text> as the content of the hyperlink (i.e. what you see). <msgnumber> can omit leading zeros. If <text> is omitted, the content will be <senders name>, <date>. [1]
E.g. [MSG=;wsbpel-reqts/200306/23]
[ISSUE=<id>]
makes a link to issue <id> in the issues list, with link content of the issues id and title.
e.g. … this does not seem to be covered by [ISSUE=12] ….
[DOCUMENT=<text>;<documentnumber>/<documenttitle>;<group>]
makes a link to the uploaded OASIS document for group <group> with number <documentnumber> and filename <documenttitle>, with link content of <text>. <group> defaults to wsbpel. It will also plant a second link to the document details information on the OASIS website.
[URL=<text>;<url>]
converts to a hyperlink to <url> with content <text>. If <text> and the semicolon are omitted, the content will be the url itself. (Don’t just omit the <text> or there will be no content.)
Note that
Links:HTML
<a href=http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/2046/BPEL%20V1-1%20May%205%202003%20Final.pdf>input spec</a>
and
Links:
[URL=input spec; http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/2046/BPEL%20V1-1%20May%205%202003%20Final.pdf]
(but without the linebreaks in the url) should end up the same, and
Links:
[DOCUMENT=input spec;2046/BPEL%20V1-1%20May%205%202003%20Final.pdf]
would be similar but have an extra hyperlink to the document details.
Note: Each requirement is given an opaque ID to track it. The ID is the value between the brackets attached to each issue description.
[REQA] A mechanism MUST be created to enable issues placed before the working group to be tracked from initial submission through discussion through final resolution.
[REQ1] Representatives MUST be assigned to maintain the actual issues list and ensure the complete history of all issues, resolved or otherwise, is maintained, minimally for the life of the TC but ideally beyond that.
[REQBET] The issues process MUST be completely transparent with all of its workings available for both review and participation by any member of the TC.
[REQGAMMA] The issues process MUST enable any member of the TC to put an issue before the TC that can only be resolved as the result of a vote by the TC.
[REQBETA] A policy MUST be put into place to ensure that all issues will be resolved before the TC issues a normative specification.
[REQGIMMEL] The issue policy MAY allow for a review period between when the issue is submitted to when it is included in the issue list during which time the submitter may change or withdraw their issue but the review period MUST have a strictly bounded time and MUST be relatively short.
Version: 1.0
Modification Date: 6/4/2003
Author: Jeff Mischkinsky
Version: 1.1
Modification Date: 6/13/2003
Author: Jeff Mischkinsky
Comments: This is a first cut to capture the discussions that we've had, and also to add in some of my own thoughts. Please consider everything here to be "open for debate and change". It's just easier to have something concrete to react to.
Version: 1.2
Modification Date: 6/18/2003
Author: Yaron Y. Goland
Comments: This is a second cut which takes into account comments made by Peter Furniss, Jeff Mischkinsky and Diane Jordan
Version 1.3
Modification Date: 6/23/2003
Author: Yaron Y. Goland
Comments: Add a requirement from Assaf that mail to submit issues must include the issue's title in the subject line.
Version 1.4
Modification Date: 6/23/2003
Author: Yaron Y. Goland
Comments:
Version 1.5
Modification Date: 6/26/2003
Author: Peter Furniss and Yaron Y. Goland
Comments:
Version 1.6
Modification Date: 10/1/2003
Author: Peter Furniss and Yaron Y. Goland
Comments:
[1] <group> and <yyyymm> also default, but the default for
<group>, currently wsbpel, is liable to change if the preferred list for
issue discussion changes and <yyyymm> defaults to the month of
processing, so they are a bit risky for general use. But <wsbpel>//12 is
probably safe early in the month.