[onap-tsc] Updated TSC Charter

[SPATSCHECK, OLIVER (OLIVER)]

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&AI 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&AI
>
> 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, expre

[onap-tsc] Updated TSC Charter

[Christopher Donley (Chris)]

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&AI 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&AI
>
> 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 

[onap-tsc] Updated TSC Charter

[Christopher Donley (Chris)]

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
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&AI 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&AI
>
> 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 situa

[onap-tsc] Updated TSC Charter

[BENNETT, RICH]

Both committer permissions and Nexus group ids are coupled to the gerrit 
project/repo name hierarchy.   If project reviews play a role in assessing the 
impact and communicating changes in these across projects, then any alternative 
that allows change in repo structure would need to address how this would be 
done.

-Original Message-
From: onap-tsc-bounces at lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of SPATSCHECK, OLIVER
Sent: Friday, April 21, 2017 2:02 PM
To: Ed Warnicke 
Cc: SULLIVAN, BRYAN L ; Ed Warnicke ; 
onap-tsc at lists.onap.org
Subject: Re: [onap-tsc] Updated TSC Charter

*** Security Advisory: This Message Originated Outside of AT&T ***.
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.



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&AI 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&AI

> 

> 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 bel

[onap-tsc] Updated TSC Charter

[SPATSCHECK, OLIVER (OLIVER)]

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&AI 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&AI
> 
> 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

[ROSE, DANIEL V]

Would it be fair to say this then?:

The tsc approach described in the charter applies to projects
The tsc approach described in the charter DOES NOT apply to subprojects

Thanks,
Daniel Rose
ECOMP / ONAP
com.att.ecomp
732-420-7308


-Original Message-
From: onap-tsc-bounces at lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of SPATSCHECK, OLIVER
Sent: Friday, April 21, 2017 12:22 PM
To: Ed Warnicke 
Cc: SULLIVAN, BRYAN L ; Ed Warnicke ; 
onap-tsc at lists.onap.org
Subject: Re: [onap-tsc] Updated TSC Charter

*** Security Advisory: This Message Originated Outside of AT&T ***.
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.



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.  



Let?s just start with A. A&AI 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&AI



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? 



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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=7fQgrg00vjmsI6lDObOMQ5GuJP5yULjerbc7r7aW87k&s=ZSmUVqKmGf-wX91p0D_iHy-NgTvWR5qV7065BPRObr8&e=
>  

> 



___
ONAP-TSC mailing list
ONAP-TSC at lists.onap.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=7fQgrg00vjmsI6lDObOMQ5GuJP5yULjerbc7r7aW87k&s=ZSmUVqKmGf-wX91p0D_iHy-NgTvWR5qV7065BPRObr8&e=
 

[onap-tsc] Updated TSC Charter

[SPATSCHECK, OLIVER (OLIVER)]

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.  

Let?s just start with A. A&AI 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&AI

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? 

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

[SULLIVAN, BRYAN L]

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&T

-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

[SPATSCHECK, OLIVER (OLIVER)]

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

[Ed Warnicke]

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) <
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]
> *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
> *Subject:* Re: [onap-tsc] Updated TSC Charter
>
>
>
> Inline...
>
>
>
> On Fri, Apr 21, 2017 at 11:01 AM, SPATSCHECK, OLIVER (OLIVER) <
> 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  wrote:
> >
> > Inline...
> >
> > On Fri, Apr 21, 2017 at 9:22 AM, SPATSCHECK, OLIVER (OLIVER) <
> 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&AI 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&AI
> >
> > 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 actu

[onap-tsc] Updated TSC Charter

[Ed Warnicke]

Inline...

On Fri, Apr 21, 2017 at 11:01 AM, SPATSCHECK, OLIVER (OLIVER) <
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  wrote:
> >
> > Inline...
> >
> > On Fri, Apr 21, 2017 at 9:22 AM, SPATSCHECK, OLIVER (OLIVER) <
> 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&AI 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&AI
> >
> > 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) <
> spatsch at 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
> conce

[onap-tsc] Updated TSC Charter

[Ed Warnicke]

Inline...

On Fri, Apr 21, 2017 at 9:22 AM, SPATSCHECK, OLIVER (OLIVER) <
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&AI 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&AI
>
> 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) <
> spatsch at 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
> >
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 

[onap-tsc] Updated TSC Charter

[Ed Warnicke]

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) <
spatsch at 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
>
-- next part --
An HTML attachment was scrubbed...
URL: 

[onap-tsc] Updated TSC Charter

[Christopher Donley (Chris)]

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&T

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

[onap-tsc] Updated TSC Charter

[Christopher Donley (Chris)]

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&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4&m=qanJmrKS-8k07dPd2m4vkZO_i076Fj4PF-Z_thIkNw0&s=ZQWOusx5K1pirGXMQqTdJ2gLSS1c8QUaIsa1vwqQrWI&e=>
___
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&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4&m=qanJmrKS-8k07dPd2m4vkZO_i076Fj4PF-Z_thIkNw0&s=pJET50QlbJFhc7UGw25LtzuYI1yz0pcrvdaq_1clvDw&e=

-- 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

[Dhananjay Pavgi]

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&T

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/

[onap-tsc] Updated TSC Charter

