Re: [oslc-ccm] Chanage management types and properties

[Steve K Speicher <sspeiche@us.ibm.com>]

Feedback included inline below...

Thanks,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web -> 
http://open-services.net


> From: Samuel Padgett/Durham/IBM@IBMUS
> To: oslc-ccm@lists.oasis-open.org
> Date: 03/12/2014 09:56 AM
> Subject: [oslc-ccm] Chanage management types and properties
> Sent by: <oslc-ccm@lists.oasis-open.org>
> 
> 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?
> 

+1

I think it doesn't make sense to bake the "is a" hierarchy requirement. 
Instead implementations can simply multi-type their resources wherever it 
makes sense.

> 
> 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
> 

+1

Follows DRY principles (Don't Repeat Yourself), even if Resource Shapes do 
not support this type of reuse today.  I have given that as a use case for 
future Resource Shape development.

> 
> 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