Topics

ONAP TSC Policies & Processes


Phil Robb <probb@...>
 

Hello ONAP TSC Members:

 

We need to discuss, decide, and document the policies and processes we will use for oversight and governance of the technical community.  This will span such mundane topics as “indentation style in the code” and “use of license/copyright headers per file” (one of my personal favorites J), to what constitutes an ONAP [sub]project, and what, if any, lifecycle should govern it.

 

Some of these policies & processes are needed more urgently than others as we begin.  We need to identify what things we need to document and prioritize our efforts on them.  This email is intended to kick off such a discussion.

 

First off, let’s clear up some terminology.  In several other Linux Foundation projects the TSC has a “Charter”.  This is not to be confused with the “ONAP Project Charter”.  The ONAP Project Charter deals with membership classes, Mission & Overall ONAP Project scope, the Governing Board Makeup, etc.  It touches upon the existence of the TSC, along with the Marketing Committee, but by-and-large it does not talk about how the TSC or the technical community are to operate.  That is left to the TSC, and the “TSC Charter” and/or “TSC Policy” document(s) spell that out.

 

As examples, here are the Charter and Policy documents from OpenDaylight.  Others from OPNFV, Open-O and other open source projects, please feel free to share documents from those projects as further examples:

 

https://www.opendaylight.org/tsc-charter

https://www.opendaylight.org/tsc-policy

 

Another document we may consider creating is to qualify and manage existing and new development activities in the project is the definition of a [sub]project lifecycle.  The reasons for setting up are varied and somewhat lengthy so we should have a discussion on what we want to accomplish before setting out to create this.  An example of a lifecycle from OpenDaylight is below.  Again, I encourage people to also respond to this thread with other examples of lifecycle documents as examples to review.

 

https://www.opendaylight.org/project-lifecycle-releases

 

Please chime in with your thoughts, suggestions, and/or questions  regarding these policy/process ideas and feel free to introduce others you think relevant on this thread.  


I look forward to your thoughts.

 

Best,

 

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


Ed Warnicke <hagbard@...>
 

Phil,

Thank you for raising this and for being clear about distinguishing the charter for the technical community from the 'ONAP Charter'.

I would recommend we look at the fd.io 'Technical Community Charter':

as a guide *structurally*.  It is structured into very short sections that can be linked directly that answer
common governance questions asked by members of the technical community.  This turns out to be massively
useful because there are questions that consistently arise like 




We may decide on different answers as a community than fd.io has... but I would maintain that the fd.io charter
effectively provides many of the *questions* we need to answer in a very very clear (and linkable) way.

Finally... I'd suggest we think of it as a 'Technical Community Charter' rather than a 'TSC Charter'... the TSC plays
an important role in the Technical Community, but there is more to the Technical Community than the TSC :)

Ed


On Sun, Mar 19, 2017 at 2:06 PM, Phil Robb via onap-tsc <onap-tsc@...> wrote:
_______________________________________________
onap-tsc mailing list
onap-tsc@...
https://lists.onap.org/mailman/listinfo/onap-tsc


---------- Forwarded message ----------
From: Phil Robb <probb@...>
To: onap-tsc@...
Cc: 
Bcc: 
Date: Sun, 19 Mar 2017 15:06:03 -0600
Subject: ONAP TSC Policies & Processes

Hello ONAP TSC Members:

 

We need to discuss, decide, and document the policies and processes we will use for oversight and governance of the technical community.  This will span such mundane topics as “indentation style in the code” and “use of license/copyright headers per file” (one of my personal favorites J), to what constitutes an ONAP [sub]project, and what, if any, lifecycle should govern it.

 

Some of these policies & processes are needed more urgently than others as we begin.  We need to identify what things we need to document and prioritize our efforts on them.  This email is intended to kick off such a discussion.

 

