OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-ccm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (OSLCCCM-32) Ability to associate a set of change requests to a parent change request


    [ https://issues.oasis-open.org/browse/OSLCCCM-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=64837#comment-64837 ] 

James Amsden commented on OSLCCCM-32:
-------------------------------------

The relationship between change requests is often how they are organized in a plan - which is not addressed by the CM spec. This could be captured in the parent/child relationship as discussed in OSLCCM-28. 

Is something more needed?

> Ability to associate a set of change requests to a parent change request
> ------------------------------------------------------------------------
>
>                 Key: OSLCCCM-32
>                 URL: https://issues.oasis-open.org/browse/OSLCCCM-32
>             Project: OASIS OSLC Lifecycle Integration for Change and Configuration Management (OSLC CCM) TC
>          Issue Type: Improvement
>          Components: Change Management
>            Reporter: Martin Sarabura
>            Assignee: James Amsden
>
> The current spec allows one to associated one or more change requests with the current change request either as a neutral association (relatedChangeRequest) or to inform impact analysis (affectsPlanItem) or as a decomposition (affectedByDefect). None of these relationships represents a container relationship whereby the current change request is decomposed into a series of tasks that must be done in order to satisfy the change request. This is a significant gap that can't be filled by repurposing one of the existing relationships because a) there may be a need to represent one of the other relationships in addition to a container relationship and b) there is no easy way to indicate how the client should interpret the relationship anyway. Note that task order is significant - not sure how it should be represented. Finally, there is (probably?) no need to include the same task twice on the same list. However, I can see a need for a task to show up on multiple containers so that it can be completed by the first person to get to it.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]