[SPATSCHECK, OLIVER (OLIVER)]

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&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4&m=qanJmrKS-8k07dPd2m4vkZO_i076Fj4PF-Z_thIkNw0&s=ZQWOusx5K1pirGXMQqTdJ2gLSS1c8QUaIsa1vwqQrWI&e=>
___
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&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4&m=qanJmrKS-8k07dPd2m4vkZO_i076Fj4PF-Z_thIkNw0&s=pJET50QlbJFhc7UGw25LtzuYI1yz0pcrvdaq_1clvDw&e=

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.onap.org/pipermail/onap-tsc/attachments/20170420/9b1d7f00/attachment-0001.html>

[onap-tsc] Updated TSC Charter

[Alla Goldner]

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-boun...@lists.onap.org] On Behalf Of Don Clarke
Sent: Thursday, April 20, 2017 8:48 AM
To: Christopher Donley (Chris) ; onap-tsc at 
lists.onap.org
Cc: Ed Warnicke 
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://www.amdocs.com/about/email-disclaimer>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.onap.org/pipermail/onap-tsc/attachments/20170420/a221de6c/attachment.html>

[onap-tsc] Updated TSC Charter

[Don Clarke]

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-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
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
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.onap.org/pipermail/onap-tsc/attachments/20170420/41486878/attachment-0001.html>

[onap-tsc] Updated TSC Charter

[Yunxia Chen]

Thanks Bryan.
Yes, Bitergia is also used by:
?   Linux Foundation 
https://linuxfoundation.biterg.io<https://linuxfoundation.biterg.io/>
?   Eclipse Foundation https://eclipse.biterg.io<https://eclipse.biterg.io/>
Which provides Comprehensive analytics; supports many data sources
?   Git/Gerrit, Confluence, Jira, Jenkins, IRC, Mailing Lists, AskBot, 
Bugzilla, etc.
But it is not free, up to 15K per year. I personally believe it worth it.  It 
is up to the board to approve the funding. ?

While Spectrometer only supports git/gerrit and mailing lists, but it is free.

Regards,

Helen Chen

From: "SULLIVAN, BRYAN L" 
Date: Wednesday, April 19, 2017 at 12:30 PM
To: Helen Chen 00725961 , Ed Warnicke 
Cc: Ed Warnicke , "onap-tsc at lists.onap.org" 
Subject: RE: [onap-tsc] Updated TSC Charter

FYI, you can see an example of what they can do (bitergia) at 
https://opnfv.biterg.io/.
With some understanding of what it shows you, its possible to gain a valuable 
perspective on how well the community is working.

Thanks,
Bryan Sullivan | AT&T

From: onap-tsc-bounces at lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Yunxia Chen
Sent: Wednesday, April 19, 2017 11:58 AM
To: SULLIVAN, BRYAN L ; Ed Warnicke 
Cc: Ed Warnicke ; onap-tsc at lists.onap.org
Subject: Re: [onap-tsc] Updated TSC Charter

Bitergia or Spectrometer could put ONAP community?s various activities / 
contribution, including integrating with Gerrit data, etc.,  together. I could 
volunteer working on it and welcome more help and suggestion.

Regards,

Helen Chen

From: mailto:onap-tsc-bounces at 
lists.onap.org>> on behalf of "SULLIVAN, BRYAN L" mailto:bs3...@att.com>>
Date: Wednesday, April 19, 2017 at 10:56 AM
To: Ed Warnicke mailto:hagbard at gmail.com>>
Cc: "onap-tsc at lists.onap.org<mailto:onap-tsc at lists.onap.org>" mailto:onap-tsc at lists.onap.org>>, Ed Warnicke mailto:eaw at cisco.com>>
Subject: Re: [onap-tsc] Updated TSC Charter

Gerrit can also provide info on reviews, documentation contributions, etc. 
Tests and project infra I assume you could class as code, but these other types 
of contributions are also tracked by gerrit.

Thanks,
Bryan Sullivan | AT&T

From: Ed Warnicke [mailto:hagb...@gmail.com]
Sent: Wednesday, April 19, 2017 10:50 AM
To: SULLIVAN, BRYAN L mailto:bs3131 at att.com>>
Cc: Christopher Donley (Chris) mailto:Christopher.Donley at huawei.com>>; onap-tsc at 
lists.onap.org<mailto:onap-tsc at lists.onap.org>; Ed Warnicke mailto:eaw at cisco.com>>
Subject: Re: [onap-tsc] Updated TSC Charter

Brian,

How would one be able to point to demonstration of meritocratic contribution 
for non-code contribution for the purpose of committer promotion?  For code 
contribution (and test case automation, which also then turns out to be code) 
one can point to the gerrit history.  For these other kinds of contribution, 
what would be the analog demonstration?

Ed

On Wed, Apr 19, 2017 at 10:12 AM, SULLIVAN, BRYAN L mailto:bs3131 at att.com>> wrote:
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&T

From: onap-tsc-bounces at lists.onap.org<mailto: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 Char

[onap-tsc] Updated TSC Charter

[SULLIVAN, BRYAN L]