First off, let’s clear up some terminology.  In several other Linux Foundation projects the TSC has a “Charter”.  This is not to be confused with the “ONAP Project Charter”.  The ONAP Project Charter deals with membership classes, Mission & Overall ONAP Project scope, the Governing Board Makeup, etc.  It touches upon the existence of the TSC, along with the Marketing Committee, but by-and-large it does not talk about how the TSC or the technical community are to operate.  That is left to the TSC, and the “TSC Charter” and/or “TSC Policy” document(s) spell that out.

 

As examples, here are the Charter and Policy documents from OpenDaylight.  Others from OPNFV, Open-O and other open source projects, please feel free to share documents from those projects as further examples:

 

https://www.opendaylight.org/tsc-charter

https://www.opendaylight.org/tsc-policy

 

Another document we may consider creating is to qualify and manage existing and new development activities in the project is the definition of a [sub]project lifecycle.  The reasons for setting up are varied and somewhat lengthy so we should have a discussion on what we want to accomplish before setting out to create this.  An example of a lifecycle from OpenDaylight is below.  Again, I encourage people to also respond to this thread with other examples of lifecycle documents as examples to review.

 

https://www.opendaylight.org/project-lifecycle-releases

 

Please chime in with your thoughts, suggestions, and/or questions  regarding these policy/process ideas and feel free to introduce others you think relevant on this thread.  


I look forward to your thoughts.

 

Best,

 

Phil.    
--
Phil Robb
Executive Director, OpenDaylight Project
VP Operations - Networking & Orchestration, The Linux Foundation
Skype: Phil.Robb



Christopher Donley (Chris) <Christopher.Donley@...>
 

Ed, Phil, and ONAP TSC,

 

Thanks for starting the discussion.  I’d also like to point to OPEN-O’s TSC Charter: https://wiki.open-o.org/display/TSC/TSC+Charter.  It’s similar to the ODL and FD.IO charters (and OPNFV), but has a few differences that may be relevant here:

·        Terminology and role definitions are more aligned with the ONAP Charter (given the relationship between the OPEN-O Charter and ONAP Charter) (Section 8)

·        We define an Architecture Committee, with responsibilities for maintaining the long-term architecture and representing the organization with external standards bodies (Section 9).  Given the need to merge two existing projects and to develop a common long-term vision, I strongly recommend we consider a similar Architecture Committee in ONAP.

·        We have a TSC Vice-Chair to help lead the project, run meetings when the Chair is away, and represent the organization at some speaking engagements (Section 4).  Given the size of this project, I recommend creating this role, as well.

·        In OPEN-O, we combined the Vice Chair and the Architecture Chair.  Since ONAP has a larger TSC, I recommend separating the roles, so the leadership team would be the TSC Chair, Vice Chair, and Architecture Chair (with the option for future subcommittees as needed).

 

Our policy document is here: https://wiki.open-o.org/display/TSC/TSC+Policies.  Again, very similar to ODL/OPNFV.

 

Ed, you raised the question of Committer promotion.  Our policy is here: https://wiki.open-o.org/display/TSC/Committer+Promotion+Process.  It’s aligned with the one in the FD.IO charter, but goes into a bit more detail to provide transparency, checks-and-balances, and a paper trail to help build trust in the community.

 

Chris

 

From: Ed Warnicke [mailto:hagbard@...]
Sent: Sunday, March 19, 2017 3:31 PM
To: Phil Robb
Cc: onap-tsc@...
Subject: Re: [onap-tsc] ONAP TSC Policies & Processes

 

Phil,

 

Thank you for raising this and for being clear about distinguishing the charter for the technical community from the 'ONAP Charter'.

 

I would recommend we look at the fd.io 'Technical Community Charter':

 

as a guide *structurally*.  It is structured into very short sections that can be linked directly that answer

common governance questions asked by members of the technical community.  This turns out to be massively

useful because there are questions that consistently arise like 

 

 

 

 

We may decide on different answers as a community than fd.io has... but I would maintain that the fd.io charter

