IssueTracker - Content Management Interoperability Services (CMIS) TC Wiki

Guidelines

Issues added at least 7 (calendar) days before a TC meeting will be reviewed before the next meeting, i.e. one of the following things will happen:

If a resolution can already be reached (e.g. it’s just fixing a “bug”, etc.), it will be done in mail before the next meeting.
- If anyone disagrees with the resolution, we can discuss it at the next meeting.
- If the proposal is substantive (ie, not a typo) it should be discussed at the next meeting. If there is any question on the substantive nature of an issue, it should be treated as substantive.
If further clarification/discussion is needed, it will either be done in mail before the next meeting.
If no consensus is reached on the list before the next meeting, the issue will be added to the agenda for the next meeting.

Responsibilities:

Proposer: It is the proposers responsibility to make sure his or her proposal is discussed, received adequate reviews, and voted on at the TC meeting.
Component Owner: It is the owners responsibility to look at across all issues for his or her componentand provide holistic feedback and validate issues do not conflict.

Fields:

Description: Describes the issue with any relevant context. This field should only be edited by the reporter to clarify the issue being reported
Proposal: This describes the proposed resolution of the issue. This field will be kept up to date based on the comments and will be updated by either the reporter or by the owner of the component.
Resolution: This describes the resolution of the issue when it is closed. This is edited by the owner of the component. If the resolution field contains a resolution, the Fixed Version must specify which version will contain this resolution.

Creating issues:

Issues should address a single item that can be resolved
Issues that contain more than one item will be updated to reflect a single item
Issues should be created to capture a discussion. A thread should be created on the mailing list and any issues that arise should be created in the issue tracker.

Editing Issues:

New: Issues are created in this state and can transition to Open (Accepted as Work by the TC) or Closed (Rejected)
Open: Issues in this state are accepted as work items for the TC. Proposals are being refined. Issues can transition to Resolved
Resolved: Issues in this state have proposals that are accepted. At this point, the issue is targeted for a particular Draft. Issues can transition to Applied
Applied: Issues in this state have been accepted and the draft has been updated. Issues can transition to Closed or Resolved if the changes are rejected. The issue submitter should review the issue and validate it is applied.
Closed: Issues are closed no work is pending on the issue

Drafts and the issues addressed in those drafts are tracked in JIRA.
After a draft candidate has been selected as a draft by the TC, all issues in:
- Open - Should be none, but if they exist moved to next draft
- Resolved - Moved to next draft
- Applied - TC should investigate whether or not this is applied. At two weeks after draft selected, all applied issues not identified by TC as not applied will be Closed. All other applied issues will be moved to the next draft with state Resolved (edits rejected)