I agree also ? specializations in project repos is a natural way to focus 
contributors with different skill sets. That?s one of the reasons for my 
?multiple repos per project? comment. Often I see docs and code (at least) 
being managed in separate repos, under a single project. Code can be further 
managed in separate repos (e.g. service and client as in OpenStack). Thus the 
committers to those repos have the meritocratic history in the related skills 
and artifacts, centered around the purpose for the repo (which nonetheless can 
host artifacts of various types, e.g. user guides/readmes, unit tests, ? even 
if it?s mostly focused on one type of artifact).

The comment about using the generic ?contribution? term (vs code) was to 
reflect those various types of contribution as the prerequisite to being a 
committer, of whatever focus. So overall I think we are in agreement.

Thanks,
Bryan Sullivan | AT&T

From: Ed Warnicke [mailto:hagb...@gmail.com]
Sent: Wednesday, April 19, 2017 12:59 PM
To: SULLIVAN, BRYAN L 
Cc: Christopher Donley (Chris) ; onap-tsc at 
lists.onap.org; Ed Warnicke 
Subject: Re: [onap-tsc] Updated TSC Charter

Bryan,

I agree with you that it's good to get architecture documents in git repos 
managed via gerrit :)  That's pure goodness.

The essense of committerness is the ability to merge a patch into a project's 
repo.  Because of this a committer should have expertise appropriate to 
exercising that ability.  One highly productive way I've seen this handled in 
other communities is to have your 'code' project, where the metric for 
committerness is code contribution as a demonstration of merit.  System test 
often has its own, separate project because the skillset for producing good 
system tests is often distinct from the skillset for generating good underlying 
code, and is often written in different languages with different tools.  
Similarly for 'user facing docs' and 'architecture docs'.  By having them be 
separate projects with separate committer pools, you select for people with the 
correct skillset to make decisions about merging to each.

This makes things fairly simple.  People become committers on 'code' projects 
by contributing code, on testing projects by contributing testing, on user 
facing doc projects by contributing user facing docs, and on architecture doc 
projects by contributing to architecture docs.  It also has the nice effect of 
building communities around each function that value each kind of contribution.

Ed

On Wed, Apr 19, 2017 at 11:07 AM, SULLIVAN, BRYAN L mailto:bs3131 at att.com>> wrote:
Yes, IMO architecture as documented should be managed thru gerrit. Discussions 
and preliminary proposals can be on wikis etc (even etherpads), but at some 
point a document is written, reviewed, and change-managed. Those stages should 
be managed thru gerrit using a document format that works for the community. I 
recommend git/gerrit-friendly formats e.g. RST which can also incorporate rich 
text artifacts (e.g. diagrams). But even pure rich-text format docs can be 
reviewed thru gerrit if the proposed changes are adequately summarized in the 
commit message and comments to it.

Thanks,
Bryan Sullivan | AT&T

From: Ed Warnicke [mailto:hagbard at gmail.com<mailto:hagb...@gmail.com>]
Sent: Wednesday, April 19, 2017 11:00 AM

To: SULLIVAN, BRYAN L mailto:bs3131 at att.com>>
Cc: Christopher Donley (Chris) mailto:Christopher.Donley at huawei.com>>; onap-tsc at 
lists.onap.org<mailto:onap-tsc at lists.onap.org>; Ed Warnicke mailto:eaw at cisco.com>>
Subject: Re: [onap-tsc] Updated TSC Charter

Totally agree that gerrit can provide info on reviews, and that documentation 
and test code contributions simply show up as patches in whichever project they 
are contributed to.  Do you see contributions to architecture coming via 
reviews?

Ed

On Wed, Apr 19, 2017 at 10:56 AM, SULLIVAN, BRYAN L mailto:bs3131 at att.com>> wrote:
Gerrit can also provide info on reviews, documentation contributions, etc. 
Tests and project infra I assume you could class as code, but these other types 
of contributions are also tracked by gerrit.

Thanks,
Bryan Sullivan | AT&T

From: Ed Warnicke [mailto:hagbard at gmail.com<mailto:hagb...@gmail.com>]
Sent: Wednesday, April 19, 2017 10:50 AM
To: SULLIVAN, BRYAN L mailto:bs3131 at att.com>>
Cc: Christopher Donley (Chris) mailto:Christopher.Donley at huawei.com>>; onap-tsc at 
lists.onap.org<mailto:onap-tsc at lists.onap.org>; Ed Warnicke mailto:eaw at cisco.com>>
Subject: Re: [onap-tsc] Updated TSC Charter

Brian,

How would one be able to point to demonstration of meritocratic contribution 
for non-code contribution for the purpose of committer promotion?  For code 
contribution (and test case automation, which also then turns out to be code) 
one can point to the gerrit history.  For these other k

[onap-tsc] Updated TSC Charter

[SULLIVAN, BRYAN L]

FYI, you can see an example of what they can do (bitergia) at 
https://opnfv.biterg.io/.
With some understanding of what it shows you, its possible to gain a valuable 
perspective on how well the community is working.

Thanks,
Bryan Sullivan | AT&T

From: onap-tsc-bounces at lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Yunxia Chen
Sent: Wednesday, April 19, 2017 11:58 AM
To: SULLIVAN, BRYAN L ; Ed Warnicke 
Cc: Ed Warnicke ; onap-tsc at lists.onap.org
Subject: Re: [onap-tsc] Updated TSC Charter

Bitergia or Spectrometer could put ONAP community?s various activities / 
contribution, including integrating with Gerrit data, etc.,  together. I could 
volunteer working on it and welcome more help and suggestion.

