[oslc-cm] OSLC-CM Workgroup meeting Minutes (November 7, 2013)

[Samit Mehta]

Sorry that I couldn't make it to the meeting.  I have a few questions on
what I saw in the minutes:


>From the minutes:
  Sam: Do delegated actions dialogs fit into the RCR scenario? It could be
a fallback for when programmatically changing the state fails.
  Workgroup agrees it makes sense.

Question:
Do the delegated action dialogs being considered include a delegated dialog
for just "editing" the change request?

Some background:
There is an outstanding request from IBM partners that consume OSLC
delegated UIs for creation and selection of Change Requests to be able to
"edit" the Change Requests from within their own tool's UI.  They have
brought up the fact that a lack of "edit" scenario requires them to now
have a different user experience for the updating Change Requests.

The example scenario that requires edit capability is as follows:
Tools being integrated: Integrated Change Management between two change
management tools (e.g. PLM tool, IT Service Management , ALM tool, general
Change Management  tools):
Scenario:
Engineer assigned to a Change Request in a change management tool wants to
provide additional information about the change request to assigned
engineer and stakeholders of a related change request in another change
management tool.  Engineer should be able to add comments, change property
values (title, description, priority, etc), links, and add/remove/update
attachments without having to leave the UI of the original change
management tool.

I am happy to provide more details about the above scenario.  I am also
encouraging the IBM partners to directly provide their input to the working
group.

>From the minutes:
	Sam: Should we support prefill like for creation dialogs?
	No current scenario needs this.
Suggestion:
Even though we don't have a current scenario, it would really help if we
include the mechanism on how to support prefill for delegated edit (action)
dialogs.  It could remain an optional capability just like prefill is
optional for creation dialogs.  This way if a scenario comes up, we don't
have folks coming up with different implementations.  What may be different
with prefilling edit dialogs from prefilling creation dialog is that there
is a chance that an attempt will be made to update a property that already
has a value.  In such cases, if the property is "writable", then the
current value will be replaced.  Clients that want different behavior could
easily do a GET first to see if the property already has a value.

>From the minutes:
	Steve: Do we just need the type URIs or do we need to define
properties? There are many scenarios where just having the type URI is very
valuable.
	Consensus is that just defining the URIs is valuable and no scenario
requires more than CM common properties.
Question:
Will there be a way to support following scenarios with what is captured in
the referenced wiki page and providing type URIs:

(i) Will an OSLC CM consumer be able to easily determine the list of user
friendly "titles" of all the Change Management types supported by the OSLC
CM provider?
(ii) Will an OSLC CM consumer be able to identify a creation factory or
delegated UI to create a resource of a specific Change Management type
where the OSLC CM consumer is provided with a "title" of Change Management
type (and not the URI)?
(iii) Will the OSLC specification require that there be a generic creation
factory, delegated UI, and query capability that supports OSLC CM consumers
that don't have awareness about the different Change Management types?  In
other words an OSLC CM consumer should be able to determine what the
default creation factory (i.e. configured by the tool's administrator) is,
or a query capability that is able to return query results across all
Change Management types.  What will be the guidance in the specification
for the shape resources for these generic services?
(iv) Will an OSLC CM consumer be able to filter the results of the query
based on one or more Change Management types? How about filtering based on
one or more user friendly titles of the Change Management types?
(v) Will there be guidance in the OSLC specification for tools to be able
to define their own proprietary change management types?

Sincerely,
___________________________________________________________________________
Samit Mehta
IBM Rational Software - Business Development


"Oslc-Cm" <oslc-cm-bounces at open-services.net> wrote on 11/07/2013 12:54:50
PM:

> From: Samuel Padgett/Durham/IBM at IBMUS
> To: oslc-cm at open-services.net,
> Date: 11/07/2013 03:41 PM
> Subject: [oslc-cm] OSLC-CM Workgroup meeting Minutes (November 7, 2013)
> Sent by: "Oslc-Cm" <oslc-cm-bounces at open-services.net>
>
>
http://open-services.net/wiki/change-management/OSLC-Change-Management-November-7-2013/

>
> Next meeting: November 21, 2013
>
> --
> Samuel Padgett | IBM Rational | spadgett at us.ibm.com
> Eclipse Lyo: Enabling tool integration with OSLC
> _______________________________________________
> Oslc-Cm mailing list
> Oslc-Cm at open-services.net
> http://open-services.net/mailman/listinfo/oslc-cm_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-cm_open-services.net/attachments/20131108/4e284551/attachment-0003.html>