Do other TSC members agree? How would we work this in practice? I think this work could start now as resources don’t overlap and it would allow us to be better prepared for release 2 when we do the release planing in November. (CMO team can go off now and have a detailed use case description ready in November).
Who would organize the meetings as there wouldn’t be a PTL etc… ? Thx Oliver > On Jun 12, 2017, at 4:07 PM, Stephen Terrill <[email protected]> > wrote: > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=9iyuArzgyekj47PZSPfIijI2cSHsUJtAlcTA0X_udNI&m=AfnVNHYp94ecJHcuaXB77m3RGUYff-uxmlnDLcc0Uw8&s=iHRAnnerLc0AyeKPTjgrHH6cF-mI51vs5S5iz37KNLw&e= >>> > _______________________________________________ ONAP-TSC mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-tsc