Regards,

Helen Chen

From: mailto:onap-tsc-bounces at 
lists.onap.org>> on behalf of "SULLIVAN, BRYAN L" mailto:bs3...@att.com>>
Date: Wednesday, April 19, 2017 at 10:56 AM
To: Ed Warnicke mailto:hagbard at gmail.com>>
Cc: "onap-tsc at lists.onap.org<mailto:onap-tsc at lists.onap.org>" mailto:onap-tsc at lists.onap.org>>, Ed Warnicke mailto:eaw at cisco.com>>
Subject: Re: [onap-tsc] Updated TSC Charter

Gerrit can also provide info on reviews, documentation contributions, etc. 
Tests and project infra I assume you could class as code, but these other types 
of contributions are also tracked by gerrit.

Thanks,
Bryan Sullivan | AT&T

From: Ed Warnicke [mailto:hagb...@gmail.com]
Sent: Wednesday, April 19, 2017 10:50 AM
To: SULLIVAN, BRYAN L mailto:bs3131 at att.com>>
Cc: Christopher Donley (Chris) mailto:Christopher.Donley at huawei.com>>; onap-tsc at 
lists.onap.org<mailto:onap-tsc at lists.onap.org>; Ed Warnicke mailto:eaw at cisco.com>>
Subject: Re: [onap-tsc] Updated TSC Charter

Brian,

How would one be able to point to demonstration of meritocratic contribution 
for non-code contribution for the purpose of committer promotion?  For code 
contribution (and test case automation, which also then turns out to be code) 
one can point to the gerrit history.  For these other kinds of contribution, 
what would be the analog demonstration?

Ed

On Wed, Apr 19, 2017 at 10:12 AM, SULLIVAN, BRYAN L mailto:bs3131 at att.com>> wrote:
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&T

From: onap-tsc-bounces at lists.onap.org<mailto: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

___
ONAP-TSC mailing list
ONAP-TSC at lists.onap.org<mailto:ONAP-TSC at lists.onap.org>
https://lists.onap.org/mailman/listinfo/onap-tsc<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OrbtGCluczz9awEKz9Fv7g&m=p0kzAvQDjXsrgQPIbU8s2Jv4A-H7H4aAbsbfuneN4Rg&s=vKRHTwaZCMn5ytWOCvgd

[onap-tsc] Updated TSC Charter

[SULLIVAN, BRYAN L]

Sure, that works too. I had recently heard this MVP term being used and thought 
it would be good to clarify - but the more acronyms we can avoid, the better!

Thanks,
Bryan Sullivan | AT&T

From: onap-tsc-bounces at lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Stephen Terrill
Sent: Wednesday, April 19, 2017 12:02 PM
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&T

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
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.onap.org/pipermail/onap-tsc/attachments/20170419/9922f42c/attachment-0001.html>

[onap-tsc] Updated TSC Charter

[Stephen Terrill]

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-boun...@lists.onap.org] On Behalf Of SULLIVAN, BRYAN L
Sent: 19 April 2017 19:12
To: Christopher Donley (Chris) ; onap-tsc at 
lists.onap.org
Cc: Ed Warnicke 
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&T

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
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.onap.org/pipermail/onap-tsc/attachments/20170419/6d2dbbdb/attachment-0001.html>

[onap-tsc] Updated TSC Charter

[Yunxia Chen]

Bitergia or Spectrometer could put ONAP community?s various activities / 
contribution, including integrating with Gerrit data, etc.,  together. I could 
volunteer working on it and welcome more help and suggestion.

Regards,

Helen Chen

From:  on behalf of "SULLIVAN, BRYAN L" 

Date: Wednesday, April 19, 2017 at 10:56 AM
To: Ed Warnicke 
Cc: "onap-tsc at lists.onap.org" , Ed Warnicke 
Subject: Re: [onap-tsc] Updated TSC Charter

Gerrit can also provide info on reviews, documentation contributions, etc. 
Tests and project infra I assume you could class as code, but these other types 
of contributions are also tracked by gerrit.

Thanks,
Bryan Sullivan | AT&T

From: Ed Warnicke [mailto:hagb...@gmail.com]
Sent: Wednesday, April 19, 2017 10:50 AM
To: SULLIVAN, BRYAN L 
Cc: Christopher Donley (Chris) ; onap-tsc at 
lists.onap.org; Ed Warnicke 
Subject: Re: [onap-tsc] Updated TSC Charter

Brian,

How would one be able to point to demonstration of meritocratic contribution 
for non-code contribution for the purpose of committer promotion?  For code 
contribution (and test case automation, which also then turns out to be code) 
one can point to the gerrit history.  For these other kinds of contribution, 
what would be the analog demonstration?

Ed

On Wed, Apr 19, 2017 at 10:12 AM, SULLIVAN, BRYAN L mailto:bs3131 at att.com>> wrote:
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&T

From: onap-tsc-bounces at lists.onap.org<mailto: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

