Hi Phil,

thanks for the clarification – I missed the “end-user” constraint. Still IMHO 
it would make sense to have another option (“#4”) for a larger TSC included – 
which would allow for a broader organizational representation. Could you add 
that? Way we’d have pretty much the overall spectrum of options covered.

Thanks, Frank

From: Phil Robb <[email protected]>
Sent: Donnerstag, 19. April 2018 16:21
To: Frank Brockners (fbrockne) <[email protected]>
Cc: [email protected]
Subject: Re: [onap-tsc] TSC Composition Proposal

Hi Frank.

The concern I'm trying to address is for the *service provider* platinum 
members, who a) are beginning plans to put ONAP as a critical piece of their 
infrastructure while b) not yet having had the chance to ramp up their 
developer teams and engage in the community because they are new to this whole 
process.  It was not intended to guarantee TSC representation by all Platinum 
Members, only the Service Provider Platinum members, so the TSC count would 
max-out in the low 20s not the low 30s.  However, some service providers will 
certainly be represented on the TSC by their developers so a likely TSC number 
would be high teens... 18 to 20; it's really the Service Providers that are 
"newer" to ONAP that we're trying to ensure have representation on the 
developer community leadership.  That's the fundamental concern I'm trying to 
address with the proposals #2 and #3.

Best,

Phil.

On Thu, Apr 19, 2018 at 7:56 AM, Frank Brockners (fbrockne) 
<[email protected]<mailto:[email protected]>> wrote:
Thanks Phil. From reading through the options below, it seems as if there is a 
desire to get a broader representation of the contributing companies in the TSC 
than what would happen with just 15 TSC members. At the same time, with option 
#3 the TSC could eventually grow (worst case) to (15 + #of-LF-platinum 
members), which could be well above 40…. Could we consider some middle ground 
which caps the size of the TSC while still ensuring a broader representation of 
contributing companies? E.g.


•       Fully elected TSC (per Chris/Steven’s proposal)

•       Per company cap at 1 person

•       TSC size: 30

Thoughts?

Thanks, Frank

From: [email protected]<mailto:[email protected]> 
<[email protected]<mailto:[email protected]>> On 
Behalf Of Phil Robb
Sent: Mittwoch, 18. April 2018 01:25
To: [email protected]<mailto:[email protected]>

Subject: Re: [onap-tsc] TSC Composition Proposal

Hello ONAP TSC Members:

There has not been much discussion on this thread, so I assume that all 
relevant questions and comments have already been expressed regarding this 
topic of how best to populate the TSC and when to do it.  To that end, I will 
be calling for a vote on this topic during the TSC meeting on Thursday, April 
19th, 2018.  Please review the material below and provide comments or questions 
if you have any.  Also, please be prepared to vote on this topic, or have a 
delegate ready to vote in your stead on Thursday.  The format of the vote will 
be similar to the following:

First, we will vote on if we want to change the way we populate the TSC after 
Beijing or after Casablanca.  Remember that in order to change the date to 
after Casablanca (Nov. 2018), we will need a 2/3 super majority to modify the 
Charter with the new date.  So the first vote will be:

Shall the TSC modify the ONAP Charter to change the date in which the "Startup 
Period" ends (as defined in Section 2.b.i) to be November 16th, 2018? -1, 0, +1

If this vote passes, we are done for now.  If it does not pass with a 2/3 
approval, we will populate a new TSC shortly after Beijing is released.  To do 
so, we will vote on the following proposals:

Proposal #0
Abstain from voting on population method.

Proposal #1:
The TSC Accepts the "TSC Composition Proposal" presented by Chris Donley and 
Stephen Terrill during the TSC Meeting held on April 5th 2018.  The proposal in 
it's entirety is located here: 
https://wiki.onap.org/download/attachments/25439857/TSC%20Composition%20proposal%20v2.pdf?version=1&modificationDate=1522934062000&api=v2

Proposal #2:
The TSC Accepts the "TSC Composition Proposal" presented by Chris Donley and 
Stephen Terrill during the TSC Meeting held on April 5th 2018 with the 
following amendment:
​That i​
n addition to
​ the​
15 elected TSC members
​ in the original proposal​
, each end-user Platinum Member of LFN that ha
​s​
been a part of ONAP and/or LFN for less than 12 months from the time of the 
election,
​is​
allowed to appoint a representative to the TSC.

