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

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

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

Martin Sarabura commented on OSLCCCM-32:
----------------------------------------

A plan does not necessarily contain all the links to all the change requests. Often a plan is created at a high level, bringing in high level change requests that are known at the time but not including the decomposed change requests that a more thorough analysis of the high level change request will create. So it makes sense for a change request to be structurally decomposed to lower-level change requests.

Is this the same as issue 32? Yes, if we also include a (likely non-normative) note suggesting possible approaches for representing the order of the relationship.It does gloss over the distinction between a cross-domain trace (which can be suspected and for which order is irrelevant) and a structural decomposition (which can't be suspected) however we can probably live with that.

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