___
ONAP-TSC mailing list
ONAP-TSC at lists.onap.org<mailto:ONAP-TSC at lists.onap.org>
https://lists.onap.org/mailman/listinfo/onap-tsc<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OrbtGCluczz9awEKz9Fv7g&m=p0kzAvQDjXsrgQPIbU8s2Jv4A-H7H4aAbsbfuneN4Rg&s=vKRHTwaZCMn5ytWOCvgd5Lh-5iID3MW7HnGXLUdQlEI&e=>

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.onap.org/pipermail/onap-tsc/attachments/20170419/ad970f33/attachment.html>

[onap-tsc] Updated TSC Charter

[SULLIVAN, BRYAN L]

Yes, IMO architecture as documented should be managed thru gerrit. Discussions 
and preliminary proposals can be on wikis etc (even etherpads), but at some 
point a document is written, reviewed, and change-managed. Those stages should 
be managed thru gerrit using a document format that works for the community. I 
recommend git/gerrit-friendly formats e.g. RST which can also incorporate rich 
text artifacts (e.g. diagrams). But even pure rich-text format docs can be 
reviewed thru gerrit if the proposed changes are adequately summarized in the 
commit message and comments to it.

Thanks,
Bryan Sullivan | AT&T

From: Ed Warnicke [mailto:hagb...@gmail.com]
Sent: Wednesday, April 19, 2017 11:00 AM
To: SULLIVAN, BRYAN L 
Cc: Christopher Donley (Chris) ; onap-tsc at 
lists.onap.org; Ed Warnicke 
Subject: Re: [onap-tsc] Updated TSC Charter

Totally agree that gerrit can provide info on reviews, and that documentation 
and test code contributions simply show up as patches in whichever project they 
are contributed to.  Do you see contributions to architecture coming via 
reviews?

Ed

On Wed, Apr 19, 2017 at 10:56 AM, SULLIVAN, BRYAN L mailto:bs3131 at att.com>> wrote:
Gerrit can also provide info on reviews, documentation contributions, etc. 
Tests and project infra I assume you could class as code, but these other types 
of contributions are also tracked by gerrit.

Thanks,
Bryan Sullivan | AT&T

From: Ed Warnicke [mailto:hagbard at gmail.com<mailto:hagb...@gmail.com>]
Sent: Wednesday, April 19, 2017 10:50 AM
To: SULLIVAN, BRYAN L mailto:bs3131 at att.com>>
Cc: Christopher Donley (Chris) mailto:Christopher.Donley at huawei.com>>; onap-tsc at 
lists.onap.org<mailto:onap-tsc at lists.onap.org>; Ed Warnicke mailto:eaw at cisco.com>>
Subject: Re: [onap-tsc] Updated TSC Charter

Brian,

How would one be able to point to demonstration of meritocratic contribution 
for non-code contribution for the purpose of committer promotion?  For code 
contribution (and test case automation, which also then turns out to be code) 
one can point to the gerrit history.  For these other kinds of contribution, 
what would be the analog demonstration?

Ed

On Wed, Apr 19, 2017 at 10:12 AM, SULLIVAN, BRYAN L mailto:bs3131 at att.com>> wrote:
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&T

From: onap-tsc-bounces at lists.onap.org<mailto: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

___
ONAP-TSC mailing list
ONAP-TSC at lists.onap.org<mailto:ONAP-TSC at lists.onap.org>
https://lists.onap.org/mailman/listinfo/onap-tsc<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OrbtGCluczz9awEKz9Fv7g&m=p0kzAvQDjXsrgQPIbU8s2Jv4A-H7H4aAbsbfuneN4Rg&s=vKRHT

[onap-tsc] Updated TSC Charter

[SULLIVAN, BRYAN L]

Gerrit can also provide info on reviews, documentation contributions, etc. 
Tests and project infra I assume you could class as code, but these other types 
of contributions are also tracked by gerrit.

Thanks,
Bryan Sullivan | AT&T

From: Ed Warnicke [mailto:hagb...@gmail.com]
Sent: Wednesday, April 19, 2017 10:50 AM
To: SULLIVAN, BRYAN L 
Cc: Christopher Donley (Chris) ; onap-tsc at 
lists.onap.org; Ed Warnicke 
Subject: Re: [onap-tsc] Updated TSC Charter

Brian,

How would one be able to point to demonstration of meritocratic contribution 
for non-code contribution for the purpose of committer promotion?  For code 
contribution (and test case automation, which also then turns out to be code) 
one can point to the gerrit history.  For these other kinds of contribution, 
what would be the analog demonstration?

Ed

On Wed, Apr 19, 2017 at 10:12 AM, SULLIVAN, BRYAN L mailto:bs3131 at att.com>> wrote:
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&T

From: onap-tsc-bounces at lists.onap.org<mailto: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

___
ONAP-TSC mailing list
ONAP-TSC at lists.onap.org<mailto:ONAP-TSC at lists.onap.org>
https://lists.onap.org/mailman/listinfo/onap-tsc<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OrbtGCluczz9awEKz9Fv7g&m=p0kzAvQDjXsrgQPIbU8s2Jv4A-H7H4aAbsbfuneN4Rg&s=vKRHTwaZCMn5ytWOCvgd5Lh-5iID3MW7HnGXLUdQlEI&e=>

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.onap.org/pipermail/onap-tsc/attachments/20170419/4572ed7e/attachment-0001.html>

[onap-tsc] Updated TSC Charter

[SULLIVAN, BRYAN L]

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&T