effectively provides many of the *questions* we need to answer in a very very clear (and linkable) way.

 

Finally... I'd suggest we think of it as a 'Technical Community Charter' rather than a 'TSC Charter'... the TSC plays

an important role in the Technical Community, but there is more to the Technical Community than the TSC :)

 

Ed

 

 

On Sun, Mar 19, 2017 at 2:06 PM, Phil Robb via onap-tsc <onap-tsc@...> wrote:

_______________________________________________
onap-tsc mailing list
onap-tsc@...
https://lists.onap.org/mailman/listinfo/onap-tsc


---------- Forwarded message ----------
From: Phil Robb <probb@...>
To: onap-tsc@...
Cc: 
Bcc: 
Date: Sun, 19 Mar 2017 15:06:03 -0600
Subject: ONAP TSC Policies & Processes

Hello ONAP TSC Members:

 

We need to discuss, decide, and document the policies and processes we will use for oversight and governance of the technical community.  This will span such mundane topics as “indentation style in the code” and “use of license/copyright headers per file” (one of my personal favorites J), to what constitutes an ONAP [sub]project, and what, if any, lifecycle should govern it.

 

Some of these policies & processes are needed more urgently than others as we begin.  We need to identify what things we need to document and prioritize our efforts on them.  This email is intended to kick off such a discussion.

 

First off, let’s clear up some terminology.  In several other Linux Foundation projects the TSC has a “Charter”.  This is not to be confused with the “ONAP Project Charter”.  The ONAP Project Charter deals with membership classes, Mission & Overall ONAP Project scope, the Governing Board Makeup, etc.  It touches upon the existence of the TSC, along with the Marketing Committee, but by-and-large it does not talk about how the TSC or the technical community are to operate.  That is left to the TSC, and the “TSC Charter” and/or “TSC Policy” document(s) spell that out.

 

As examples, here are the Charter and Policy documents from OpenDaylight.  Others from OPNFV, Open-O and other open source projects, please feel free to share documents from those projects as further examples:

 

https://www.opendaylight.org/tsc-charter

https://www.opendaylight.org/tsc-policy

 

Another document we may consider creating is to qualify and manage existing and new development activities in the project is the definition of a [sub]project lifecycle.  The reasons for setting up are varied and somewhat lengthy so we should have a discussion on what we want to accomplish before setting out to create this.  An example of a lifecycle from OpenDaylight is below.  Again, I encourage people to also respond to this thread with other examples of lifecycle documents as examples to review.

 

https://www.opendaylight.org/project-lifecycle-releases

 

Please chime in with your thoughts, suggestions, and/or questions  regarding these policy/process ideas and feel free to introduce others you think relevant on this thread.  

 

I look forward to your thoughts.

 

Best,

 

Phil.    

--

Phil Robb

Executive Director, OpenDaylight Project

VP Operations - Networking & Orchestration, The Linux Foundation

Skype: Phil.Robb

 

 


Ed Warnicke <hagbard@...>
 

Chris,
       It looks like, being maintained in the wiki, anyone can edit the OpenO TSC Charter... is that correct?  It would appear that anyone with an LF account (and one can create those from any email account) may log in and edit the TSC Charter for OpenO.
       Typically in my experience, TSC Charters are kept on the website of the project, not on the wiki, for precisely this reason.

       I'd suggest it would be productive to separate the *structure* of the Technical Community Charter (I favor a highly granular, highly linkable, non-world-editable structure) from the *answers* to particular questions raised within that structure.  It allows one to figure out what questions have to be answered and to look at the pros and cons of those answers.  For example, in comparing the open-o charter with the fd.io charter... I see more differences than you called out, in part because I can walk through the fd.io charter clearly identified item by clearly identified item and go looking for them in the OpenO charter for comparison.

       Would it perhaps make sense for you to transliterate the *answers* from the OpenO Charter into the kind of clear, granular, linkable format of the fd.io charter to ease discussion? 

