Date   

Bootstrapping the CDF TOC

Chris Aniszczyk
 

Hey all!

The role of the CDF Technical Oversight Committee (TOC) is to facilitate communication and collaboration among the Technical Projects. The TOC will be responsible for:

- coordinating collaboration among Technical Projects, including development of an overall technical vision for the community;
- making recommendations to the Budget Committee of resource priorities for Technical Projects;
- electing annually a chairperson to preside over meetings, set the agenda for meetings, ensure meeting minutes are taken and who will also serve on the Governing Board as the TOC’s representative (the "TOC Representative");
- creating, maintaining and amending project lifecycle procedures and processes, subject to the approval of the Governing Board; and
- such other matters related to the technical role of the TOC as may be communicated to the TOC by the Governing Board.

The initial TOC members are:
Kohsuke Kawaguchi (Jenkins) [chair]
James Strachan (Jenkins-X)
Dan Lorenc (Tekton)
Andy Glover (Spinnaker)

The goal is to schedule the first meeting in the next few weeks:
https://github.com/cdfoundation/toc/issues/1

--
Chris Aniszczyk (@cra) | +1-512-961-6719


Re: Bootstrapping the CDF TOC

R. Tyler Croy
 

Considering the initial members are between PDT and GMT, I'm sure scheduling
this will be fun :)

--
GitHub: https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2


Re: Bootstrapping the CDF TOC

dlorenc@...
 

I sent a doodle here: https://doodle.com/poll/7kfkgsheg39rtmzn

These are open meetings so everyone is free/encouraged to vote but we'll prioritize availability of the TOC members.

Dan Lorenc

On Thu, Mar 14, 2019, 7:54 AM R. Tyler Croy <rtyler@...> wrote:
Considering the initial members are between PDT and GMT, I'm sure scheduling
this will be fun :)

--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

On Thu, Mar 14, 2019, 7:54 AM R. Tyler Croy <rtyler@...> wrote:
Considering the initial members are between PDT and GMT, I'm sure scheduling
this will be fun :)

--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2


Re: Bootstrapping the CDF TOC

Kohsuke Kawaguchi
 

Thanks! I've added my availability.


On Thu, Mar 14, 2019 at 10:34 AM Dan Lorenc <dlorenc@...> wrote:
I sent a doodle here: https://doodle.com/poll/7kfkgsheg39rtmzn

These are open meetings so everyone is free/encouraged to vote but we'll prioritize availability of the TOC members.

Dan Lorenc

On Thu, Mar 14, 2019, 7:54 AM R. Tyler Croy <rtyler@...> wrote:
Considering the initial members are between PDT and GMT, I'm sure scheduling
this will be fun :)

--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

On Thu, Mar 14, 2019, 7:54 AM R. Tyler Croy <rtyler@...> wrote:
Considering the initial members are between PDT and GMT, I'm sure scheduling
this will be fun :)

--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2


--
Kohsuke Kawaguchi


Thoughts from OSLS

Kohsuke Kawaguchi
 

I'm back to work from the hectic week that is OSLS. As everyone said it before, the launch went really well. Here are some thoughts that I'm starting to form that's relevant to what TOC might want to take on.
  • Several people who are behind some of the "CD" projects came up to me and showed their interest to bring their projects under the CDF. All of them are overlapping to some degree with some of the 4 projects that we already have. That by itself isn't a bad thing, but it did make me wonder how we'd approach them. I feel like the industry and vendors are watching what color this foundation will take in the next few months, and if we build a super market with 4 different kind of apples without any oranges, I don't know if that's the message we want to send.

  • But another way to look at this is that the reasons those 4 different apples exist (in various different stages of maturity) is that devops teams needed to scratch their itches, and I'd think a part of the reason is that they weren't aware, or didn't feel comfortable joining other projects. I think we can solve those problems here, and that might encourage more collaboration and result in more consolidation, which I think is a better outcome.

  • From there, my mind went to "how do we solve that?" There are a lot of things we can do for sure, and some of those are already mentioned by people when we met. For example, putting people behind those projects together and sharing what problems they are trying to solve to each other would be a great step. Another one I thought is to set a bar or provide help to participating projects about transparency to the governance and/or the vision, which help other organized potential contributors to see if it's aligned with what they need, or they need to build something else. That kind of visibility feels like a sign of maturity anyway.

  • Relevant to above visibility/transparency is that people wanted understand where the collaboration with Tekton and Jenkins are happening and what that means.

  • From the "4 different kind of apples without any oranges" thought, another place my head went is that it'd be great to recruit projects more proactively (or at least build relations with.) I think that requires drawing a mental map of the super market, that is the CD space.

  • Finally, completely tangentially, I always thought there are lots of rooms for more API/interop focused small projects. I'm a big fan of Grafeas. Another example is the machine readable input/output to test frameworks --- there's the test report format that JUnit started but now used everywhere from nosetest to rspec, and that could really use a name and a schema. Then I'd love to see a mechanism that allows CI/CD tool to specify a subset of tests to run and its order, for more frictionless parallelism and efficiency. It's all fairly trivial things but it takes putting the right group of people in the room to make happen!!

As you can see, random unorganized thoughts here. Love to hear other people's own thoughts.

--
Kohsuke Kawaguchi


Re: Thoughts from OSLS

Dan Lorenc <dlorenc@...>
 

Thanks for sending this! Some thoughts inline, and I look forward to discussing more in person.

On Fri, Mar 15, 2019 at 12:51 PM Kohsuke Kawaguchi <kk@...> wrote:
I'm back to work from the hectic week that is OSLS. As everyone said it before, the launch went really well. Here are some thoughts that I'm starting to form that's relevant to what TOC might want to take on.
  • Several people who are behind some of the "CD" projects came up to me and showed their interest to bring their projects under the CDF. All of them are overlapping to some degree with some of the 4 projects that we already have. That by itself isn't a bad thing, but it did make me wonder how we'd approach them. I feel like the industry and vendors are watching what color this foundation will take in the next few months, and if we build a super market with 4 different kind of apples without any oranges, I don't know if that's the message we want to send.
This came up with me as well. I think we should try to understand the motivations these companies have for placing these projects in a foundation and make sure we have places/levels in place for the broad range of projects/motivations. For example, some companies seem to be motivated by:
  • getting a broader contributor base
  • solving a large industry problem that can't be done in isolation
  • marketing, other project support
  • credibility of being in a foundation
We should prioritize establishing a set of areas where the appropriate type of collaboration can take place for each project. CNCF has sandbox, incubating, graduation, etc. to help. Other foundations have other types of "levels".

A sign of a healthy ecosystem would be projects both inside and outside the foundation interoperating and building on each other. We should also work to dispel any notions that projects must be in the CDF to interoperate with the CDF projects. A CDF landscape would be a big help here. I think Chris said these are pretty easy to setup.

  • But another way to look at this is that the reasons those 4 different apples exist (in various different stages of maturity) is that devops teams needed to scratch their itches, and I'd think a part of the reason is that they weren't aware, or didn't feel comfortable joining other projects. I think we can solve those problems here, and that might encourage more collaboration and result in more consolidation, which I think is a better outcome.

Definitely, vendor-neutral owned projects can be much more welcoming to others. 
  • From there, my mind went to "how do we solve that?" There are a lot of things we can do for sure, and some of those are already mentioned by people when we met. For example, putting people behind those projects together and sharing what problems they are trying to solve to each other would be a great step. Another one I thought is to set a bar or provide help to participating projects about transparency to the governance and/or the vision, which help other organized potential contributors to see if it's aligned with what they need, or they need to build something else. That kind of visibility feels like a sign of maturity anyway.

  • Relevant to above visibility/transparency is that people wanted understand where the collaboration with Tekton and Jenkins are happening and what that means.
 Right! I look forward to having these conversations in central, public discussions hosted by the CDF going forward. They've mostly been informal adhoc meetings so far.
  •  


  • From the "4 different kind of apples without any oranges" thought, another place my head went is that it'd be great to recruit projects more proactively (or at least build relations with.) I think that requires drawing a mental map of the super market, that is the CD space.

  • Finally, completely tangentially, I always thought there are lots of rooms for more API/interop focused small projects. I'm a big fan of Grafeas. Another example is the machine readable input/output to test frameworks --- there's the test report format that JUnit started but now used everywhere from nosetest to rspec, and that could really use a name and a schema.