From: 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
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
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.onap.org/pipermail/onap-tsc/attachments/20170419/fe20ac1d/attachment-0001.html>
-- next part --
A non-text attachment was scrubbed...
Name: ONAP TSC Charter DRAFT 6 8 CLEAN.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 102673 bytes
Desc: ONAP TSC Charter DRAFT 6 8 CLEAN.docx
URL: 
<http://lists.onap.org/pipermail/onap-tsc/attachments/20170419/fe20ac1d/attachment-0001.docx>

[onap-tsc] Updated TSC Charter

[Christopher Donley (Chris)]

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
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: ONAP TSC Charter DRAFT 6 8 CLEAN.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 108068 bytes
Desc: ONAP TSC Charter DRAFT 6 8 CLEAN.docx
URL: 

[onap-tsc] Updated TSC Charter

[Brian Hedstrom]

I think it's important to choose a collaborative documentation control and
development environment where many can simultaneously contribute to the
document artifact, as well as architecture specification artifacts such as
UML models developed under something like Eclipse/Papyrus. There are ways
to use the Confluence Wiki for collaboratively developing documents,
generating PDFs of them if an offline copy is needed, and
protecting/restricting them from updates as they move through the process.
I'd like to see the charter up there in Wiki form with restrictions set at
view only for the community.

On Wed, Apr 19, 2017 at 12:07 PM, SULLIVAN, BRYAN L  wrote:

> Yes, IMO architecture as documented should be managed thru gerrit.
> Discussions and preliminary proposals can be on wikis etc (even etherpads),
> but at some point a document is written, reviewed, and change-managed.
> Those stages should be managed thru gerrit using a document format that
> works for the community. I recommend git/gerrit-friendly formats e.g. RST
> which can also incorporate rich text artifacts (e.g. diagrams). But even
> pure rich-text format docs can be reviewed thru gerrit if the proposed
> changes are adequately summarized in the commit message and comments to it.
>
>
>
> Thanks,
>
> Bryan Sullivan | AT&T
>
>
>
> *From:* Ed Warnicke [mailto:hagbard at gmail.com]
> *Sent:* Wednesday, April 19, 2017 11:00 AM
>
> *To:* SULLIVAN, BRYAN L 
> *Cc:* Christopher Donley (Chris) ;
> onap-tsc at lists.onap.org; Ed Warnicke 
> *Subject:* Re: [onap-tsc] Updated TSC Charter
>
>
>
> Totally agree that gerrit can provide info on reviews, and that
> documentation and test code contributions simply show up as patches in
> whichever project they are contributed to.  Do you see contributions to
> architecture coming via reviews?
>
>
>
> Ed
>
>
>
> On Wed, Apr 19, 2017 at 10:56 AM, SULLIVAN, BRYAN L 
> wrote:
>
> Gerrit can also provide info on reviews, documentation contributions, etc.
> Tests and project infra I assume you could class as code, but these other
> types of contributions are also tracked by gerrit.
>
>
>
> Thanks,
>
> Bryan Sullivan | AT&T
>
>
>
> *From:* Ed Warnicke [mailto:hagbard at gmail.com]
> *Sent:* Wednesday, April 19, 2017 10:50 AM
> *To:* SULLIVAN, BRYAN L 
> *Cc:* Christopher Donley (Chris) ;
> onap-tsc at lists.onap.org; Ed Warnicke 
> *Subject:* Re: [onap-tsc] Updated TSC Charter
>
>
>
> Brian,
>
>
>
> How would one be able to point to demonstration of meritocratic
> contribution for non-code contribution for the purpose of committer
> promotion?  For code contribution (and test case automation, which also
> then turns out to be code) one can point to the gerrit history.  For these
> other kinds of contribution, what would be the analog demonstration?
>
>
>
> Ed
>
>
>
> On Wed, Apr 19, 2017 at 10:12 AM, SULLIVAN, BRYAN L 
> wrote:
>
> 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&T
>
>
>
> *From:* onap-tsc-bounces at lists.onap.org [mailto:onap-tsc-bounces@
> lists.onap.org] *On Behalf Of *Christopher Donley (Chris)
> *Sent:* Wednesday, April 19, 2017 8:45 AM
> *To:* onap-tsc at lists.onap.org
> *

[onap-tsc] Updated TSC Charter

[Ed Warnicke]

I think we are in agreement :)

Ed

On Wed, Apr 19, 2017 at 1:15 PM, SULLIVAN, BRYAN L  wrote:

