Early Draft: Planned for the OSLC-CM 3.0 Specification.
Contents
Motivation
Most change management systems support different types such as defects, tasks, enhancements, and stories. The OSLC-CM 2.0 specification modeled all of these as a single oslc_cm:ChangeRequest resource type. The single-type approach is appealing because it is simple and supports the scenarios. It also has drawbacks, however:
- A defect is different than a task. Conceptually, it makes sense to have different types.
- Not all types are necessarily “change requests” in the literal sense of the phrase. For instance, many tasks in a change management system are not change requests.
- Different types might have different properties. For instance, “severity” might be appropriate for a defect, but not for a task.
- It is difficult to query for or create specific types when everything is an oslc_cm:ChangeRequest.
- The dcterms:type property in OSLC-CM 2.0 is defined as a string with no standard values. Guidance from Dublin Core is to use rdf:type instead of dcterms:type. (See OSLC-CM 2.0 spec issues, issue 11.)
As we evolve OSLC-CM, we believe it makes sense to define more types.
OSLC-CM 2.0 defines Usage Identifiers to identify types for dialogs, query capabilities, and creation factories. These usage identifiers would not be necessary if we define different resource types.
See the mailing list thread, Providing additional types of “change request”-like resources
Approach
We will look at OSLC-CM scenarios, existing Usage Identifiers, and different change management tools to understand what types we need and what properties are appropriate for each type.
Proposed Types
oslc_cm:Defect
A software or product defect. Used by QM tools to report defects in testing.
oslc_cm:Enhancement
A request for new functionality.
oslc_cm:ReviewTask
A request to make a changes and review the change. A review task can be used by RM tools to request and approve changes to requirements, or it might be used by QM tools to review test plans and test cases.
oslc_cm:Task
An executable and trackable activity. Tasks can be used in many context. A QM tool that create tasks to write test plans and test cases is one example.
Backwards Compatibility Considerations
TBD
Open Questions
- Should we have a common parent type? If so, what should it be called?
- Should we specify properties for each type or simply define types and properties separately as the OSLC-CM vocabulary?
- Should we have an incident or ticket type?
- Should we have a common review/approval type for RM and QM review scenarios?
Next Steps
- Identify potential types
- Assess how well they map to real-world change management systems
- Determine what properties are appropriate for each type
Notes
Category:Supporting documents