​Proposal #3:
The TSC Accepts the "TSC Composition Proposal" presented by Chris Donley and 
Stephen Terrill during the TSC Meeting held on April 5th 2018 with the 
following amendment:
​That in addition to the 15 elected TSC members in the original proposal, ​each 
end-user Platinum Member of LFN who does not otherwise have a representative 
(elected) on the TSC, is allowed to appoint a representative to the TSC.

Shall the TSC approve one of the above proposed methods of populating the TSC? 
0, 1, 2, 3

Please let me know if this sounds reasonable or if there is another way you 
would like to vote on these options or others for this topic.

Thanks,

Phil.

On Wed, Apr 11, 2018 at 4:59 PM, Phil Robb 
<[email protected]<mailto:[email protected]>> wrote:
Hello ONAP TSC:

I would like to keep the discussion moving regarding how and when we might 
choose to change the method of populating the TSC.

From the discussions thus far, I do not believe I heard much pushback on the 
population method suggested by Chris D. and Stephen T. at last week's TSC 
meeting.  In general, it called for a TSC where anyone can self-nominate to run 
for a TSC seat, and those that are allowed to vote must have demonstrated some 
form of previous participation in the project including code contributions, 
wiki contributions, subcommittee participation/leadership, etc.

If we were to do something like that, the one significant concern is end user 
representation, in particular since several of our end users have just joined 
the project recently and are ramping up their plans, and developer capabilities 
to directly participate in the project.  Mazin has called for 50% end-user 
participation in the TSC, others have just expressed the general concern that 
the end users should still be represented "well" in the new structure.

We have also heard from several of the TSC members that now is not the right 
time to change the makeup of the TSC and we should leave it the same at least 
until Casablanca (Nov. 2018).  A vote was held on this with a significant 
number of voters indicating that they would like the TSC to remain the same 
until Casablanca.  The vote did not pass however because such a change (which 
affects the ONAP Charter) must pass with a super-majority of 2/3s of the votes.

We have agreed to vote on this postponement again to see if it will pass the 
super-majority.  However, several TSC members have requested that such a vote 
not occur in a vacuum and instead be voted on along side other proposal(s) to 
populate the TSC differently than it is done today.

In the spirit of compromise, there are two ways in which we might ensure 
end-user representation on the TSC.  One of the ways was suggested by Chris and 
Stephen during their presentation last week, whereby:
   In addition to 15 elected TSC members, each end-user Platinum Member of LFN 
that had been a part of ONAP and/or LFN for less than 12 months from the time 
of the election, would be allowed to appoint a representative to the TSC.  If 
we were to put this in place, then Turk Telecom, Verizon, and Vodafone would be 
allowed to appoint a TSC representative while China Mobile, China Telecom, 
AT&T, Bell Canada, Orange, and Reliance Jio would not get an appointment 
because they have been members of ONAP/LFN for more than 12 months.  If we were 
to change this appointment time period from 12 months to 24 months, then all 
current LFN Platinum members who are end users would be allowed to appoint a 
representative for this year's TSC election, and Verizon, Vodafone, and Turk 
Telecom would be allowed to appoint a representative in the 2019 TSC election 
as well.

Another way we could ensure Operator participation in the TSC during our first 
2 years would be to say that we will elect a TSC of 13 or 15 members, then for 
all end-user Platinum members who do not otherwise have a representative 
(elected) on the TSC, they would be allowed to appoint a representative.  If we 
were to elect 13 and then have a potential addition of the 9 Platinum end 
users, that would make the TSC size 22.  However, I am confident that some 
community members from our heavily engaged end users will be elected to the TSC 
as part of the 13 count and as such, there will be no need for that company to 
appoint a representative.

Finally, I will reiterate that from my vantage point, there will be significant 
benefit from having our developers who are much closer to the code have TSC 
leadership positions.  We have a lot of room for improvement in how we work 
collectively and collaboratively to produce ONAP and empowering our leading 
developers to identify and overcome those issues will benefit the project 
substantially.

I would like to facilitate this [re]vote with potential TSC-population options 
at the TSC meeting next week (4/19)  If that sounds like a reasonable target to 
everyone, then please provide your comments and suggestions on the proposals 
I've listed above and/or propose another alternative method of populating the 
TSC.  Let's see if we can form up what will be the best options to vote on via 
email before the TSC meeting next week.

Thanks in advance for your feedback.

Best,

Phil.

On Thu, Apr 5, 2018 at 9:01 AM, Christopher Donley (Chris) 
<[email protected]<mailto:[email protected]>> wrote:
Alex,