> I agree also ? specializations in project repos is a natural way to focus
> contributors with different skill sets. That?s one of the reasons for my
> ?multiple repos per project? comment. Often I see docs and code (at least)
> being managed in separate repos, under a single project. Code can be
> further managed in separate repos (e.g. service and client as in
> OpenStack). Thus the committers to those repos have the meritocratic
> history in the related skills and artifacts, centered around the purpose
> for the repo (which nonetheless can host artifacts of various types, e.g.
> user guides/readmes, unit tests, ? even if it?s mostly focused on one type
> of artifact).
>
>
>
> The comment about using the generic ?contribution? term (vs code) was to
> reflect those various types of contribution as the prerequisite to being a
> committer, of whatever focus. So overall I think we are in agreement.
>
>
>
> Thanks,
>
> Bryan Sullivan | AT&T
>
>
>
> *From:* Ed Warnicke [mailto:hagbard at gmail.com]
> *Sent:* Wednesday, April 19, 2017 12:59 PM
>
> *To:* SULLIVAN, BRYAN L 
> *Cc:* Christopher Donley (Chris) ;
> onap-tsc at lists.onap.org; Ed Warnicke 
> *Subject:* Re: [onap-tsc] Updated TSC Charter
>
>
>
> Bryan,
>
>
>
> I agree with you that it's good to get architecture documents in git repos
> managed via gerrit :)  That's pure goodness.
>
>
>
> The essense of committerness is the ability to merge a patch into a
> project's repo.  Because of this a committer should have expertise
> appropriate to exercising that ability.  One highly productive way I've
> seen this handled in other communities is to have your 'code' project,
> where the metric for committerness is code contribution as a demonstration
> of merit.  System test often has its own, separate project because the
> skillset for producing good system tests is often distinct from the
> skillset for generating good underlying code, and is often written in
> different languages with different tools.  Similarly for 'user facing docs'
> and 'architecture docs'.  By having them be separate projects with separate
> committer pools, you select for people with the correct skillset to make
> decisions about merging to each.
>
>
>
> This makes things fairly simple.  People become committers on 'code'
> projects by contributing code, on testing projects by contributing testing,
> on user facing doc projects by contributing user facing docs, and on
> architecture doc projects by contributing to architecture docs.  It also
> has the nice effect of building communities around each function that value
> each kind of contribution.
>
>
>
> Ed
>
>
>
> On Wed, Apr 19, 2017 at 11:07 AM, SULLIVAN, BRYAN L 
> wrote:
>
> Yes, IMO architecture as documented should be managed thru gerrit.
> Discussions and preliminary proposals can be on wikis etc (even etherpads),
> but at some point a document is written, reviewed, and change-managed.
> Those stages should be managed thru gerrit using a document format that
> works for the community. I recommend git/gerrit-friendly formats e.g. RST
> which can also incorporate rich text artifacts (e.g. diagrams). But even
> pure rich-text format docs can be reviewed thru gerrit if the proposed
> changes are adequately summarized in the commit message and comments to it.
>
>
>
> Thanks,
>
> Bryan Sullivan | AT&T
>
>
>
> *From:* Ed Warnicke [mailto:hagbard at gmail.com]
> *Sent:* Wednesday, April 19, 2017 11:00 AM
>
>
> *To:* SULLIVAN, BRYAN L 
> *Cc:* Christopher Donley (Chris) ;
> onap-tsc at lists.onap.org; Ed Warnicke 
> *Subject:* Re: [onap-tsc] Updated TSC Charter
>
>
>
> Totally agree that gerrit can provide info on reviews, and that
> documentation and test code contributions simply show up as patches in
> whichever project they are contributed to.  Do you see contributions to
> architecture coming via reviews?
>
>
>
> Ed
>
>
>
> On Wed, Apr 19, 2017 at 10:56 AM, SULLIVAN, BRYAN L 
> wrote:
>
> Gerrit can also provide info on reviews, documentation contributions, etc.
> Tests and project infra I assume you could class as code, but these other
> types of contributions are also tracked by gerrit.
>
>
>
> Thanks,
>
> Bryan Sullivan | AT&T
>
>
>
> *From:* Ed Warnicke [mailto:hagbard at gmail.com]
> *Sent:* Wednesday, April 19, 2017 10:50 AM
> *To:* SULLIVAN, BRYAN L 
> *Cc:* Christopher Donley (Chris) ;
> onap-tsc at lists.onap.org; Ed Warnicke 
> *Subject:* Re: [onap-tsc] U

[onap-tsc] Updated TSC Charter

[Ed Warnicke]

Bryan,

I agree with you that it's good to get architecture documents in git repos
managed via gerrit :)  That's pure goodness.

The essense of committerness is the ability to merge a patch into a
project's repo.  Because of this a committer should have expertise
appropriate to exercising that ability.  One highly productive way I've
seen this handled in other communities is to have your 'code' project,
where the metric for committerness is code contribution as a demonstration
of merit.  System test often has its own, separate project because the
skillset for producing good system tests is often distinct from the
skillset for generating good underlying code, and is often written in
different languages with different tools.  Similarly for 'user facing docs'
and 'architecture docs'.  By having them be separate projects with separate
committer pools, you select for people with the correct skillset to make
decisions about merging to each.

This makes things fairly simple.  People become committers on 'code'
projects by contributing code, on testing projects by contributing testing,
on user facing doc projects by contributing user facing docs, and on
architecture doc projects by contributing to architecture docs.  It also
has the nice effect of building communities around each function that value
each kind of contribution.

Ed

On Wed, Apr 19, 2017 at 11:07 AM, SULLIVAN, BRYAN L  wrote:

