Chanage management types and properties

[Samuel Padgett <spadgett@us.ibm.com>]

I've asked Nick to add a topic to tomorrow's CCM call to discuss the following questions on change management types. I thought I'd weigh in before the meeting to start the discussion.


1. Should we have a common parent ChangeRequest that other types subclass?

I propose we don't. For one, the Task and ReviewTask types are not necessarily change requests. We could call it something else, but what would that be? Second, it's not clear to me what the value really is. You can infer that a defect is a change request if it's a subclass, but I'm not sure what use case that supports.

Considering backwards compatibility: providers can declare resources using both the new 3.0 type and the 2.0 change request type for compatibility with 2.0 consumers. If we make the new types sublasses of change request, what is the impact?


2. Should we have a list of common properties for all types or define properties for each type?

I suggest we have one list of common change management properties. Most types have the same properties with only a few that might be specific to a type (like severity for defect). You can see this when you look at our spreadsheet that catalogs the properties in real change management tools.

https://docs.google.com/spreadsheet/ccc?key=0AsgaoPBj7epTdGotZjBsY19HZTJrS3dZRDJHbExQSlE&hl=en#gid=0


For context, here is the list of the proposed types from the contributed draft 3.0 change management specification:

### Resource: Defect

A software or product defect. Used by QM tools to report defects in testing.

* **Name:** `Defect`
* **Type URI** `http://open-services.net/ns/cm#Defect`

### Resource: Enhancement

A request for new functionality.

* **Name:** `Enhancement`
* **Type URI** `http://open-services.net/ns/cm#Enhancement`

### Resource: 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](http://open-services.net/wiki/change-management/Change-Management-of-Requirements/), or it might be used by QM tools to review test plans and test cases.

* **Name:** `ReviewTask`
* **Type URI** `http://open-services.net/ns/cm#ReviewTask`

### Resource: 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.

* **Name:** `Task`
* **Type URI** `http://open-services.net/ns/cm#Task`

--
Samuel Padgett | IBM Rational | spadgett@us.ibm.com
Eclipse Lyo: Enabling tool integration with OSLC