That’s the intention (same with use case, etc.).  We want a way to measure it, 
and have it included under wiki.  People who make presentations are uploading 
their slides or adding wiki pages, which can be measured using Bitergia.

Chris

From: "Vul, Alex" <[email protected]<mailto:[email protected]>>
Date: Thursday, April 5, 2018 at 7:58 AM
To: Chris Donley 
<[email protected]<mailto:[email protected]>>, "Haiby, 
Ranny (Nokia - US/San Jose)" 
<[email protected]<mailto:[email protected]>>, 
"[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>

Subject: RE: TSC Composition Proposal

Chris,

Given that the TSC is a leadership body, I think that architectural subject 
matter expertise and industry experience should count for a lot as well…

Alex Vul
Intel Corporation

From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]] On Behalf Of Christopher Donley (Chris)
Sent: Thursday, April 5, 2018 6:23 AM
To: Haiby, Ranny (Nokia - US/San Jose) 
<[email protected]<mailto:[email protected]>>; 
[email protected]<mailto:[email protected]>
Subject: Re: [onap-tsc] TSC Composition Proposal

Ranny,

First, everyone currently on the TSC would be eligible to run under this 
structure.  Second, we are not just counting code contributions for determining 
voters.  We also propose counting a number of areas where operators have been 
active, such as presenting a use case to the use case or security subcommittee, 
presenting architecture proposals, or working on security in the security 
subcommittee (to name a few). These are captured in the contributions to the 
wiki bullet. The full list is:
-Code contributions/commits
-Code reviews
-Submitting Jira tickets (project management)
-Readthedocs (documentation)
-Subcommittee leadership
-Contributions to the wiki (files or wiki pages)

Also, since the window for measuring participation hasn’t closed, there is 
still time for other operators to get involved.

Chris
From: "Haiby, Ranny (Nokia - US/San Jose)" 
<[email protected]<mailto:[email protected]>>
Date: Wednesday, April 4, 2018 at 2:47 PM
To: Chris Donley 
<[email protected]<mailto:[email protected]>>, 
"[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Subject: RE: TSC Composition Proposal

Chris and Steve,

Thanks for the time and effort put into this proposal.

One thing I do not see in the proposal is explanation of the “Support operators 
with high interest in ONAP (regardless of development resources involved) to be 
active in the TSC” item from the first slide. Reading the next slides it seems 
that only active contributors will be able to vote, so there is no guarantee 
operators who did not contribute yet will get a seat at the TSC. Would you care 
to elaborate on this please?

Thanks,

Ranny.


From:[email protected]<mailto:[email protected]> 
<[email protected]<mailto:[email protected]>> On 
Behalf Of Christopher Donley (Chris)
Sent: Wednesday, April 4, 2018 1:58 PM
To: [email protected]<mailto:[email protected]>
Subject: [onap-tsc] TSC Composition Proposal

Dear TSC,

Steve Terrill and I have put together a proposal to transition the TSC to its 
“steady state” by June 30, as required in the ONAP Technical Charter.  We have 
tried to incorporate feedback from previous TSC discussions on this topic, and 
are proposing a structure that encourages diversity of companies and roles, 
while recognizing contributions in the community and interested operators who 
may have joined later, but who want to take an active role in ONAP.  See 
attached.

Under our proposal, the TSC will be composed of 15 elected representatives, 
with a cap of no more than two people per company.  Anyone who is interested 
may run for a seat on the TSC.  Voters in the election will consist of people 
who have been active in the community over the previous six month period, as 
demonstrated by one or more of {code contributions, code reviews, lira ticket 
submissions, readthedocs, wiki (pages or file uploads), or subcommittee 
leadership}.

We are interested in feedback on our proposal (including community feedback), 
and would like to discuss this on tomorrow’s TSC call.

Thanks,
Chris & Steve



_______________________________________________
ONAP-TSC mailing list
[email protected]<mailto:[email protected]>
https://lists.onap.org/mailman/listinfo/onap-tsc



--
Phil Robb
VP Operations - Networking & Orchestration, The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb



--
Phil Robb
VP Operations - Networking & Orchestration, The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb



--
Phil Robb
VP Operations - Networking & Orchestration, The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb
_______________________________________________
ONAP-TSC mailing list
[email protected]
https://lists.onap.org/mailman/listinfo/onap-tsc

Reply via email to