Ed

On Tue, Mar 21, 2017 at 1:01 PM, Christopher Donley (Chris) <Christopher.Donley@...> wrote:

Ed, Phil, and ONAP TSC,

 

Thanks for starting the discussion.  I’d also like to point to OPEN-O’s TSC Charter: https://wiki.open-o.org/display/TSC/TSC+Charter.  It’s similar to the ODL and FD.IO charters (and OPNFV), but has a few differences that may be relevant here:

·        Terminology and role definitions are more aligned with the ONAP Charter (given the relationship between the OPEN-O Charter and ONAP Charter) (Section 8)

·        We define an Architecture Committee, with responsibilities for maintaining the long-term architecture and representing the organization with external standards bodies (Section 9).  Given the need to merge two existing projects and to develop a common long-term vision, I strongly recommend we consider a similar Architecture Committee in ONAP.

·        We have a TSC Vice-Chair to help lead the project, run meetings when the Chair is away, and represent the organization at some speaking engagements (Section 4).  Given the size of this project, I recommend creating this role, as well.

·        In OPEN-O, we combined the Vice Chair and the Architecture Chair.  Since ONAP has a larger TSC, I recommend separating the roles, so the leadership team would be the TSC Chair, Vice Chair, and Architecture Chair (with the option for future subcommittees as needed).

 

Our policy document is here: https://wiki.open-o.org/display/TSC/TSC+Policies.  Again, very similar to ODL/OPNFV.

 

Ed, you raised the question of Committer promotion.  Our policy is here: https://wiki.open-o.org/display/TSC/Committer+Promotion+Process.  It’s aligned with the one in the FD.IO charter, but goes into a bit more detail to provide transparency, checks-and-balances, and a paper trail to help build trust in the community.

 

Chris

 

From: Ed Warnicke [mailto:hagbard@...]
Sent: Sunday, March 19, 2017 3:31 PM
To: Phil Robb
Cc: onap-tsc@...
Subject: Re: [onap-tsc] ONAP TSC Policies & Processes

 

Phil,

 

Thank you for raising this and for being clear about distinguishing the charter for the technical community from the 'ONAP Charter'.

 

I would recommend we look at the fd.io 'Technical Community Charter':

 

as a guide *structurally*.  It is structured into very short sections that can be linked directly that answer

common governance questions asked by members of the technical community.  This turns out to be massively

useful because there are questions that consistently arise like 

 

 

 

 

We may decide on different answers as a community than fd.io has... but I would maintain that the fd.io charter

effectively provides many of the *questions* we need to answer in a very very clear (and linkable) way.

 

Finally... I'd suggest we think of it as a 'Technical Community Charter' rather than a 'TSC Charter'... the TSC plays

an important role in the Technical Community, but there is more to the Technical Community than the TSC :)

 

Ed

 

 

On Sun, Mar 19, 2017 at 2:06 PM, Phil Robb via onap-tsc <onap-tsc@...> wrote:

_______________________________________________
onap-tsc mailing list
onap-tsc@...
https://lists.onap.org/mailman/listinfo/onap-tsc


---------- Forwarded message ----------
From: Phil Robb <probb@...>
To: onap-tsc@...
Cc: 
Bcc: 
Date: Sun, 19 Mar 2017 15:06:03 -0600
Subject: ONAP TSC Policies & Processes

Hello ONAP TSC Members:

 

We need to discuss, decide, and document the policies and processes we will use for oversight and governance of the technical community.  This will span such mundane topics as “indentation style in the code” and “use of license/copyright headers per file” (one of my personal favorites J), to what constitutes an ONAP [sub]project, and what, if any, lifecycle should govern it.

 

Some of these policies & processes are needed more urgently than others as we begin.  We need to identify what things we need to document and prioritize our efforts on them.  This email is intended to kick off such a discussion.

 