A few other CDF members expressed interest in Grafeas as well. I'll follow up on this in the next couple of weeks. I think there's definitely a need for a CD-focused, secure metadata standard for interop. 
  • Then I'd love to see a mechanism that allows CI/CD tool to specify a subset of tests to run and its order, for more frictionless parallelism and efficiency. It's all fairly trivial things but it takes putting the right group of people in the room to make happen!!

As you can see, random unorganized thoughts here. Love to hear other people's own thoughts.

--
Kohsuke Kawaguchi


Re: Thoughts from OSLS

Chris Aniszczyk
 

I'm happy to see this discussion going on and my advice would be to focus on two things:

1) establish a set of principles/values that the CDF TOC can agree on as clarity helps with consensus building, see this as an example: https://github.com/cncf/toc/blob/master/PRINCIPLES.md or https://github.com/cncf/foundation/blob/master/charter.md#3-values

There are good ideas to pull from CNCF and other communities out there, with an opportunity to put your own spin on it.

2) establish a project acceptance/lifecycle process:


I'd start there before worrying about landscapes or new projects, establishing a set of values and process the TOC and the community agrees on is critical. While this discussion is happening, the rest of the TOC will be filled out by the GB over the coming couple months (after the GB meets for the first time next month).

Those are my two cents :)

On Fri, Mar 15, 2019 at 11:01 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks for sending this! Some thoughts inline, and I look forward to discussing more in person.

On Fri, Mar 15, 2019 at 12:51 PM Kohsuke Kawaguchi <kk@...> wrote:
I'm back to work from the hectic week that is OSLS. As everyone said it before, the launch went really well. Here are some thoughts that I'm starting to form that's relevant to what TOC might want to take on.
  • Several people who are behind some of the "CD" projects came up to me and showed their interest to bring their projects under the CDF. All of them are overlapping to some degree with some of the 4 projects that we already have. That by itself isn't a bad thing, but it did make me wonder how we'd approach them. I feel like the industry and vendors are watching what color this foundation will take in the next few months, and if we build a super market with 4 different kind of apples without any oranges, I don't know if that's the message we want to send.
This came up with me as well. I think we should try to understand the motivations these companies have for placing these projects in a foundation and make sure we have places/levels in place for the broad range of projects/motivations. For example, some companies seem to be motivated by:
  • getting a broader contributor base
  • solving a large industry problem that can't be done in isolation
  • marketing, other project support
  • credibility of being in a foundation
We should prioritize establishing a set of areas where the appropriate type of collaboration can take place for each project. CNCF has sandbox, incubating, graduation, etc. to help. Other foundations have other types of "levels".

A sign of a healthy ecosystem would be projects both inside and outside the foundation interoperating and building on each other. We should also work to dispel any notions that projects must be in the CDF to interoperate with the CDF projects. A CDF landscape would be a big help here. I think Chris said these are pretty easy to setup.

  • But another way to look at this is that the reasons those 4 different apples exist (in various different stages of maturity) is that devops teams needed to scratch their itches, and I'd think a part of the reason is that they weren't aware, or didn't feel comfortable joining other projects. I think we can solve those problems here, and that might encourage more collaboration and result in more consolidation, which I think is a better outcome.

Definitely, vendor-neutral owned projects can be much more welcoming to others. 
  • From there, my mind went to "how do we solve that?" There are a lot of things we can do for sure, and some of those are already mentioned by people when we met. For example, putting people behind those projects together and sharing what problems they are trying to solve to each other would be a great step. Another one I thought is to set a bar or provide help to participating projects about transparency to the governance and/or the vision, which help other organized potential contributors to see if it's aligned with what they need, or they need to build something else. That kind of visibility feels like a sign of maturity anyway.

  • Relevant to above visibility/transparency is that people wanted understand where the collaboration with Tekton and Jenkins are happening and what that means.
 Right! I look forward to having these conversations in central, public discussions hosted by the CDF going forward. They've mostly been informal adhoc meetings so far.
  •  


  • From the "4 different kind of apples without any oranges" thought, another place my head went is that it'd be great to recruit projects more proactively (or at least build relations with.) I think that requires drawing a mental map of the super market, that is the CD space.

  • Finally, completely tangentially, I always thought there are lots of rooms for more API/interop focused small projects. I'm a big fan of Grafeas. Another example is the machine readable input/output to test frameworks --- there's the test report format that JUnit started but now used everywhere from nosetest to rspec, and that could really use a name and a schema.
A few other CDF members expressed interest in Grafeas as well. I'll follow up on this in the next couple of weeks. I think there's definitely a need for a CD-focused, secure metadata standard for interop. 
  • Then I'd love to see a mechanism that allows CI/CD tool to specify a subset of tests to run and its order, for more frictionless parallelism and efficiency. It's all fairly trivial things but it takes putting the right group of people in the room to make happen!!

As you can see, random unorganized thoughts here. Love to hear other people's own thoughts.

--
Kohsuke Kawaguchi



--
Chris Aniszczyk (@cra) | +1-512-961-6719


Re: Thoughts from OSLS

Dan Lorenc <dlorenc@...>
 

Thanks Chris! I threw some initial ideas on principles/values, etc. down here. I started with some of the format from the CNCF documents.


On Fri, Mar 15, 2019 at 4:41 PM Chris Aniszczyk <caniszczyk@...> wrote:
I'm happy to see this discussion going on and my advice would be to focus on two things:

1) establish a set of principles/values that the CDF TOC can agree on as clarity helps with consensus building, see this as an example: https://github.com/cncf/toc/blob/master/PRINCIPLES.md or https://github.com/cncf/foundation/blob/master/charter.md#3-values

There are good ideas to pull from CNCF and other communities out there, with an opportunity to put your own spin on it.

2) establish a project acceptance/lifecycle process:


I'd start there before worrying about landscapes or new projects, establishing a set of values and process the TOC and the community agrees on is critical. While this discussion is happening, the rest of the TOC will be filled out by the GB over the coming couple months (after the GB meets for the first time next month).

Those are my two cents :)

On Fri, Mar 15, 2019 at 11:01 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks for sending this! Some thoughts inline, and I look forward to discussing more in person.

On Fri, Mar 15, 2019 at 12:51 PM Kohsuke Kawaguchi <kk@...> wrote:
I'm back to work from the hectic week that is OSLS. As everyone said it before, the launch went really well. Here are some thoughts that I'm starting to form that's relevant to what TOC might want to take on.
  • Several people who are behind some of the "CD" projects came up to me and showed their interest to bring their projects under the CDF. All of them are overlapping to some degree with some of the 4 projects that we already have. That by itself isn't a bad thing, but it did make me wonder how we'd approach them. I feel like the industry and vendors are watching what color this foundation will take in the next few months, and if we build a super market with 4 different kind of apples without any oranges, I don't know if that's the message we want to send.
This came up with me as well. I think we should try to understand the motivations these companies have for placing these projects in a foundation and make sure we have places/levels in place for the broad range of projects/motivations. For example, some companies seem to be motivated by:
  • getting a broader contributor base
  • solving a large industry problem that can't be done in isolation
  • marketing, other project support
  • credibility of being in a foundation
We should prioritize establishing a set of areas where the appropriate type of collaboration can take place for each project. CNCF has sandbox, incubating, graduation, etc. to help. Other foundations have other types of "levels".

A sign of a healthy ecosystem would be projects both inside and outside the foundation interoperating and building on each other. We should also work to dispel any notions that projects must be in the CDF to interoperate with the CDF projects. A CDF landscape would be a big help here. I think Chris said these are pretty easy to setup.

  • But another way to look at this is that the reasons those 4 different apples exist (in various different stages of maturity) is that devops teams needed to scratch their itches, and I'd think a part of the reason is that they weren't aware, or didn't feel comfortable joining other projects. I think we can solve those problems here, and that might encourage more collaboration and result in more consolidation, which I think is a better outcome.

