[onap-tsc] Updated TSC Charter
That sounds reasonable to me. Oliver On Apr 21, 2017, at 15:50, Christopher Donley (Chris) mailto:Christopher.Donley at huawei.com>> wrote: That?s essentially the approach we used in OPEN-O, with the Release Manager handling the coordination ? if a project needed a new repo for a sub-project, etc., the team reached out to Gildas. It worked fairly well. We could update the language in section 1 to allow plural repositories. Beyond that, I suggest not over specifying the mechanism in the charter, and instead provide flexibility to the TSC to deal with issues as they arise. Chris From: Ed Warnicke [mailto:hagb...@gmail.com] Sent: Friday, April 21, 2017 12:34 PM To: SPATSCHECK, OLIVER (OLIVER) Cc: Christopher Donley (Chris); Ed Warnicke; SULLIVAN, BRYAN L; onap-tsc at lists.onap.org<mailto:onap-tsc at lists.onap.org> Subject: Re: [onap-tsc] Updated TSC Charter Inline... On Fri, Apr 21, 2017 at 11:01 AM, SPATSCHECK, OLIVER (OLIVER) mailto:spatsch at research.att.com>> wrote: I think one option would be to stick with the project approval as outline but allow multiple repos in one project as decided by the project team. Then we could have a repo coordinator who provides advice to the projects on repos and races issues (like this should really be two projects) to the TSC as they occur which allows the TSC to intervene (e.g. splitting the project). This sounds like a good start :) Though I would prefer the TSC ask hard questions as to whether a project has grown beyond its scope rather than 'intervening' ;) Ed Similarly to your philosophy I believe into trusting the people which do the work and dealing with problems IF they happen rather then trying to design a process which is heavy handed trying to address anticipated issues which might rarely/never occur. Oliver > On Apr 21, 2017, at 1:47 PM EDT, Ed Warnicke gmail.com<mailto:hagbard at gmail.com>> wrote: > > Inline... > > On Fri, Apr 21, 2017 at 9:22 AM, SPATSCHECK, OLIVER (OLIVER) research.att.com<mailto:spatsch at research.att.com>> wrote: > > I guess you could argue that our current code base is not well formed but if > you look at Gerrit right now you see about 60+ repos for the couple of > components we have. > > LOL... I try not to argue that somebody elses work is not well formed till I > can understand a bit better both their constraints and reasoning ;) > But when they do things that don't make immediate sense to me... I *do* get > curious and want to understand :) > So about the worst you are going to get from me is that seeking to understand > and perhaps some "Have you thought of this" questions :) > > > Let?s just start with A. A in my mind is one project. The scope of the > project is to provide a current inventory for ONAP. > > It consist of 5 repos. > > - AAI Chef cookbooks > - AAI Chef environment files > - AAI REST based services > - AAI common logging library > - Loads SDC Models into A > > now could we have thrown all of this into one repo? Sure we could have but I > think they are functionally separate enough that they shouldn?t be in the > same repo so they can be managed separately (e.g. versioning, patches, > releases etc?). Also not every ONAP user might use all of them (e.g. somebody > might not want to use chef and add an ansible repo) > > This is true pretty much for every component we have right now as you can see > in gerrit. > > Now I guess you could argue that we should file a sub project proposal for > each of those repos but I am not sure if e.g. creating two repos for Check > cookbooks and Check environment files is really a decision which needs TSC > input. That could perfectly be handled by the project team. After all we are > trusting the project team to write the code so why not trust them with this? > > Honestly, my preferred mode of oversite in general is to provide information > that may be relavent and then defer to the guys doing the work. > So please take my comments in that spirit ;) > > When I see repo proliferation a couple of things come to mind for me: > 1) Is that really part of one project with one set of committers? Or is > that a new subcommunitee with a new set of committers (or likely to be). > In my mind, its much easier in a multi-repo environment to miss the "Hey, > that's actually different committers involved and should probably be a new > project" mark. > 2) Repo splits have costs both way. Multiple repos make it harder for folks > to check out all the code, but easier to grab just one corner of it. > Multiple repos make builds more complex, but faster. > e > > My past experience has been that TSCs are at their best when they ask > projects to *consider* questions, express that they have thought ab
[onap-tsc] Updated TSC Charter
We had a smaller community, and didn?t have ?coordinators?? My point is to leave the flexibility to the TSC, and not to specify the mechanism in the Charter (no comment on who specifically would coordinate/manage the repos). Chris From: Ed Warnicke [mailto:hagb...@gmail.com] Sent: Friday, April 21, 2017 12:56 PM To: Christopher Donley (Chris) Cc: SPATSCHECK, OLIVER (OLIVER); Ed Warnicke; SULLIVAN, BRYAN L; onap-tsc at lists.onap.org Subject: Re: [onap-tsc] Updated TSC Charter I'd suggest distributing responsibilities at bit more (rather than centralizing in a Release Manager... that job is hard enough ;) ). Ed On Fri, Apr 21, 2017 at 12:50 PM, Christopher Donley (Chris) mailto:Christopher.Donley at huawei.com>> wrote: That?s essentially the approach we used in OPEN-O, with the Release Manager handling the coordination ? if a project needed a new repo for a sub-project, etc., the team reached out to Gildas. It worked fairly well. We could update the language in section 1 to allow plural repositories. Beyond that, I suggest not over specifying the mechanism in the charter, and instead provide flexibility to the TSC to deal with issues as they arise. Chris From: Ed Warnicke [mailto:hagbard at gmail.com<mailto:hagb...@gmail.com>] Sent: Friday, April 21, 2017 12:34 PM To: SPATSCHECK, OLIVER (OLIVER) Cc: Christopher Donley (Chris); Ed Warnicke; SULLIVAN, BRYAN L; onap-tsc at lists.onap.org<mailto:onap-tsc at lists.onap.org> Subject: Re: [onap-tsc] Updated TSC Charter Inline... On Fri, Apr 21, 2017 at 11:01 AM, SPATSCHECK, OLIVER (OLIVER) mailto:spatsch at research.att.com>> wrote: I think one option would be to stick with the project approval as outline but allow multiple repos in one project as decided by the project team. Then we could have a repo coordinator who provides advice to the projects on repos and races issues (like this should really be two projects) to the TSC as they occur which allows the TSC to intervene (e.g. splitting the project). This sounds like a good start :) Though I would prefer the TSC ask hard questions as to whether a project has grown beyond its scope rather than 'intervening' ;) Ed Similarly to your philosophy I believe into trusting the people which do the work and dealing with problems IF they happen rather then trying to design a process which is heavy handed trying to address anticipated issues which might rarely/never occur. Oliver > On Apr 21, 2017, at 1:47 PM EDT, Ed Warnicke gmail.com<mailto:hagbard at gmail.com>> wrote: > > Inline... > > On Fri, Apr 21, 2017 at 9:22 AM, SPATSCHECK, OLIVER (OLIVER) research.att.com<mailto:spatsch at research.att.com>> wrote: > > I guess you could argue that our current code base is not well formed but if > you look at Gerrit right now you see about 60+ repos for the couple of > components we have. > > LOL... I try not to argue that somebody elses work is not well formed till I > can understand a bit better both their constraints and reasoning ;) > But when they do things that don't make immediate sense to me... I *do* get > curious and want to understand :) > So about the worst you are going to get from me is that seeking to understand > and perhaps some "Have you thought of this" questions :) > > > Let?s just start with A. A in my mind is one project. The scope of the > project is to provide a current inventory for ONAP. > > It consist of 5 repos. > > - AAI Chef cookbooks > - AAI Chef environment files > - AAI REST based services > - AAI common logging library > - Loads SDC Models into A > > now could we have thrown all of this into one repo? Sure we could have but I > think they are functionally separate enough that they shouldn?t be in the > same repo so they can be managed separately (e.g. versioning, patches, > releases etc?). Also not every ONAP user might use all of them (e.g. somebody > might not want to use chef and add an ansible repo) > > This is true pretty much for every component we have right now as you can see > in gerrit. > > Now I guess you could argue that we should file a sub project proposal for > each of those repos but I am not sure if e.g. creating two repos for Check > cookbooks and Check environment files is really a decision which needs TSC > input. That could perfectly be handled by the project team. After all we are > trusting the project team to write the code so why not trust them with this? > > Honestly, my preferred mode of oversite in general is to provide information > that may be relavent and then defer to the guys doing the work. > So please take my comments in that spirit ;) > > When I see repo proliferation a couple of things come to mind for me: > 1) Is that really part of one project with one set of committers? Or is > that a new s
[onap-tsc] Updated TSC Charter
I think one option would be to stick with the project approval as outline but allow multiple repos in one project as decided by the project team. Then we could have a repo coordinator who provides advice to the projects on repos and races issues (like this should really be two projects) to the TSC as they occur which allows the TSC to intervene (e.g. splitting the project). Similarly to your philosophy I believe into trusting the people which do the work and dealing with problems IF they happen rather then trying to design a process which is heavy handed trying to address anticipated issues which might rarely/never occur. Oliver > On Apr 21, 2017, at 1:47 PM EDT, Ed Warnicke wrote: > > Inline... > > On Fri, Apr 21, 2017 at 9:22 AM, SPATSCHECK, OLIVER (OLIVER) research.att.com> wrote: > > I guess you could argue that our current code base is not well formed but if > you look at Gerrit right now you see about 60+ repos for the couple of > components we have. > > LOL... I try not to argue that somebody elses work is not well formed till I > can understand a bit better both their constraints and reasoning ;) > But when they do things that don't make immediate sense to me... I *do* get > curious and want to understand :) > So about the worst you are going to get from me is that seeking to understand > and perhaps some "Have you thought of this" questions :) > > > Let?s just start with A. A in my mind is one project. The scope of the > project is to provide a current inventory for ONAP. > > It consist of 5 repos. > > - AAI Chef cookbooks > - AAI Chef environment files > - AAI REST based services > - AAI common logging library > - Loads SDC Models into A > > now could we have thrown all of this into one repo? Sure we could have but I > think they are functionally separate enough that they shouldn?t be in the > same repo so they can be managed separately (e.g. versioning, patches, > releases etc?). Also not every ONAP user might use all of them (e.g. somebody > might not want to use chef and add an ansible repo) > > This is true pretty much for every component we have right now as you can see > in gerrit. > > Now I guess you could argue that we should file a sub project proposal for > each of those repos but I am not sure if e.g. creating two repos for Check > cookbooks and Check environment files is really a decision which needs TSC > input. That could perfectly be handled by the project team. After all we are > trusting the project team to write the code so why not trust them with this? > > Honestly, my preferred mode of oversite in general is to provide information > that may be relavent and then defer to the guys doing the work. > So please take my comments in that spirit ;) > > When I see repo proliferation a couple of things come to mind for me: > 1) Is that really part of one project with one set of committers? Or is > that a new subcommunitee with a new set of committers (or likely to be). > In my mind, its much easier in a multi-repo environment to miss the "Hey, > that's actually different committers involved and should probably be a new > project" mark. > 2) Repo splits have costs both way. Multiple repos make it harder for folks > to check out all the code, but easier to grab just one corner of it. > Multiple repos make builds more complex, but faster. > e > > My past experience has been that TSCs are at their best when they ask > projects to *consider* questions, express that they have thought about them, > but then defer broadly to the guys on the ground (a projects committers). > > Do you have thoughts for how that might be done in this situation? > > Ed > > > So in my mind this will either lead to: > > A.) unnecessary red tape overhead > B.) people combining things into a single repo because they don?t want to do > the red tape. > > (and believe me I know red tape ?.). Probably you get a bit of both. > > > Oliver > > > On Apr 21, 2017, at 12:07 PM EDT, Ed Warnicke wrote: > > > > Oliver, > > > > For my edification, can you give an example or two of where a well scoped > > project would set up multiple repos? > > > > Ed > > > > On Fri, Apr 21, 2017 at 8:47 AM, SPATSCHECK, OLIVER (OLIVER) > research.att.com> wrote: > > I have another question on the charter. I just noticed that a project (or > > sub project) and a repo are the same thing. I find this to be sub optimal. > > In my mind a project is a well defined scope of work. A repo has to do with > > how to optimize my code management. Am I the only one with the concern > > that binding the two will force people into sub optimal repo structures? > > > > Thx > > > > Oliver > > ___ > > ONAP-TSC mailing list > > ONAP-TSC at lists.onap.org > > https://lists.onap.org/mailman/listinfo/onap-tsc > > > >
[onap-tsc] Updated TSC Charter
That was also my comment on the charter. Projects should be able to setup multiple repos for their scope, e.g. code, documentation, ... and for multiple components separately managed in repos. Thanks, Bryan Sullivan | AT -Original Message- From: SPATSCHECK, OLIVER Sent: Friday, April 21, 2017 8:47 AM To: Christopher Donley (Chris) Cc: Dhananjay Pavgi ; Stephen Terrill ; SULLIVAN, BRYAN L ; onap-tsc at lists.onap.org; Ed Warnicke Subject: Re: [onap-tsc] Updated TSC Charter I have another question on the charter. I just noticed that a project (or sub project) and a repo are the same thing. I find this to be sub optimal. In my mind a project is a well defined scope of work. A repo has to do with how to optimize my code management. Am I the only one with the concern that binding the two will force people into sub optimal repo structures? Thx Oliver
[onap-tsc] Updated TSC Charter
It's important to separate the project lifecycle from the release lifecycle. It usually takes 2+ releases for a project to move from 'incubation' to 'mature'. However, you probably want to have an MVP for each release defined during the planning phase (before the M1 milestone). What is the minimum functionality this project can deliver and still be part of the release? You can add stretch goals in case the team has extra time. In a date-driven release, though, the two levers a project team has are scope and quality, so it helps to understand up front what features/functions can be jettisoned if the team starts to fall behind. Chris From: Dhananjay Pavgi [mailto:dp00476...@techmahindra.com] Sent: Thursday, April 20, 2017 5:12 AM To: Stephen Terrill; SULLIVAN, BRYAN L; Christopher Donley (Chris); onap-tsc at lists.onap.org Cc: Ed Warnicke Subject: RE: Updated TSC Charter On MVP and text in below email from Bryan, Clarification as to what an MVP is as the target for the end of the incubation phase. Believe, that's where we need to some element of Product Management. thanks & regards, Dhananjay Pavgi Mobile : +91 98220 22264 [cid:image002.png at 01CE7323.F2727500] [ONAP_logo_Sig] www.techmahindra.com<http://www.techmahindra.com/> Platinum Member. Visit : http://www.onap.org<http://www.onap.org/> From: onap-tsc-bounces at lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Stephen Terrill Sent: Thursday, April 20, 2017 12:32 AM To: SULLIVAN, BRYAN L ; Christopher Donley (Chris) ; onap-tsc at lists.onap.org Cc: Ed Warnicke Subject: Re: [onap-tsc] Updated TSC Charter Hi, Thanks for the comments Bryan. On responding comment in the "incubation" and MVP definition and that is on the proposed addition of "That is (or can be) used in a production environment". The use in a "production environment" is also subject to whatever additions and support is required. I can agree that MVP is subject to the same question in that its very subjective. Its not obvious to phrase in a non-subjective way, but we could remove MVP and go with "Project has resources, but is recognized to be in an early stage of development and not generally considered suitable to a production environment." I'm ok with the contributor clarification. Best Regards, Steve. From: onap-tsc-bounces at lists.onap.org<mailto:onap-tsc-bounces at lists.onap.org> [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of SULLIVAN, BRYAN L Sent: 19 April 2017 19:12 To: Christopher Donley (Chris) mailto:Christopher.Donley at huawei.com>>; onap-tsc at lists.onap.org<mailto:onap-tsc at lists.onap.org> Cc: Ed Warnicke mailto:eaw at cisco.com>> Subject: Re: [onap-tsc] Updated TSC Charter Chris, Not sure I can post to the TSC list, but here are some comments in the draft: * Each project will have its own code repositories (one or multiple),... o The concept of an umbrella project may address this, but that's an overhead that should be optional. It may be more effective in some cases for projects just to have multiple repos. * A Contributor is someone who contributes code or other artifacts to a project, and reviews the contributions of others. Contributors are not necessarily from Member companies. o We should encourage and recognize all forms of contribution, especially reviews. IMO contributors may provide *no* code but still contribute valuable advice on architecture, quality, testability, or other contributions of a non-code/artifact nature. * Committer rights for a project are earned via code contribution ... o The potential pool of committers should go beyond just code contribution, given the merit of their other types of contributions * (description of Incubation phase) Project has resources, but is recognized to be in early stages of development, having yet to achieve a MVP (Minimum Viable Product) that is (or can be) used in production environments. o Clarification as to what an MVP is as the target for the end of the incubation phase. * Other editorial items Thanks, Bryan Sullivan | AT From: onap-tsc-bounces at lists.onap.org<mailto:onap-tsc-bounces at lists.onap.org> [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Christopher Donley (Chris) Sent: Wednesday, April 19, 2017 8:45 AM To: onap-tsc at lists.onap.org<mailto:onap-tsc at lists.onap.org> Cc: Ed Warnicke mailto:eaw at cisco.com>> Subject: [onap-tsc] Updated TSC Charter Dear TSC, On behalf of the Charter drafting team, please find attached an updated version of the TSC Charter incorporating your suggestions and feedback from the last review. We have attempted to highlight the open issues that need a decision from the TSC. We are sending this draft with the intention that you review it in preparatio
[onap-tsc] Updated TSC Charter
We talked about this at the face-to-face in Santa Clara. We agreed not to over-specify coordinators or subcommittees in the Charter, but instead set up a framework so that the TSC can add them once the Charter is in place. We specifically talked about security ? while we?re bootstrapping, security questions go to Phil Robb, but once the Charter is in place, we expect to have a security team to handle vulnerability reports. Of course, each individual project is responsible for the security of its component. Chris From: SPATSCHECK, OLIVER (OLIVER) [mailto:spat...@research.att.com] Sent: Thursday, April 20, 2017 4:55 AM To: GOLDNER, ALLA Cc: Don Clarke; Christopher Donley (Chris); onap-tsc at lists.onap.org; Ed Warnicke Subject: Re: [onap-tsc] Updated TSC Charter I would have expected to have at least a coordinator focused on this or even better a project which builds risk analysis tools and guidelines for ONAP. You can define them under the release requirements but unless you have a group of people working out the tools and details they really don?t mean much and I don?t think you want to distribute this to all the individual component projects. Oliver On Apr 20, 2017, at 1:51 AM, GOLDNER, ALLA mailto:alla.goldner at amdocs.com>> wrote: Hi Don, all, I believe this would be covered under Release requirements, once we define those. Best regards, Alla From: onap-tsc-bounces at lists.onap.org<mailto:onap-tsc-bounces at lists.onap.org> [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Don Clarke Sent: Thursday, April 20, 2017 8:48 AM To: Christopher Donley (Chris) mailto:Christopher.Donley at huawei.com>>; onap-tsc at lists.onap.org<mailto:onap-tsc at lists.onap.org> Cc: Ed Warnicke mailto:eaw at cisco.com>> Subject: Re: [onap-tsc] Updated TSC Charter Chris, Regulators are concerned about the impact of virtualization on the resilience of critical national infrastructures (they have turned-up at ETSI NFV meetings). Will there be a formalized ONAP process to minimize security vulnerabilities and/or undertake risk analysis in relation to critical components of the platform? I don?t see anything in the charter, would these aspects fall under (e.g.) the TSC Responsibility for ?defining release quality standards?? I don?t think this should be left to individual project teams to figure out. Thanks, Don. From: onap-tsc-bounces at lists.onap.org<mailto:onap-tsc-bounces at lists.onap.org> [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Christopher Donley (Chris) Sent: Wednesday, April 19, 2017 9:45 AM To: onap-tsc at lists.onap.org<mailto:onap-tsc at lists.onap.org> Cc: Ed Warnicke Subject: [onap-tsc] Updated TSC Charter Dear TSC, On behalf of the Charter drafting team, please find attached an updated version of the TSC Charter incorporating your suggestions and feedback from the last review. We have attempted to highlight the open issues that need a decision from the TSC. We are sending this draft with the intention that you review it in preparation for discussion and voting during our next TSC meeting. Chris, Steve, Ed, Lingli, Alla, and Phil This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.amdocs.com_about_email-2Ddisclaimer=DwMFAg=LFYZ-o9_HUMeMTSQicvjIg=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4=qanJmrKS-8k07dPd2m4vkZO_i076Fj4PF-Z_thIkNw0=ZQWOusx5K1pirGXMQqTdJ2gLSS1c8QUaIsa1vwqQrWI=> ___ ONAP-TSC mailing list ONAP-TSC at lists.onap.org<mailto:ONAP-TSC at lists.onap.org> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4=qanJmrKS-8k07dPd2m4vkZO_i076Fj4PF-Z_thIkNw0=pJET50QlbJFhc7UGw25LtzuYI1yz0pcrvdaq_1clvDw= -- next part -- An HTML attachment was scrubbed... URL: <http://lists.onap.org/pipermail/onap-tsc/attachments/20170420/1deb9b9f/attachment-0001.html>
[onap-tsc] Updated TSC Charter
On MVP and text in below email from Bryan, Clarification as to what an MVP is as the target for the end of the incubation phase. Believe, that's where we need to some element of Product Management. thanks & regards, Dhananjay Pavgi Mobile : +91 98220 22264 [cid:image002.png at 01CE7323.F2727500] [ONAP_logo_Sig] www.techmahindra.com<http://www.techmahindra.com/> Platinum Member. Visit : http://www.onap.org<http://www.onap.org/> From: onap-tsc-bounces at lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Stephen Terrill Sent: Thursday, April 20, 2017 12:32 AM To: SULLIVAN, BRYAN L ; Christopher Donley (Chris) ; onap-tsc at lists.onap.org Cc: Ed Warnicke Subject: Re: [onap-tsc] Updated TSC Charter Hi, Thanks for the comments Bryan. On responding comment in the "incubation" and MVP definition and that is on the proposed addition of "That is (or can be) used in a production environment". The use in a "production environment" is also subject to whatever additions and support is required. I can agree that MVP is subject to the same question in that its very subjective. Its not obvious to phrase in a non-subjective way, but we could remove MVP and go with "Project has resources, but is recognized to be in an early stage of development and not generally considered suitable to a production environment." I'm ok with the contributor clarification. Best Regards, Steve. From: onap-tsc-bounces at lists.onap.org<mailto:onap-tsc-bounces at lists.onap.org> [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of SULLIVAN, BRYAN L Sent: 19 April 2017 19:12 To: Christopher Donley (Chris) mailto:Christopher.Donley at huawei.com>>; onap-tsc at lists.onap.org<mailto:onap-tsc at lists.onap.org> Cc: Ed Warnicke mailto:eaw at cisco.com>> Subject: Re: [onap-tsc] Updated TSC Charter Chris, Not sure I can post to the TSC list, but here are some comments in the draft: * Each project will have its own code repositories (one or multiple),... o The concept of an umbrella project may address this, but that's an overhead that should be optional. It may be more effective in some cases for projects just to have multiple repos. * A Contributor is someone who contributes code or other artifacts to a project, and reviews the contributions of others. Contributors are not necessarily from Member companies. o We should encourage and recognize all forms of contribution, especially reviews. IMO contributors may provide *no* code but still contribute valuable advice on architecture, quality, testability, or other contributions of a non-code/artifact nature. * Committer rights for a project are earned via code contribution ... o The potential pool of committers should go beyond just code contribution, given the merit of their other types of contributions * (description of Incubation phase) Project has resources, but is recognized to be in early stages of development, having yet to achieve a MVP (Minimum Viable Product) that is (or can be) used in production environments. o Clarification as to what an MVP is as the target for the end of the incubation phase. * Other editorial items Thanks, Bryan Sullivan | AT From: onap-tsc-bounces at lists.onap.org<mailto:onap-tsc-bounces at lists.onap.org> [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Christopher Donley (Chris) Sent: Wednesday, April 19, 2017 8:45 AM To: onap-tsc at lists.onap.org<mailto:onap-tsc at lists.onap.org> Cc: Ed Warnicke mailto:eaw at cisco.com>> Subject: [onap-tsc] Updated TSC Charter Dear TSC, On behalf of the Charter drafting team, please find attached an updated version of the TSC Charter incorporating your suggestions and feedback from the last review. We have attempted to highlight the open issues that need a decision from the TSC. We are sending this draft with the intention that you review it in preparation for discussion and voting during our next TSC meeting. Chris, Steve, Ed, Lingli, Alla, and Phil Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html <http://www.techmahindra.com/Disclaimer.html> externally http://tim.techmahindra.com/tim/disclaimer.html <http://tim.techmahindra.com/tim/disclaimer.html> internally within TechMahindra. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.onap.org/pipermail/onap-tsc/attachments/20170420/512d8a05/a