First off, let’s clear up some terminology.  In several other Linux Foundation projects the TSC has a “Charter”.  This is not to be confused with the “ONAP Project Charter”.  The ONAP Project Charter deals with membership classes, Mission & Overall ONAP Project scope, the Governing Board Makeup, etc.  It touches upon the existence of the TSC, along with the Marketing Committee, but by-and-large it does not talk about how the TSC or the technical community are to operate.  That is left to the TSC, and the “TSC Charter” and/or “TSC Policy” document(s) spell that out.

 

As examples, here are the Charter and Policy documents from OpenDaylight.  Others from OPNFV, Open-O and other open source projects, please feel free to share documents from those projects as further examples:

 

https://www.opendaylight.org/tsc-charter

https://www.opendaylight.org/tsc-policy

 

Another document we may consider creating is to qualify and manage existing and new development activities in the project is the definition of a [sub]project lifecycle.  The reasons for setting up are varied and somewhat lengthy so we should have a discussion on what we want to accomplish before setting out to create this.  An example of a lifecycle from OpenDaylight is below.  Again, I encourage people to also respond to this thread with other examples of lifecycle documents as examples to review.

 

https://www.opendaylight.org/project-lifecycle-releases

 

Please chime in with your thoughts, suggestions, and/or questions  regarding these policy/process ideas and feel free to introduce others you think relevant on this thread.  

 

I look forward to your thoughts.

 

Best,

 

Phil.    

--

Phil Robb

Executive Director, OpenDaylight Project

VP Operations - Networking & Orchestration, The Linux Foundation

Skype: Phil.Robb

 

 



Stephen Terrill
 

Hi All,

 

Thanks for the input, this email raises a few interesting questions that we need to deal with and reading it I had a query regarding the suggestion to form an architecture project.  The ONAP project charter points to the TSC for coordinating the technical direction including the architecture, which I interpret as both guidance to the projects and a basis for broader communication.  This could be achieved by delegation to a project as suggested, though it raises the question of whether we would practically end up all meeting in a different constellation or leaving the TSC meetings without a deep view of the deep architecture principles when it comes to guiding the project scopes.  What has been the experience on this?

 

BR,

 

Steve

 

From: onap-tsc-bounces@... [mailto:onap-tsc-bounces@...] On Behalf Of Christopher Donley (Chris)
Sent: 21 March 2017 21:01
To: Ed Warnicke <hagbard@...>; Phil Robb <probb@...>
Cc: onap-tsc@...
Subject: Re: [onap-tsc] ONAP TSC Policies & Processes

 

Ed, Phil, and ONAP TSC,

 

Thanks for starting the discussion.  I’d also like to point to OPEN-O’s TSC Charter: https://wiki.open-o.org/display/TSC/TSC+Charter.  It’s similar to the ODL and FD.IO charters (and OPNFV), but has a few differences that may be relevant here:

·         Terminology and role definitions are more aligned with the ONAP Charter (given the relationship between the OPEN-O Charter and ONAP Charter) (Section 8)

·         We define an Architecture Committee, with responsibilities for maintaining the long-term architecture and representing the organization with external standards bodies (Section 9).  Given the need to merge two existing projects and to develop a common long-term vision, I strongly recommend we consider a similar Architecture Committee in ONAP.

·         We have a TSC Vice-Chair to help lead the project, run meetings when the Chair is away, and represent the organization at some speaking engagements (Section 4).  Given the size of this project, I recommend creating this role, as well.

·         In OPEN-O, we combined the Vice Chair and the Architecture Chair.  Since ONAP has a larger TSC, I recommend separating the roles, so the leadership team would be the TSC Chair, Vice Chair, and Architecture Chair (with the option for future subcommittees as needed).

 

Our policy document is here: https://wiki.open-o.org/display/TSC/TSC+Policies.  Again, very similar to ODL/OPNFV.

 

