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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ ONAP-TSC mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-tsc