> Yes, IMO architecture as documented should be managed thru gerrit.
> Discussions and preliminary proposals can be on wikis etc (even etherpads),
> but at some point a document is written, reviewed, and change-managed.
> Those stages should be managed thru gerrit using a document format that
> works for the community. I recommend git/gerrit-friendly formats e.g. RST
> which can also incorporate rich text artifacts (e.g. diagrams). But even
> pure rich-text format docs can be reviewed thru gerrit if the proposed
> changes are adequately summarized in the commit message and comments to it.
>
>
>
> Thanks,
>
> Bryan Sullivan | AT&T
>
>
>
> *From:* Ed Warnicke [mailto:hagbard at gmail.com]
> *Sent:* Wednesday, April 19, 2017 11:00 AM
>
> *To:* SULLIVAN, BRYAN L 
> *Cc:* Christopher Donley (Chris) ;
> onap-tsc at lists.onap.org; Ed Warnicke 
> *Subject:* Re: [onap-tsc] Updated TSC Charter
>
>
>
> Totally agree that gerrit can provide info on reviews, and that
> documentation and test code contributions simply show up as patches in
> whichever project they are contributed to.  Do you see contributions to
> architecture coming via reviews?
>
>
>
> Ed
>
>
>
> On Wed, Apr 19, 2017 at 10:56 AM, SULLIVAN, BRYAN L 
> wrote:
>
> Gerrit can also provide info on reviews, documentation contributions, etc.
> Tests and project infra I assume you could class as code, but these other
> types of contributions are also tracked by gerrit.
>
>
>
> Thanks,
>
> Bryan Sullivan | AT&T
>
>
>
> *From:* Ed Warnicke [mailto:hagbard at gmail.com]
> *Sent:* Wednesday, April 19, 2017 10:50 AM
> *To:* SULLIVAN, BRYAN L 
> *Cc:* Christopher Donley (Chris) ;
> onap-tsc at lists.onap.org; Ed Warnicke 
> *Subject:* Re: [onap-tsc] Updated TSC Charter
>
>
>
> Brian,
>
>
>
> How would one be able to point to demonstration of meritocratic
> contribution for non-code contribution for the purpose of committer
> promotion?  For code contribution (and test case automation, which also
> then turns out to be code) one can point to the gerrit history.  For these
> other kinds of contribution, what would be the analog demonstration?
>
>
>
> Ed
>
>
>
> On Wed, Apr 19, 2017 at 10:12 AM, SULLIVAN, BRYAN L 
> wrote:
>
> 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
> 

[onap-tsc] Updated TSC Charter

[Ed Warnicke]

Totally agree that gerrit can provide info on reviews, and that
documentation and test code contributions simply show up as patches in
whichever project they are contributed to.  Do you see contributions to
architecture coming via reviews?

Ed

On Wed, Apr 19, 2017 at 10:56 AM, SULLIVAN, BRYAN L  wrote:

> Gerrit can also provide info on reviews, documentation contributions, etc.
> Tests and project infra I assume you could class as code, but these other
> types of contributions are also tracked by gerrit.
>
>
>
> Thanks,
>
> Bryan Sullivan | AT&T
>
>
>
> *From:* Ed Warnicke [mailto:hagbard at gmail.com]
> *Sent:* Wednesday, April 19, 2017 10:50 AM
> *To:* SULLIVAN, BRYAN L 
> *Cc:* Christopher Donley (Chris) ;
> onap-tsc at lists.onap.org; Ed Warnicke 
> *Subject:* Re: [onap-tsc] Updated TSC Charter
>
>
>
> Brian,
>
>
>
> How would one be able to point to demonstration of meritocratic
> contribution for non-code contribution for the purpose of committer
> promotion?  For code contribution (and test case automation, which also
> then turns out to be code) one can point to the gerrit history.  For these
> other kinds of contribution, what would be the analog demonstration?
>
>
>
> Ed
>
>
>
> On Wed, Apr 19, 2017 at 10:12 AM, SULLIVAN, BRYAN L 
> wrote:
>
> 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&T
>
>
>
> *From:* onap-tsc-bounces at lists.onap.org [mailto:onap-tsc-bounces@
> lists.onap.org] *On Behalf Of *Christopher Donley (Chris)
> *Sent:* Wednesday, April 19, 2017 8:45 AM
> *To:* 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
>
>
> ___
> ONAP-TSC mailing list
> ONAP-TSC at lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-tsc
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OrbtGCluczz9awEKz9Fv7g&m=p0kzAvQDjXsrgQPIbU8s2Jv4A-H7H4aAbsbfuneN4Rg&s=vKRHTwaZCMn5ytWOCvgd5Lh-5iID3MW7HnGXLUdQlEI&e=>
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.onap.org/pipermail/onap-tsc/attachments/20170419/eafadac3/attachment-0001.html>

[onap-tsc] Updated TSC Charter

[Ed Warnicke]

Brian,

How would one be able to point to demonstration of meritocratic
contribution for non-code contribution for the purpose of committer
promotion?  For code contribution (and test case automation, which also
then turns out to be code) one can point to the gerrit history.  For these
other kinds of contribution, what would be the analog demonstration?

Ed

On Wed, Apr 19, 2017 at 10:12 AM, SULLIVAN, BRYAN L  wrote:

> 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&T
>
>
>
> *From:* onap-tsc-bounces at lists.onap.org [mailto:onap-tsc-bounces@
> lists.onap.org] *On Behalf Of *Christopher Donley (Chris)
> *Sent:* Wednesday, April 19, 2017 8:45 AM
> *To:* 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
>
> ___
> ONAP-TSC mailing list
> ONAP-TSC at lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-tsc
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.onap.org/pipermail/onap-tsc/attachments/20170419/fd972f81/attachment.html>