Definitely, vendor-neutral owned projects can be much more welcoming to others. 
  • From there, my mind went to "how do we solve that?" There are a lot of things we can do for sure, and some of those are already mentioned by people when we met. For example, putting people behind those projects together and sharing what problems they are trying to solve to each other would be a great step. Another one I thought is to set a bar or provide help to participating projects about transparency to the governance and/or the vision, which help other organized potential contributors to see if it's aligned with what they need, or they need to build something else. That kind of visibility feels like a sign of maturity anyway.

  • Relevant to above visibility/transparency is that people wanted understand where the collaboration with Tekton and Jenkins are happening and what that means.
 Right! I look forward to having these conversations in central, public discussions hosted by the CDF going forward. They've mostly been informal adhoc meetings so far.
  •  


  • From the "4 different kind of apples without any oranges" thought, another place my head went is that it'd be great to recruit projects more proactively (or at least build relations with.) I think that requires drawing a mental map of the super market, that is the CD space.

  • Finally, completely tangentially, I always thought there are lots of rooms for more API/interop focused small projects. I'm a big fan of Grafeas. Another example is the machine readable input/output to test frameworks --- there's the test report format that JUnit started but now used everywhere from nosetest to rspec, and that could really use a name and a schema.
A few other CDF members expressed interest in Grafeas as well. I'll follow up on this in the next couple of weeks. I think there's definitely a need for a CD-focused, secure metadata standard for interop. 
  • Then I'd love to see a mechanism that allows CI/CD tool to specify a subset of tests to run and its order, for more frictionless parallelism and efficiency. It's all fairly trivial things but it takes putting the right group of people in the room to make happen!!

As you can see, random unorganized thoughts here. Love to hear other people's own thoughts.

--
Kohsuke Kawaguchi



--
Chris Aniszczyk (@cra) | +1-512-961-6719


Re: Thoughts from OSLS

Andy Glover
 

This is great, thanks for putting this together, Dan! 

-Andy


On Thu, Mar 21, 2019 at 7:30 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks Chris! I threw some initial ideas on principles/values, etc. down here. I started with some of the format from the CNCF documents.

On Fri, Mar 15, 2019 at 4:41 PM Chris Aniszczyk <caniszczyk@...> wrote:
I'm happy to see this discussion going on and my advice would be to focus on two things:

1) establish a set of principles/values that the CDF TOC can agree on as clarity helps with consensus building, see this as an example: https://github.com/cncf/toc/blob/master/PRINCIPLES.md or https://github.com/cncf/foundation/blob/master/charter.md#3-values

There are good ideas to pull from CNCF and other communities out there, with an opportunity to put your own spin on it.

2) establish a project acceptance/lifecycle process:


I'd start there before worrying about landscapes or new projects, establishing a set of values and process the TOC and the community agrees on is critical. While this discussion is happening, the rest of the TOC will be filled out by the GB over the coming couple months (after the GB meets for the first time next month).

Those are my two cents :)

On Fri, Mar 15, 2019 at 11:01 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks for sending this! Some thoughts inline, and I look forward to discussing more in person.

On Fri, Mar 15, 2019 at 12:51 PM Kohsuke Kawaguchi <kk@...> wrote:
I'm back to work from the hectic week that is OSLS. As everyone said it before, the launch went really well. Here are some thoughts that I'm starting to form that's relevant to what TOC might want to take on.
  • Several people who are behind some of the "CD" projects came up to me and showed their interest to bring their projects under the CDF. All of them are overlapping to some degree with some of the 4 projects that we already have. That by itself isn't a bad thing, but it did make me wonder how we'd approach them. I feel like the industry and vendors are watching what color this foundation will take in the next few months, and if we build a super market with 4 different kind of apples without any oranges, I don't know if that's the message we want to send.
This came up with me as well. I think we should try to understand the motivations these companies have for placing these projects in a foundation and make sure we have places/levels in place for the broad range of projects/motivations. For example, some companies seem to be motivated by:
  • getting a broader contributor base
  • solving a large industry problem that can't be done in isolation
  • marketing, other project support
  • credibility of being in a foundation
We should prioritize establishing a set of areas where the appropriate type of collaboration can take place for each project. CNCF has sandbox, incubating, graduation, etc. to help. Other foundations have other types of "levels".

A sign of a healthy ecosystem would be projects both inside and outside the foundation interoperating and building on each other. We should also work to dispel any notions that projects must be in the CDF to interoperate with the CDF projects. A CDF landscape would be a big help here. I think Chris said these are pretty easy to setup.

  • But another way to look at this is that the reasons those 4 different apples exist (in various different stages of maturity) is that devops teams needed to scratch their itches, and I'd think a part of the reason is that they weren't aware, or didn't feel comfortable joining other projects. I think we can solve those problems here, and that might encourage more collaboration and result in more consolidation, which I think is a better outcome.

Definitely, vendor-neutral owned projects can be much more welcoming to others. 
  • From there, my mind went to "how do we solve that?" There are a lot of things we can do for sure, and some of those are already mentioned by people when we met. For example, putting people behind those projects together and sharing what problems they are trying to solve to each other would be a great step. Another one I thought is to set a bar or provide help to participating projects about transparency to the governance and/or the vision, which help other organized potential contributors to see if it's aligned with what they need, or they need to build something else. That kind of visibility feels like a sign of maturity anyway.

  • Relevant to above visibility/transparency is that people wanted understand where the collaboration with Tekton and Jenkins are happening and what that means.
 Right! I look forward to having these conversations in central, public discussions hosted by the CDF going forward. They've mostly been informal adhoc meetings so far.
  •  


  • From the "4 different kind of apples without any oranges" thought, another place my head went is that it'd be great to recruit projects more proactively (or at least build relations with.) I think that requires drawing a mental map of the super market, that is the CD space.

  • Finally, completely tangentially, I always thought there are lots of rooms for more API/interop focused small projects. I'm a big fan of Grafeas. Another example is the machine readable input/output to test frameworks --- there's the test report format that JUnit started but now used everywhere from nosetest to rspec, and that could really use a name and a schema.
A few other CDF members expressed interest in Grafeas as well. I'll follow up on this in the next couple of weeks. I think there's definitely a need for a CD-focused, secure metadata standard for interop. 
  • Then I'd love to see a mechanism that allows CI/CD tool to specify a subset of tests to run and its order, for more frictionless parallelism and efficiency. It's all fairly trivial things but it takes putting the right group of people in the room to make happen!!

As you can see, random unorganized thoughts here. Love to hear other people's own thoughts.

--
Kohsuke Kawaguchi



--
Chris Aniszczyk (@cra) | +1-512-961-6719



--
Andrew Glover
Director of Delivery Engineering
Netflix, Inc.


Re: Thoughts from OSLS

Kohsuke Kawaguchi
 

Yes, this is great! I've made one pass. I gotta leave the keyboard now, but I'll come back to this later for more.

On Thu, Mar 21, 2019 at 7:38 AM Andy Glover via Lists.Cd.Foundation <aglover=netflix.com@...> wrote:
This is great, thanks for putting this together, Dan! 

-Andy


On Thu, Mar 21, 2019 at 7:30 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks Chris! I threw some initial ideas on principles/values, etc. down here. I started with some of the format from the CNCF documents.

On Fri, Mar 15, 2019 at 4:41 PM Chris Aniszczyk <caniszczyk@...> wrote:
I'm happy to see this discussion going on and my advice would be to focus on two things:

1) establish a set of principles/values that the CDF TOC can agree on as clarity helps with consensus building, see this as an example: https://github.com/cncf/toc/blob/master/PRINCIPLES.md or https://github.com/cncf/foundation/blob/master/charter.md#3-values

There are good ideas to pull from CNCF and other communities out there, with an opportunity to put your own spin on it.

2) establish a project acceptance/lifecycle process:


I'd start there before worrying about landscapes or new projects, establishing a set of values and process the TOC and the community agrees on is critical. While this discussion is happening, the rest of the TOC will be filled out by the GB over the coming couple months (after the GB meets for the first time next month).

Those are my two cents :)

On Fri, Mar 15, 2019 at 11:01 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks for sending this! Some thoughts inline, and I look forward to discussing more in person.

On Fri, Mar 15, 2019 at 12:51 PM Kohsuke Kawaguchi <kk@...> wrote:
I'm back to work from the hectic week that is OSLS. As everyone said it before, the launch went really well. Here are some thoughts that I'm starting to form that's relevant to what TOC might want to take on.
  • Several people who are behind some of the "CD" projects came up to me and showed their interest to bring their projects under the CDF. All of them are overlapping to some degree with some of the 4 projects that we already have. That by itself isn't a bad thing, but it did make me wonder how we'd approach them. I feel like the industry and vendors are watching what color this foundation will take in the next few months, and if we build a super market with 4 different kind of apples without any oranges, I don't know if that's the message we want to send.
