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-29) References to before and after states of affected resources


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

Martin Sarabura commented on OSLCCCM-29:
----------------------------------------

Yes, those requirements should be met. I believe CCM already does support this. The question is, should there be any guidance (if non-normative) or should we add these convenience references to the before/after snapshots of the resources as part of the spec? My motivation here is to assure the specification adopters that their use case can be accommodated by the spec and if it is a common scenario, to make the recommendation normative though no stronger than MAY. If deemed not so important then the resolution may be lumped into the same category as issue 26.

> References to before and after states of affected resources
> -----------------------------------------------------------
>
>                 Key: OSLCCCM-29
>                 URL: https://issues.oasis-open.org/browse/OSLCCCM-29
>             Project: OASIS OSLC Lifecycle Integration for Change and Configuration Management (OSLC CCM) TC
>          Issue Type: Bug
>          Components: Change Management
>            Reporter: Martin Sarabura
>
> Our PTC tools have a usability feature that allows the end user to see the state of the affected resources prior to and after the requested changes have been implemented. This allows a reviewer to easily ascertain that the implemented changes are consistent with the request, even if other changes had been introduced by other change requests concurrently. The alternative approach - which is supported by the current spec - is to review every change in the list of change sets. This approach adds cognitive load if more than one change set was created and/or if the same resource is represented more than once in the change sets.



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