Hi Oliver, I think that we are at a stage where we are setting a precedent with this type of problem, so we may try one approach and decide it was or was not a good idea. Yes, I would suggest the use case approach for this for release 2, where the output of the use case work is an understanding of the needs expressed on different projects.
BR, Steve -----Original Message----- From: SPATSCHECK, OLIVER (OLIVER) [mailto:[email protected]] Sent: 12 June 2017 17:00 To: Stephen Terrill <[email protected]> Cc: [email protected] Subject: Re: [onap-tsc] Network Function Change Management Project Proposal Steve, I think the actual code would be contributions to various other projects e.g. CMO needs workflows but I would think those would be additional features in SO not a separate orchestrator for CMO. So the CMO team members would likely also become contributors in other projects but we wouldn’t need a separate code base. So I think what you are recommending is to work this as a use case for release 2 ? Oliver > On Jun 10, 2017, at 8:07 AM EDT, Stephen Terrill > <[email protected]> wrote: > > Hi Oliver, > > It might depend a little on the expected final intention. Is the final > expectation that there will be a new module required (I thought I'd heard > something about that could be the case), or whether it is expected that this > functionality is something that would be realised solely through additional > to the code produced by existing/already proposed projects? > > If the former we could go and setup a project, if the latter is be leaning > towards use cases. > > We now need to keep in mind that the projects we start now don't have to be > aimed for the first release, but if there is a group interested and it > eventually plans to have a result I don't see why it couldn't start now if we > are clear on what it is to do. > > BR, > > Steve > > BR, > > Steve. > > Sent from my Phone > >> On 9 Jun 2017, at 11:23, SPATSCHECK, OLIVER (OLIVER) >> <[email protected]> wrote: >> >> >> During the F2F meeting we discussed a project proposal on the topic. As this >> addresses workflows across components rather then build a component the >> question came up what form this should take. 4 options are proposed >> >> 1. Make it a project and add a clear deliverable (e.g. Documentation) to the >> project proposal. >> 2. Make this work part of the architecture subcommittee. >> 3. Have a coordinator on this >> 4. Make this a use case for r2 >> >> In my mind I don't like #2. as it removes the clear focus of this work. >> >> The suggestion was made to ask the TSC on the mailing list for opinions. >> >> So please advice. >> >> Oliver >> _______________________________________________ >> ONAP-TSC mailing list >> [email protected] >> https://lists.onap.org/mailman/listinfo/onap-tsc _______________________________________________ ONAP-TSC mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-tsc