This came up with me as well. I think we should try to understand the motivations these companies have for placing these projects in a foundation and make sure we have places/levels in place for the broad range of projects/motivations. For example, some companies seem to be motivated by:
  • getting a broader contributor base
  • solving a large industry problem that can't be done in isolation
  • marketing, other project support
  • credibility of being in a foundation
We should prioritize establishing a set of areas where the appropriate type of collaboration can take place for each project. CNCF has sandbox, incubating, graduation, etc. to help. Other foundations have other types of "levels".

A sign of a healthy ecosystem would be projects both inside and outside the foundation interoperating and building on each other. We should also work to dispel any notions that projects must be in the CDF to interoperate with the CDF projects. A CDF landscape would be a big help here. I think Chris said these are pretty easy to setup.

  • But another way to look at this is that the reasons those 4 different apples exist (in various different stages of maturity) is that devops teams needed to scratch their itches, and I'd think a part of the reason is that they weren't aware, or didn't feel comfortable joining other projects. I think we can solve those problems here, and that might encourage more collaboration and result in more consolidation, which I think is a better outcome.

Definitely, vendor-neutral owned projects can be much more welcoming to others. 
  • From there, my mind went to "how do we solve that?" There are a lot of things we can do for sure, and some of those are already mentioned by people when we met. For example, putting people behind those projects together and sharing what problems they are trying to solve to each other would be a great step. Another one I thought is to set a bar or provide help to participating projects about transparency to the governance and/or the vision, which help other organized potential contributors to see if it's aligned with what they need, or they need to build something else. That kind of visibility feels like a sign of maturity anyway.

  • Relevant to above visibility/transparency is that people wanted understand where the collaboration with Tekton and Jenkins are happening and what that means.
 Right! I look forward to having these conversations in central, public discussions hosted by the CDF going forward. They've mostly been informal adhoc meetings so far.
  •  


  • From the "4 different kind of apples without any oranges" thought, another place my head went is that it'd be great to recruit projects more proactively (or at least build relations with.) I think that requires drawing a mental map of the super market, that is the CD space.

  • Finally, completely tangentially, I always thought there are lots of rooms for more API/interop focused small projects. I'm a big fan of Grafeas. Another example is the machine readable input/output to test frameworks --- there's the test report format that JUnit started but now used everywhere from nosetest to rspec, and that could really use a name and a schema.
A few other CDF members expressed interest in Grafeas as well. I'll follow up on this in the next couple of weeks. I think there's definitely a need for a CD-focused, secure metadata standard for interop. 
  • Then I'd love to see a mechanism that allows CI/CD tool to specify a subset of tests to run and its order, for more frictionless parallelism and efficiency. It's all fairly trivial things but it takes putting the right group of people in the room to make happen!!

As you can see, random unorganized thoughts here. Love to hear other people's own thoughts.

--
Kohsuke Kawaguchi



--
Chris Aniszczyk (@cra) | +1-512-961-6719



--
Andrew Glover
Director of Delivery Engineering
Netflix, Inc.



--
Kohsuke Kawaguchi


Re: Thoughts from OSLS

Chris Aniszczyk
 

Good start, reminder to also fill out the doodle poll for the first meeting:


On Thu, Mar 21, 2019 at 8:35 PM Kohsuke Kawaguchi <kk@...> wrote:
Yes, this is great! I've made one pass. I gotta leave the keyboard now, but I'll come back to this later for more.

On Thu, Mar 21, 2019 at 7:38 AM Andy Glover via Lists.Cd.Foundation <aglover=netflix.com@...> wrote:
This is great, thanks for putting this together, Dan! 

-Andy


On Thu, Mar 21, 2019 at 7:30 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks Chris! I threw some initial ideas on principles/values, etc. down here. I started with some of the format from the CNCF documents.

On Fri, Mar 15, 2019 at 4:41 PM Chris Aniszczyk <caniszczyk@...> wrote:
I'm happy to see this discussion going on and my advice would be to focus on two things:

1) establish a set of principles/values that the CDF TOC can agree on as clarity helps with consensus building, see this as an example: https://github.com/cncf/toc/blob/master/PRINCIPLES.md or https://github.com/cncf/foundation/blob/master/charter.md#3-values

There are good ideas to pull from CNCF and other communities out there, with an opportunity to put your own spin on it.

2) establish a project acceptance/lifecycle process:


I'd start there before worrying about landscapes or new projects, establishing a set of values and process the TOC and the community agrees on is critical. While this discussion is happening, the rest of the TOC will be filled out by the GB over the coming couple months (after the GB meets for the first time next month).

Those are my two cents :)

On Fri, Mar 15, 2019 at 11:01 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks for sending this! Some thoughts inline, and I look forward to discussing more in person.

On Fri, Mar 15, 2019 at 12:51 PM Kohsuke Kawaguchi <kk@...> wrote:
I'm back to work from the hectic week that is OSLS. As everyone said it before, the launch went really well. Here are some thoughts that I'm starting to form that's relevant to what TOC might want to take on.
  • Several people who are behind some of the "CD" projects came up to me and showed their interest to bring their projects under the CDF. All of them are overlapping to some degree with some of the 4 projects that we already have. That by itself isn't a bad thing, but it did make me wonder how we'd approach them. I feel like the industry and vendors are watching what color this foundation will take in the next few months, and if we build a super market with 4 different kind of apples without any oranges, I don't know if that's the message we want to send.
This came up with me as well. I think we should try to understand the motivations these companies have for placing these projects in a foundation and make sure we have places/levels in place for the broad range of projects/motivations. For example, some companies seem to be motivated by:
  • getting a broader contributor base
  • solving a large industry problem that can't be done in isolation
  • marketing, other project support
  • credibility of being in a foundation
We should prioritize establishing a set of areas where the appropriate type of collaboration can take place for each project. CNCF has sandbox, incubating, graduation, etc. to help. Other foundations have other types of "levels".

A sign of a healthy ecosystem would be projects both inside and outside the foundation interoperating and building on each other. We should also work to dispel any notions that projects must be in the CDF to interoperate with the CDF projects. A CDF landscape would be a big help here. I think Chris said these are pretty easy to setup.

  • But another way to look at this is that the reasons those 4 different apples exist (in various different stages of maturity) is that devops teams needed to scratch their itches, and I'd think a part of the reason is that they weren't aware, or didn't feel comfortable joining other projects. I think we can solve those problems here, and that might encourage more collaboration and result in more consolidation, which I think is a better outcome.

Definitely, vendor-neutral owned projects can be much more welcoming to others. 
  • From there, my mind went to "how do we solve that?" There are a lot of things we can do for sure, and some of those are already mentioned by people when we met. For example, putting people behind those projects together and sharing what problems they are trying to solve to each other would be a great step. Another one I thought is to set a bar or provide help to participating projects about transparency to the governance and/or the vision, which help other organized potential contributors to see if it's aligned with what they need, or they need to build something else. That kind of visibility feels like a sign of maturity anyway.

  • Relevant to above visibility/transparency is that people wanted understand where the collaboration with Tekton and Jenkins are happening and what that means.
 Right! I look forward to having these conversations in central, public discussions hosted by the CDF going forward. They've mostly been informal adhoc meetings so far.
  •  


  • From the "4 different kind of apples without any oranges" thought, another place my head went is that it'd be great to recruit projects more proactively (or at least build relations with.) I think that requires drawing a mental map of the super market, that is the CD space.

  • Finally, completely tangentially, I always thought there are lots of rooms for more API/interop focused small projects. I'm a big fan of Grafeas. Another example is the machine readable input/output to test frameworks --- there's the test report format that JUnit started but now used everywhere from nosetest to rspec, and that could really use a name and a schema.
A few other CDF members expressed interest in Grafeas as well. I'll follow up on this in the next couple of weeks. I think there's definitely a need for a CD-focused, secure metadata standard for interop. 
  • Then I'd love to see a mechanism that allows CI/CD tool to specify a subset of tests to run and its order, for more frictionless parallelism and efficiency. It's all fairly trivial things but it takes putting the right group of people in the room to make happen!!

As you can see, random unorganized thoughts here. Love to hear other people's own thoughts.

--
Kohsuke Kawaguchi



--
Chris Aniszczyk (@cra) | +1-512-961-6719



--
Andrew Glover
Director of Delivery Engineering
Netflix, Inc.