Ed, you raised the question of Committer promotion.  Our policy is here: https://wiki.open-o.org/display/TSC/Committer+Promotion+Process.  It’s aligned with the one in the FD.IO charter, but goes into a bit more detail to provide transparency, checks-and-balances, and a paper trail to help build trust in the community.

 

Chris

 

From: Ed Warnicke [mailto:hagbard@...]
Sent: Sunday, March 19, 2017 3:31 PM
To: Phil Robb
Cc: onap-tsc@...
Subject: Re: [onap-tsc] ONAP TSC Policies & Processes

 

Phil,

 

Thank you for raising this and for being clear about distinguishing the charter for the technical community from the 'ONAP Charter'.

 

I would recommend we look at the fd.io 'Technical Community Charter':

 

as a guide *structurally*.  It is structured into very short sections that can be linked directly that answer

common governance questions asked by members of the technical community.  This turns out to be massively

useful because there are questions that consistently arise like 

 

 

 

 

We may decide on different answers as a community than fd.io has... but I would maintain that the fd.io charter

effectively provides many of the *questions* we need to answer in a very very clear (and linkable) way.

 

Finally... I'd suggest we think of it as a 'Technical Community Charter' rather than a 'TSC Charter'... the TSC plays

an important role in the Technical Community, but there is more to the Technical Community than the TSC :)

 

Ed

 

 

On Sun, Mar 19, 2017 at 2:06 PM, Phil Robb via onap-tsc <onap-tsc@...> wrote:

_______________________________________________
onap-tsc mailing list
onap-tsc@...
https://lists.onap.org/mailman/listinfo/onap-tsc


---------- Forwarded message ----------
From: Phil Robb <probb@...>
To: onap-tsc@...
Cc: 
Bcc: 
Date: Sun, 19 Mar 2017 15:06:03 -0600
Subject: ONAP TSC Policies & Processes

Hello ONAP TSC Members:

 

We need to discuss, decide, and document the policies and processes we will use for oversight and governance of the technical community.  This will span such mundane topics as “indentation style in the code” and “use of license/copyright headers per file” (one of my personal favorites J), to what constitutes an ONAP [sub]project, and what, if any, lifecycle should govern it.

 

Some of these policies & processes are needed more urgently than others as we begin.  We need to identify what things we need to document and prioritize our efforts on them.  This email is intended to kick off such a discussion.

 

First off, let’s clear up some terminology.  In several other Linux Foundation projects the TSC has a “Charter”.  This is not to be confused with the “ONAP Project Charter”.  The ONAP Project Charter deals with membership classes, Mission & Overall ONAP Project scope, the Governing Board Makeup, etc.  It touches upon the existence of the TSC, along with the Marketing Committee, but by-and-large it does not talk about how the TSC or the technical community are to operate.  That is left to the TSC, and the “TSC Charter” and/or “TSC Policy” document(s) spell that out.

 

As examples, here are the Charter and Policy documents from OpenDaylight.  Others from OPNFV, Open-O and other open source projects, please feel free to share documents from those projects as further examples:

 

https://www.opendaylight.org/tsc-charter

https://www.opendaylight.org/tsc-policy

 

Another document we may consider creating is to qualify and manage existing and new development activities in the project is the definition of a [sub]project lifecycle.  The reasons for setting up are varied and somewhat lengthy so we should have a discussion on what we want to accomplish before setting out to create this.  An example of a lifecycle from OpenDaylight is below.  Again, I encourage people to also respond to this thread with other examples of lifecycle documents as examples to review.

 

https://www.opendaylight.org/project-lifecycle-releases

 

Please chime in with your thoughts, suggestions, and/or questions  regarding these policy/process ideas and feel free to introduce others you think relevant on this thread.  

 

I look forward to your thoughts.

 

Best,

 

Phil.    

--

Phil Robb

Executive Director, OpenDaylight Project

VP Operations - Networking & Orchestration, The Linux Foundation

Skype: Phil.Robb