--
Kohsuke Kawaguchi



--
Chris Aniszczyk (@cra) | +1-512-961-6719


Re: Bootstrapping the CDF TOC

kayw@...
 

Hi all, I have added my availability as well.  I introduced myself at the kickoff meeting - I work in the Azure Office of the CTO. Microsoft is not a member of the CD Foundation at this time, but I am gathering information and keeping internal teams informed. We are a big company and I suspect some teams will be interested over time. For now, I am learning. Thanks!


CDF Project Acceptance Criteria/Process

Chris Aniszczyk
 

At our upcoming meeting, we should come up with a project proposal process, I highly recommend looking NodeJS/OpenJS as a template:


Anyways, let's put this on the agenda for tomorrow :)


Re: Bootstrapping the CDF TOC

Sheroy Marker
 

Hi all,

I just added my availability as well. To introduce myself, I work with ThoughtWorks Products where we build GoCD. At ThoughtWorks we have experience and a rich legacy with CD. Our products division and I are keen on participating in the CDF by sharing our experiences and our thoughts towards the development of CD as a practice.

Regards,
Sheroy

On Mon, Mar 25, 2019 at 10:44 AM kayw via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:
Hi all, I have added my availability as well.  I introduced myself at the kickoff meeting - I work in the Azure Office of the CTO. Microsoft is not a member of the CD Foundation at this time, but I am gathering information and keeping internal teams informed. We are a big company and I suspect some teams will be interested over time. For now, I am learning. Thanks!


Re: Bootstrapping the CDF TOC

Dan Lorenc <dlorenc@...>
 

Hey All, 

I just closed the poll, apologies for not doing that earlier. The chosen time is tomorrow at 9 PST. The calendar invite is here in this issue:

Dan Lorenc

On Mon, Mar 25, 2019 at 2:43 PM Sheroy Marker <smarker@...> wrote:
Hi all,

I just added my availability as well. To introduce myself, I work with ThoughtWorks Products where we build GoCD. At ThoughtWorks we have experience and a rich legacy with CD. Our products division and I are keen on participating in the CDF by sharing our experiences and our thoughts towards the development of CD as a practice.

Regards,
Sheroy

On Mon, Mar 25, 2019 at 10:44 AM kayw via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:
Hi all, I have added my availability as well.  I introduced myself at the kickoff meeting - I work in the Azure Office of the CTO. Microsoft is not a member of the CD Foundation at this time, but I am gathering information and keeping internal teams informed. We are a big company and I suspect some teams will be interested over time. For now, I am learning. Thanks!


Re: Bootstrapping the CDF TOC

Chris Aniszczyk
 

On Mon, Mar 25, 2019 at 2:46 PM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Hey All, 

I just closed the poll, apologies for not doing that earlier. The chosen time is tomorrow at 9 PST. The calendar invite is here in this issue:

Dan Lorenc

On Mon, Mar 25, 2019 at 2:43 PM Sheroy Marker <smarker@...> wrote:
Hi all,

I just added my availability as well. To introduce myself, I work with ThoughtWorks Products where we build GoCD. At ThoughtWorks we have experience and a rich legacy with CD. Our products division and I are keen on participating in the CDF by sharing our experiences and our thoughts towards the development of CD as a practice.

Regards,
Sheroy

On Mon, Mar 25, 2019 at 10:44 AM kayw via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:
Hi all, I have added my availability as well.  I introduced myself at the kickoff meeting - I work in the Azure Office of the CTO. Microsoft is not a member of the CD Foundation at this time, but I am gathering information and keeping internal teams informed. We are a big company and I suspect some teams will be interested over time. For now, I am learning. Thanks!



--
Chris Aniszczyk (@cra) | +1-512-961-6719


Re: Thoughts from OSLS

Kohsuke Kawaguchi
 

I wasn't sure how to fit this into a comment of the Google Doc, so instead I'm going to write it here.

I was reading what Dan wrote more carefully, and I thought it'd help to dissect multiple layers in it.
  1. The charter lays out the mission of the CDF. This is what the CDF holds self-evident. This is controlled by the GB, and we the TOC start from here.
  2. There's high level technical values/traits/translation of CD that the TOC holds self-evident. This paints the picture of the practice our projects and their software should enable to users. "Security, reliability, velocity: Pick Three" and the following two bullet items that expands security and velocity maps to this part.
  3. Then there are what the TOC want in software that projects produce. Practicality, Maintainability, Portability, Platform/Stack agnostic sections fit in this layer. Extensibility would be in here as well
  4. Then there are what the TOC want in projects that produce those software. Governance section, what I suggested as a comment as "collaborations" fit in this layer. Openness, fairness belongs here as well.
Does this distinction make sense for others? If so, and if Dan is OK, I'm happy to reorganize the text accordingly.

I think this will help prospective projects understand what the CDF is looking for and how they need to evolve once they join. And that naturally leads to the acceptance criteria and project lifecycle conversations -- that is, we want projects that share the same technical interpretations of CD (#2), projects that are willing to go through the evolution to hit quality software that meets #3, and projects that are willing to evolve its governance to hit #4. The graduation criteria follows from #3 & #4.

That should also serve as a brake pedal for the values to become too numerous and onerous.


On Thu, Mar 21, 2019 at 8:05 AM Kohsuke Kawaguchi <kk@...> wrote:
Yes, this is great! I've made one pass. I gotta leave the keyboard now, but I'll come back to this later for more.

On Thu, Mar 21, 2019 at 7:38 AM Andy Glover via Lists.Cd.Foundation <aglover=netflix.com@...> wrote:
This is great, thanks for putting this together, Dan! 

-Andy


On Thu, Mar 21, 2019 at 7:30 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks Chris! I threw some initial ideas on principles/values, etc. down here. I started with some of the format from the CNCF documents.

On Fri, Mar 15, 2019 at 4:41 PM Chris Aniszczyk <caniszczyk@...> wrote:
I'm happy to see this discussion going on and my advice would be to focus on two things:

1) establish a set of principles/values that the CDF TOC can agree on as clarity helps with consensus building, see this as an example: https://github.com/cncf/toc/blob/master/PRINCIPLES.md or https://github.com/cncf/foundation/blob/master/charter.md#3-values

There are good ideas to pull from CNCF and other communities out there, with an opportunity to put your own spin on it.

2) establish a project acceptance/lifecycle process:


I'd start there before worrying about landscapes or new projects, establishing a set of values and process the TOC and the community agrees on is critical. While this discussion is happening, the rest of the TOC will be filled out by the GB over the coming couple months (after the GB meets for the first time next month).

Those are my two cents :)

On Fri, Mar 15, 2019 at 11:01 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks for sending this! Some thoughts inline, and I look forward to discussing more in person.

On Fri, Mar 15, 2019 at 12:51 PM Kohsuke Kawaguchi <kk@...> wrote:
I'm back to work from the hectic week that is OSLS. As everyone said it before, the launch went really well. Here are some thoughts that I'm starting to form that's relevant to what TOC might want to take on.
  • Several people who are behind some of the "CD" projects came up to me and showed their interest to bring their projects under the CDF. All of them are overlapping to some degree with some of the 4 projects that we already have. That by itself isn't a bad thing, but it did make me wonder how we'd approach them. I feel like the industry and vendors are watching what color this foundation will take in the next few months, and if we build a super market with 4 different kind of apples without any oranges, I don't know if that's the message we want to send.
This came up with me as well. I think we should try to understand the motivations these companies have for placing these projects in a foundation and make sure we have places/levels in place for the broad range of projects/motivations. For example, some companies seem to be motivated by:
  • getting a broader contributor base
  • solving a large industry problem that can't be done in isolation
  • marketing, other project support
  • credibility of being in a foundation
We should prioritize establishing a set of areas where the appropriate type of collaboration can take place for each project. CNCF has sandbox, incubating, graduation, etc. to help. Other foundations have other types of "levels".

A sign of a healthy ecosystem would be projects both inside and outside the foundation interoperating and building on each other. We should also work to dispel any notions that projects must be in the CDF to interoperate with the CDF projects. A CDF landscape would be a big help here. I think Chris said these are pretty easy to setup.

  • But another way to look at this is that the reasons those 4 different apples exist (in various different stages of maturity) is that devops teams needed to scratch their itches, and I'd think a part of the reason is that they weren't aware, or didn't feel comfortable joining other projects. I think we can solve those problems here, and that might encourage more collaboration and result in more consolidation, which I think is a better outcome.

Definitely, vendor-neutral owned projects can be much more welcoming to others. 
  • From there, my mind went to "how do we solve that?" There are a lot of things we can do for sure, and some of those are already mentioned by people when we met. For example, putting people behind those projects together and sharing what problems they are trying to solve to each other would be a great step. Another one I thought is to set a bar or provide help to participating projects about transparency to the governance and/or the vision, which help other organized potential contributors to see if it's aligned with what they need, or they need to build something else. That kind of visibility feels like a sign of maturity anyway.

  • Relevant to above visibility/transparency is that people wanted understand where the collaboration with Tekton and Jenkins are happening and what that means.
 Right! I look forward to having these conversations in central, public discussions hosted by the CDF going forward. They've mostly been informal adhoc meetings so far.
  •  


  • From the "4 different kind of apples without any oranges" thought, another place my head went is that it'd be great to recruit projects more proactively (or at least build relations with.) I think that requires drawing a mental map of the super market, that is the CD space.

  • Finally, completely tangentially, I always thought there are lots of rooms for more API/interop focused small projects. I'm a big fan of Grafeas. Another example is the machine readable input/output to test frameworks --- there's the test report format that JUnit started but now used everywhere from nosetest to rspec, and that could really use a name and a schema.
A few other CDF members expressed interest in Grafeas as well. I'll follow up on this in the next couple of weeks. I think there's definitely a need for a CD-focused, secure metadata standard for interop. 
  • Then I'd love to see a mechanism that allows CI/CD tool to specify a subset of tests to run and its order, for more frictionless parallelism and efficiency. It's all fairly trivial things but it takes putting the right group of people in the room to make happen!!

As you can see, random unorganized thoughts here. Love to hear other people's own thoughts.

--
Kohsuke Kawaguchi



--
Chris Aniszczyk (@cra) | +1-512-961-6719



--
Andrew Glover
Director of Delivery Engineering
Netflix, Inc.



--
Kohsuke Kawaguchi



--
Kohsuke Kawaguchi


Re: Thoughts from OSLS

Dan Lorenc <dlorenc@...>
 

Sounds great to me! I didn't put too much thought into the organization and your layout makes sense to me.

The sections I used for inspiration from the cncf and other documents came from all over.

Dan Lorenc

On Mon, Mar 25, 2019, 7:35 PM Kohsuke Kawaguchi <kk@...> wrote:
I wasn't sure how to fit this into a comment of the Google Doc, so instead I'm going to write it here.

I was reading what Dan wrote more carefully, and I thought it'd help to dissect multiple layers in it.
  1. The charter lays out the mission of the CDF. This is what the CDF holds self-evident. This is controlled by the GB, and we the TOC start from here.
  2. There's high level technical values/traits/translation of CD that the TOC holds self-evident. This paints the picture of the practice our projects and their software should enable to users. "Security, reliability, velocity: Pick Three" and the following two bullet items that expands security and velocity maps to this part.
  3. Then there are what the TOC want in software that projects produce. Practicality, Maintainability, Portability, Platform/Stack agnostic sections fit in this layer. Extensibility would be in here as well
  4. Then there are what the TOC want in projects that produce those software. Governance section, what I suggested as a comment as "collaborations" fit in this layer. Openness, fairness belongs here as well.
Does this distinction make sense for others? If so, and if Dan is OK, I'm happy to reorganize the text accordingly.

I think this will help prospective projects understand what the CDF is looking for and how they need to evolve once they join. And that naturally leads to the acceptance criteria and project lifecycle conversations -- that is, we want projects that share the same technical interpretations of CD (#2), projects that are willing to go through the evolution to hit quality software that meets #3, and projects that are willing to evolve its governance to hit #4. The graduation criteria follows from #3 & #4.

That should also serve as a brake pedal for the values to become too numerous and onerous.


On Thu, Mar 21, 2019 at 8:05 AM Kohsuke Kawaguchi <kk@...> wrote:
Yes, this is great! I've made one pass. I gotta leave the keyboard now, but I'll come back to this later for more.

On Thu, Mar 21, 2019 at 7:38 AM Andy Glover via Lists.Cd.Foundation <aglover=netflix.com@...> wrote:
This is great, thanks for putting this together, Dan! 

-Andy


On Thu, Mar 21, 2019 at 7:30 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks Chris! I threw some initial ideas on principles/values, etc. down here. I started with some of the format from the CNCF documents.

On Fri, Mar 15, 2019 at 4:41 PM Chris Aniszczyk <caniszczyk@...> wrote:
I'm happy to see this discussion going on and my advice would be to focus on two things:

1) establish a set of principles/values that the CDF TOC can agree on as clarity helps with consensus building, see this as an example: https://github.com/cncf/toc/blob/master/PRINCIPLES.md or https://github.com/cncf/foundation/blob/master/charter.md#3-values

There are good ideas to pull from CNCF and other communities out there, with an opportunity to put your own spin on it.

2) establish a project acceptance/lifecycle process:


I'd start there before worrying about landscapes or new projects, establishing a set of values and process the TOC and the community agrees on is critical. While this discussion is happening, the rest of the TOC will be filled out by the GB over the coming couple months (after the GB meets for the first time next month).

Those are my two cents :)

On Fri, Mar 15, 2019 at 11:01 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks for sending this! Some thoughts inline, and I look forward to discussing more in person.

On Fri, Mar 15, 2019 at 12:51 PM Kohsuke Kawaguchi <kk@...> wrote:
I'm back to work from the hectic week that is OSLS. As everyone said it before, the launch went really well. Here are some thoughts that I'm starting to form that's relevant to what TOC might want to take on.
  • Several people who are behind some of the "CD" projects came up to me and showed their interest to bring their projects under the CDF. All of them are overlapping to some degree with some of the 4 projects that we already have. That by itself isn't a bad thing, but it did make me wonder how we'd approach them. I feel like the industry and vendors are watching what color this foundation will take in the next few months, and if we build a super market with 4 different kind of apples without any oranges, I don't know if that's the message we want to send.
This came up with me as well. I think we should try to understand the motivations these companies have for placing these projects in a foundation and make sure we have places/levels in place for the broad range of projects/motivations. For example, some companies seem to be motivated by:
  • getting a broader contributor base
  • solving a large industry problem that can't be done in isolation
  • marketing, other project support
  • credibility of being in a foundation
We should prioritize establishing a set of areas where the appropriate type of collaboration can take place for each project. CNCF has sandbox, incubating, graduation, etc. to help. Other foundations have other types of "levels".

A sign of a healthy ecosystem would be projects both inside and outside the foundation interoperating and building on each other. We should also work to dispel any notions that projects must be in the CDF to interoperate with the CDF projects. A CDF landscape would be a big help here. I think Chris said these are pretty easy to setup.

  • But another way to look at this is that the reasons those 4 different apples exist (in various different stages of maturity) is that devops teams needed to scratch their itches, and I'd think a part of the reason is that they weren't aware, or didn't feel comfortable joining other projects. I think we can solve those problems here, and that might encourage more collaboration and result in more consolidation, which I think is a better outcome.

Definitely, vendor-neutral owned projects can be much more welcoming to others. 
  • From there, my mind went to "how do we solve that?" There are a lot of things we can do for sure, and some of those are already mentioned by people when we met. For example, putting people behind those projects together and sharing what problems they are trying to solve to each other would be a great step. Another one I thought is to set a bar or provide help to participating projects about transparency to the governance and/or the vision, which help other organized potential contributors to see if it's aligned with what they need, or they need to build something else. That kind of visibility feels like a sign of maturity anyway.

  • Relevant to above visibility/transparency is that people wanted understand where the collaboration with Tekton and Jenkins are happening and what that means.
 Right! I look forward to having these conversations in central, public discussions hosted by the CDF going forward. They've mostly been informal adhoc meetings so far.
  •  


  • From the "4 different kind of apples without any oranges" thought, another place my head went is that it'd be great to recruit projects more proactively (or at least build relations with.) I think that requires drawing a mental map of the super market, that is the CD space.

  • Finally, completely tangentially, I always thought there are lots of rooms for more API/interop focused small projects. I'm a big fan of Grafeas. Another example is the machine readable input/output to test frameworks --- there's the test report format that JUnit started but now used everywhere from nosetest to rspec, and that could really use a name and a schema.
A few other CDF members expressed interest in Grafeas as well. I'll follow up on this in the next couple of weeks. I think there's definitely a need for a CD-focused, secure metadata standard for interop. 
  • Then I'd love to see a mechanism that allows CI/CD tool to specify a subset of tests to run and its order, for more frictionless parallelism and efficiency. It's all fairly trivial things but it takes putting the right group of people in the room to make happen!!

As you can see, random unorganized thoughts here. Love to hear other people's own thoughts.

--
Kohsuke Kawaguchi



--
Chris Aniszczyk (@cra) | +1-512-961-6719



--
Andrew Glover
Director of Delivery Engineering
Netflix, Inc.



--
Kohsuke Kawaguchi



--
Kohsuke Kawaguchi


Re: Thoughts from OSLS

kayw@...
 

I am new to these discussions, so please forgive if I mention something that has been discussed or covered elsewhere.

 

Would folks consider modifying the charter slightly to focus on ‘standards and open source software’ … in that order. This might lower the barrier for companies who are, or might be, interested in participating in the foundation for the standards aspect, but are hesitant for one of the following reasons:

 

  1. They don’t currently have open source software to contribute.
  2. They have existing products that compete with some of the initial four projects.

 

Thanks,

Kay

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Kohsuke Kawaguchi via Lists.Cd.Foundation
Sent: Monday, March 25, 2019 5:35 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] Thoughts from OSLS

 

I wasn't sure how to fit this into a comment of the Google Doc, so instead I'm going to write it here.

 

I was reading what Dan wrote more carefully, and I thought it'd help to dissect multiple layers in it.

  1. The charter lays out the mission of the CDF. This is what the CDF holds self-evident. This is controlled by the GB, and we the TOC start from here.
  2. There's high level technical values/traits/translation of CD that the TOC holds self-evident. This paints the picture of the practice our projects and their software should enable to users. "Security, reliability, velocity: Pick Three" and the following two bullet items that expands security and velocity maps to this part.
  3. Then there are what the TOC want in software that projects produce. Practicality, Maintainability, Portability, Platform/Stack agnostic sections fit in this layer. Extensibility would be in here as well
  4. Then there are what the TOC want in projects that produce those software. Governance section, what I suggested as a comment as "collaborations" fit in this layer. Openness, fairness belongs here as well.

Does this distinction make sense for others? If so, and if Dan is OK, I'm happy to reorganize the text accordingly.

 

I think this will help prospective projects understand what the CDF is looking for and how they need to evolve once they join. And that naturally leads to the acceptance criteria and project lifecycle conversations -- that is, we want projects that share the same technical interpretations of CD (#2), projects that are willing to go through the evolution to hit quality software that meets #3, and projects that are willing to evolve its governance to hit #4. The graduation criteria follows from #3 & #4.

 

That should also serve as a brake pedal for the values to become too numerous and onerous.

 

 

On Thu, Mar 21, 2019 at 8:05 AM Kohsuke Kawaguchi <kk@...> wrote:

Yes, this is great! I've made one pass. I gotta leave the keyboard now, but I'll come back to this later for more.

 

On Thu, Mar 21, 2019 at 7:38 AM Andy Glover via Lists.Cd.Foundation <aglover=netflix.com@...> wrote:

This is great, thanks for putting this together, Dan! 

 

-Andy

 

 

On Thu, Mar 21, 2019 at 7:30 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:

Thanks Chris! I threw some initial ideas on principles/values, etc. down here. I started with some of the format from the CNCF documents.

 

On Fri, Mar 15, 2019 at 4:41 PM Chris Aniszczyk <caniszczyk@...> wrote:

I'm happy to see this discussion going on and my advice would be to focus on two things:

 

1) establish a set of principles/values that the CDF TOC can agree on as clarity helps with consensus building, see this as an example: https://github.com/cncf/toc/blob/master/PRINCIPLES.md or https://github.com/cncf/foundation/blob/master/charter.md#3-values

 

There are good ideas to pull from CNCF and other communities out there, with an opportunity to put your own spin on it.

 

2) establish a project acceptance/lifecycle process:

 

 

I'd start there before worrying about landscapes or new projects, establishing a set of values and process the TOC and the community agrees on is critical. While this discussion is happening, the rest of the TOC will be filled out by the GB over the coming couple months (after the GB meets for the first time next month).


Those are my two cents :)

 

On Fri, Mar 15, 2019 at 11:01 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:

Thanks for sending this! Some thoughts inline, and I look forward to discussing more in person.

On Fri, Mar 15, 2019 at 12:51 PM Kohsuke Kawaguchi <kk@...> wrote:

I'm back to work from the hectic week that is OSLS. As everyone said it before, the launch went really well. Here are some thoughts that I'm starting to form that's relevant to what TOC might want to take on.

  • Several people who are behind some of the "CD" projects came up to me and showed their interest to bring their projects under the CDF. All of them are overlapping to some degree with some of the 4 projects that we already have. That by itself isn't a bad thing, but it did make me wonder how we'd approach them. I feel like the industry and vendors are watching what color this foundation will take in the next few months, and if we build a super market with 4 different kind of apples without any oranges, I don't know if that's the message we want to send.

This came up with me as well. I think we should try to understand the motivations these companies have for placing these projects in a foundation and make sure we have places/levels in place for the broad range of projects/motivations. For example, some companies seem to be motivated by:

  • getting a broader contributor base
  • solving a large industry problem that can't be done in isolation
  • marketing, other project support
  • credibility of being in a foundation

We should prioritize establishing a set of areas where the appropriate type of collaboration can take place for each project. CNCF has sandbox, incubating, graduation, etc. to help. Other foundations have other types of "levels".

 

A sign of a healthy ecosystem would be projects both inside and outside the foundation interoperating and building on each other. We should also work to dispel any notions that projects must be in the CDF to interoperate with the CDF projects. A CDF landscape would be a big help here. I think Chris said these are pretty easy to setup.

  •  
  • But another way to look at this is that the reasons those 4 different apples exist (in various different stages of maturity) is that devops teams needed to scratch their itches, and I'd think a part of the reason is that they weren't aware, or didn't feel comfortable joining other projects. I think we can solve those problems here, and that might encourage more collaboration and result in more consolidation, which I think is a better outcome.

Definitely, vendor-neutral owned projects can be much more welcoming to others. 

  •  
  • From there, my mind went to "how do we solve that?" There are a lot of things we can do for sure, and some of those are already mentioned by people when we met. For example, putting people behind those projects together and sharing what problems they are trying to solve to each other would be a great step. Another one I thought is to set a bar or provide help to participating projects about transparency to the governance and/or the vision, which help other organized potential contributors to see if it's aligned with what they need, or they need to build something else. That kind of visibility feels like a sign of maturity anyway.
  • Relevant to above visibility/transparency is that people wanted understand where the collaboration with Tekton and Jenkins are happening and what that means.

 Right! I look forward to having these conversations in central, public discussions hosted by the CDF going forward. They've mostly been informal adhoc meetings so far.

  •  

 

  •  
  • From the "4 different kind of apples without any oranges" thought, another place my head went is that it'd be great to recruit projects more proactively (or at least build relations with.) I think that requires drawing a mental map of the super market, that is the CD space.
  • Finally, completely tangentially, I always thought there are lots of rooms for more API/interop focused small projects. I'm a big fan of Grafeas. Another example is the machine readable input/output to test frameworks --- there's the test report format that JUnit started but now used everywhere from nosetest to rspec, and that could really use a name and a schema.

A few other CDF members expressed interest in Grafeas as well. I'll follow up on this in the next couple of weeks. I think there's definitely a need for a CD-focused, secure metadata standard for interop. 

  • Then I'd love to see a mechanism that allows CI/CD tool to specify a subset of tests to run and its order, for more frictionless parallelism and efficiency. It's all fairly trivial things but it takes putting the right group of people in the room to make happen!!

 

As you can see, random unorganized thoughts here. Love to hear other people's own thoughts.

 

--

Kohsuke Kawaguchi


 

--

Chris Aniszczyk (@cra) | +1-512-961-6719


 

--

Andrew Glover

Director of Delivery Engineering

Netflix, Inc.


 

--

Kohsuke Kawaguchi


 

--

Kohsuke Kawaguchi


Re: Thoughts from OSLS

Chris Aniszczyk
 

Hey Kay, great to have you here!

I don't see how any of those reasons would preclude any organization from joining or participating in any technical discussions (we are not a traditional standards body). If you don't have software to contribute, you're welcome to contribute to TOC meetings with ideas or opening up issues as you see fit, CDF is an open source foundation where technical discussions are open to all. In regards to #2, that's great to hear, that shouldn't cause any issues, we look forward to having the market select what is best for them, but that is outside the role of the foundation.

FYI: modifying the charter takes a 2/3 vote of the Governing Board, this mailing list is for the technical board (TOC) which discusses the overall technical strategy for the CDF. I'm happy to bring up your issue at the next GB meeting next month but the CDF is an open source organization first, with specifications that trail any source code.



On Mon, Mar 25, 2019 at 8:08 PM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

I am new to these discussions, so please forgive if I mention something that has been discussed or covered elsewhere.

 

Would folks consider modifying the charter slightly to focus on ‘standards and open source software’ … in that order. This might lower the barrier for companies who are, or might be, interested in participating in the foundation for the standards aspect, but are hesitant for one of the following reasons:

 

  1. They don’t currently have open source software to contribute.
  2. They have existing products that compete with some of the initial four projects.

 

Thanks,

Kay

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Kohsuke Kawaguchi via Lists.Cd.Foundation
Sent: Monday, March 25, 2019 5:35 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] Thoughts from OSLS

 

I wasn't sure how to fit this into a comment of the Google Doc, so instead I'm going to write it here.

 

I was reading what Dan wrote more carefully, and I thought it'd help to dissect multiple layers in it.

  1. The charter lays out the mission of the CDF. This is what the CDF holds self-evident. This is controlled by the GB, and we the TOC start from here.
  2. There's high level technical values/traits/translation of CD that the TOC holds self-evident. This paints the picture of the practice our projects and their software should enable to users. "Security, reliability, velocity: Pick Three" and the following two bullet items that expands security and velocity maps to this part.
  3. Then there are what the TOC want in software that projects produce. Practicality, Maintainability, Portability, Platform/Stack agnostic sections fit in this layer. Extensibility would be in here as well
  4. Then there are what the TOC want in projects that produce those software. Governance section, what I suggested as a comment as "collaborations" fit in this layer. Openness, fairness belongs here as well.

Does this distinction make sense for others? If so, and if Dan is OK, I'm happy to reorganize the text accordingly.

 

I think this will help prospective projects understand what the CDF is looking for and how they need to evolve once they join. And that naturally leads to the acceptance criteria and project lifecycle conversations -- that is, we want projects that share the same technical interpretations of CD (#2), projects that are willing to go through the evolution to hit quality software that meets #3, and projects that are willing to evolve its governance to hit #4. The graduation criteria follows from #3 & #4.

 

That should also serve as a brake pedal for the values to become too numerous and onerous.

 

 

On Thu, Mar 21, 2019 at 8:05 AM Kohsuke Kawaguchi <kk@...> wrote:

Yes, this is great! I've made one pass. I gotta leave the keyboard now, but I'll come back to this later for more.

 

On Thu, Mar 21, 2019 at 7:38 AM Andy Glover via Lists.Cd.Foundation <aglover=netflix.com@...> wrote:

This is great, thanks for putting this together, Dan! 

 

-Andy

 

 

On Thu, Mar 21, 2019 at 7:30 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:

Thanks Chris! I threw some initial ideas on principles/values, etc. down here. I started with some of the format from the CNCF documents.

 

On Fri, Mar 15, 2019 at 4:41 PM Chris Aniszczyk <caniszczyk@...> wrote:

I'm happy to see this discussion going on and my advice would be to focus on two things:

 

1) establish a set of principles/values that the CDF TOC can agree on as clarity helps with consensus building, see this as an example: https://github.com/cncf/toc/blob/master/PRINCIPLES.md or https://github.com/cncf/foundation/blob/master/charter.md#3-values

 

There are good ideas to pull from CNCF and other communities out there, with an opportunity to put your own spin on it.

 

2) establish a project acceptance/lifecycle process:

 

 

I'd start there before worrying about landscapes or new projects, establishing a set of values and process the TOC and the community agrees on is critical. While this discussion is happening, the rest of the TOC will be filled out by the GB over the coming couple months (after the GB meets for the first time next month).


Those are my two cents :)

 

On Fri, Mar 15, 2019 at 11:01 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:

Thanks for sending this! Some thoughts inline, and I look forward to discussing more in person.

On Fri, Mar 15, 2019 at 12:51 PM Kohsuke Kawaguchi <kk@...> wrote:

I'm back to work from the hectic week that is OSLS. As everyone said it before, the launch went really well. Here are some thoughts that I'm starting to form that's relevant to what TOC might want to take on.

  • Several people who are behind some of the "CD" projects came up to me and showed their interest to bring their projects under the CDF. All of them are overlapping to some degree with some of the 4 projects that we already have. That by itself isn't a bad thing, but it did make me wonder how we'd approach them. I feel like the industry and vendors are watching what color this foundation will take in the next few months, and if we build a super market with 4 different kind of apples without any oranges, I don't know if that's the message we want to send.

This came up with me as well. I think we should try to understand the motivations these companies have for placing these projects in a foundation and make sure we have places/levels in place for the broad range of projects/motivations. For example, some companies seem to be motivated by:

  • getting a broader contributor base
  • solving a large industry problem that can't be done in isolation
  • marketing, other project support
  • credibility of being in a foundation

We should prioritize establishing a set of areas where the appropriate type of collaboration can take place for each project. CNCF has sandbox, incubating, graduation, etc. to help. Other foundations have other types of "levels".

 

A sign of a healthy ecosystem would be projects both inside and outside the foundation interoperating and building on each other. We should also work to dispel any notions that projects must be in the CDF to interoperate with the CDF projects. A CDF landscape would be a big help here. I think Chris said these are pretty easy to setup.

  •  
  • But another way to look at this is that the reasons those 4 different apples exist (in various different stages of maturity) is that devops teams needed to scratch their itches, and I'd think a part of the reason is that they weren't aware, or didn't feel comfortable joining other projects. I think we can solve those problems here, and that might encourage more collaboration and result in more consolidation, which I think is a better outcome.

Definitely, vendor-neutral owned projects can be much more welcoming to others. 

  •  
  • From there, my mind went to "how do we solve that?" There are a lot of things we can do for sure, and some of those are already mentioned by people when we met. For example, putting people behind those projects together and sharing what problems they are trying to solve to each other would be a great step. Another one I thought is to set a bar or provide help to participating projects about transparency to the governance and/or the vision, which help other organized potential contributors to see if it's aligned with what they need, or they need to build something else. That kind of visibility feels like a sign of maturity anyway.
  • Relevant to above visibility/transparency is that people wanted understand where the collaboration with Tekton and Jenkins are happening and what that means.

 Right! I look forward to having these conversations in central, public discussions hosted by the CDF going forward. They've mostly been informal adhoc meetings so far.

  •  

 

  •  
  • From the "4 different kind of apples without any oranges" thought, another place my head went is that it'd be great to recruit projects more proactively (or at least build relations with.) I think that requires drawing a mental map of the super market, that is the CD space.
  • Finally, completely tangentially, I always thought there are lots of rooms for more API/interop focused small projects. I'm a big fan of Grafeas. Another example is the machine readable input/output to test frameworks --- there's the test report format that JUnit started but now used everywhere from nosetest to rspec, and that could really use a name and a schema.

A few other CDF members expressed interest in Grafeas as well. I'll follow up on this in the next couple of weeks. I think there's definitely a need for a CD-focused, secure metadata standard for interop. 

  • Then I'd love to see a mechanism that allows CI/CD tool to specify a subset of tests to run and its order, for more frictionless parallelism and efficiency. It's all fairly trivial things but it takes putting the right group of people in the room to make happen!!

 

As you can see, random unorganized thoughts here. Love to hear other people's own thoughts.

 

--

Kohsuke Kawaguchi


 

--

Chris Aniszczyk (@cra) | +1-512-961-6719


 

--

Andrew Glover

Director of Delivery Engineering

Netflix, Inc.


 

--

Kohsuke Kawaguchi


 

--

Kohsuke Kawaguchi



--
Chris Aniszczyk (@cra) | +1-512-961-6719

1 - 20 of 858