|
Quinton Hoole <quinton@...>
Yes, I agree. The model I've been proposing is to select one SIG as the primary caretaker for each project, and have them responsible for engaging other SIGs where appropriate. Here's one nascent example:
If anyone has any better/alternative suggestions, they would be most welcome.
Q
One other angle/comment: We have a model right now a SIG owning some level over oversight over a project. But the mapping may not be that clean. A project may be primarily in a specific space but there may be aspects of that that cross
all the lines. (example is security, but there are others, I’m sure). We need to find the right way to involve the right SIGs at the right times.
Joe
Having gone through some of the debates when we first put the SIG charters together, there are a few other considerations I'd like to add to the debate :-)
In general I think SIGs should bias towards having a broader rather than a narrower scope:
-
A larger/broader SIG community creates critical mass which helps participation and, more importantly, encourages collaboration and information sharing between different projects or initiatives
-
Narrow scopes tend to lead to ambiguity as to where different initiatives should sit - this can cause delays/debate - and this means a lot more "shepherding" by the TOC to help guide and liaise - which might hamper the original
objective to allow the TOC to scale
This was part of the original governance/operating model for the SIGs: Each SIG was to have a number of co-chairs - specifically to allow load sharing and continuity over time. The focus for specific
projects/initiatives is then applied to the tech lead role - of which there can be as many as needed based on the workload/diversity of topics in the SIG scope. This allows the tech leads to be focused on a specific area, whilst the co-chairs help manage
& co-ordinate.
Of course, nothing is static and ideas & orgs evolve over time, so there are always changes that can be applied.
Also, agree with the points about getting content around SIGs on the website (which will help participation), better (and more explicit) management of SIG priorities (which I guess should also
reflect the TOC priorities).
Thanks Liz
This is exactly the discussion I hoped to spark, so I definitely don't mind your debate :-)
Michelle and I happened to have a chat about this today, as she mentioned, and will discuss further with the TOC.
In summary, my personal opinion is that we need to:
1. Agree what the scope of the CNCF is.
2. Partition that scope into bite-sized chunks that cover the entire scope (these were the original 7 proposed SIGs).
3. Make sure that each of the chunks is appropriately taken care of. Over time the details of "appropriately taken care of" will clearly change, as hot spots come and go (FaaS, Service Mesh, Secure Containers, Edge, ..... ), projects come
and go, etc. In the extreme, a chunk may be completely dormant for a period of time, or temporarily focussed on one specific subset. But it's still a chunk of the logical total CNCF scope.
There are many different ways to execute on the above. The 7 originally proposed SIG's and their scopes are one way.
Other ways are fine, as long as they achieve the overall goal over time.
There are several possible ways to implement the above strategy.
On Thu, Nov 7, 2019 at 11:01 AM Liz Rice <liz@...> wrote:
I've been mulling over Quinton's comments on the last TOC call about SIGs reducing their scope.
-
SIGs are there to help the TOC scale, with expertise and/or time that the TOC members don't necessarily have. It would be nice if the whole Cloud Native landscape were neatly divided up amongst SIGs, but I am sure that the landscape is evolving, and we're bound
to end up with things that we didn't anticipate. The TOC remains the decision-making body, and it's also the place where we decide what to do with topics or projects that don't naturally fit in a SIG. So it's OK, and natural, if there are gaps between them.
-
SIGs (and the TOC for that matter) consist of volunteers, who have some finite amount of time to devote to SIG/TOC work. They'll probably achieve more if they stay focussed.
-
The TOC needs to help SIGs prioritize what they're doing. This week Joe and I have been working with SIG Security on exactly this, hopefully it will serve as a template for other TOC-SIG liaisons. I do think that as volunteers, SIG teams (through their chairs)
should be able to influence these priorities.
-
We need to get away from submission-driven prioritization - it would be better to evaluate gaps in the landscape and consider possible alternative projects. So SIGs ideally *should* be focusing on particular areas within their scope
-
SIGs can evolve!
So with all that in mind I've come to the conclusion that actually a SIG reducing their scope could be a healthy sign of focus and enthusiasm. wdyt? Quinton, I hope you don't mind my debate/disagreement :-)
There's not a lot of participation yet in some of the SIGs. I'm hoping there are folks out there who would like to be on the TOC one day, and want to get relevant experience - being meaningfully involved in a SIG should be a great way to
do that (it's one of the goals of the SIGs). So how can we get more folks actively involved?
--
|
|
|
Quinton Hoole <qhoole@...>
Yes, I agree. The model I've been proposing is to select one SIG as the primary caretaker for each project, and have them responsible for engaging other SIGs where appropriate. Here's one nascent example:
If anyone has any better suggestions, they would be most welcome.
Q
toggle quoted message
Show quoted text
From: cncf-toc@... <cncf-toc@...> on behalf of Joe Beda via Lists.Cncf.Io <jbeda=vmware.com@...>
Sent: Friday, November 8, 2019 10:53:07 AM
To: Alex Chircop <alex.chircop@...>; Quinton Hoole via Lists.Cncf.Io <quinton=hoole.biz@...>; Liz Rice <liz@...>
Cc: cncf-toc@... <cncf-toc@...>
Subject: Re: [cncf-toc] SIG scopes
One other angle/comment: We have a model right now a SIG owning some level over oversight over a project. But the mapping may not be that clean. A project may be primarily in a specific space but there may be aspects of that that cross all the lines. (example
is security, but there are others, I’m sure). We need to find the right way to involve the right SIGs at the right times.
Joe
From: <cncf-toc@...> on behalf of Alex Chircop <alex.chircop@...>
Date: Friday, November 8, 2019 at 4:49 AM
To: "Quinton Hoole via Lists.Cncf.Io" <quinton=hoole.biz@...>, Liz Rice <liz@...>
Cc: "cncf-toc@..." <cncf-toc@...>
Subject: Re: [cncf-toc] SIG scopes
Having gone through some of the debates when we first put the SIG charters together, there are a few other considerations I'd like to add to the debate :-)
In general I think SIGs should bias towards having a broader rather than a narrower scope:
-
A larger/broader SIG community creates critical mass which helps participation and, more importantly, encourages collaboration and information sharing between different projects or initiatives
-
Narrow scopes tend to lead to ambiguity as to where different initiatives should sit - this can cause delays/debate - and this means a lot more "shepherding" by the TOC to help guide and liaise - which might hamper the original
objective to allow the TOC to scale
This was part of the original governance/operating model for the SIGs: Each SIG was to have a number of co-chairs - specifically to allow load sharing and continuity over time. The focus for specific projects/initiatives
is then applied to the tech lead role - of which there can be as many as needed based on the workload/diversity of topics in the SIG scope. This allows the tech leads to be focused on a specific area, whilst the co-chairs help manage & co-ordinate.
Of course, nothing is static and ideas & orgs evolve over time, so there are always changes that can be applied.
Also, agree with the points about getting content around SIGs on the website (which will help participation), better (and more explicit) management of SIG priorities (which I guess should also reflect the TOC priorities).
From: cncf-toc@... <cncf-toc@...> on behalf of Quinton Hoole via Lists.Cncf.Io <quinton=hoole.biz@...>
Sent: 07 November 2019 22:01
To: Liz Rice <liz@...>
Cc: cncf-toc@... <cncf-toc@...>
Subject: Re: [cncf-toc] SIG scopes
Thanks Liz
This is exactly the discussion I hoped to spark, so I definitely don't mind your debate :-)
Michelle and I happened to have a chat about this today, as she mentioned, and will discuss further with the TOC.
In summary, my personal opinion is that we need to:
1. Agree what the scope of the CNCF is.
2. Partition that scope into bite-sized chunks that cover the entire scope (these were the original 7 proposed SIGs).
3. Make sure that each of the chunks is appropriately taken care of. Over time the details of "appropriately taken care of" will clearly change, as hot spots come and go (FaaS, Service Mesh, Secure Containers, Edge, ..... ), projects come and go, etc. In
the extreme, a chunk may be completely dormant for a period of time, or temporarily focussed on one specific subset. But it's still a chunk of the logical total CNCF scope.
There are many different ways to execute on the above. The 7 originally proposed SIG's and their scopes are one way.
Other ways are fine, as long as they achieve the overall goal over time.
There are several possible ways to implement the above strategy.
On Thu, Nov 7, 2019 at 11:01 AM Liz Rice <liz@...> wrote:
I've been mulling over Quinton's comments on the last TOC call about SIGs reducing their scope.
-
SIGs are there to help the TOC scale, with expertise and/or time that the TOC members don't necessarily have. It would be nice if the whole Cloud Native landscape were neatly divided up amongst SIGs, but I am sure that the landscape is evolving, and we're bound
to end up with things that we didn't anticipate. The TOC remains the decision-making body, and it's also the place where we decide what to do with topics or projects that don't naturally fit in a SIG. So it's OK, and natural, if there are gaps between them.
-
SIGs (and the TOC for that matter) consist of volunteers, who have some finite amount of time to devote to SIG/TOC work. They'll probably achieve more if they stay focussed.
-
The TOC needs to help SIGs prioritize what they're doing. This week Joe and I have been working with SIG Security on exactly this, hopefully it will serve as a template for other TOC-SIG liaisons. I do think that as volunteers, SIG teams (through their chairs)
should be able to influence these priorities.
-
We need to get away from submission-driven prioritization - it would be better to evaluate gaps in the landscape and consider possible alternative projects. So SIGs ideally *should* be focusing on particular areas within their scope
-
SIGs can evolve!
So with all that in mind I've come to the conclusion that actually a SIG reducing their scope could be a healthy sign of focus and enthusiasm. wdyt? Quinton, I hope you don't mind my debate/disagreement :-)
There's not a lot of participation yet in some of the SIGs. I'm hoping there are folks out there who would like to be on the TOC one day, and want to get relevant experience - being meaningfully involved in a SIG should be a great way to do that (it's one of
the goals of the SIGs). So how can we get more folks actively involved?
--
|
|
|
Folks, let's remember this CNCF SIG stuff is new, and it's up to us to
shape it right. It could take a bit of time. +1 for a SIG leads f2f
at Kubecon.
toggle quoted message
Show quoted text
On Fri, Nov 8, 2019 at 8:44 PM Liz Rice <liz@...> wrote:
Good points. I love the content ideas, Michelle.
Alois suggested a SIG chairs f2f at KubeCon to share ideas if it's possible to find a good time
Liz
On 8 Nov 2019, 18:53 +0000, Joe Beda <jbeda@...>, wrote:
One other angle/comment: We have a model right now a SIG owning some level over oversight over a project. But the mapping may not be that clean. A project may be primarily in a specific space but there may be aspects of that that cross all the lines. (example is security, but there are others, I’m sure). We need to find the right way to involve the right SIGs at the right times.
Joe
From: <cncf-toc@...> on behalf of Alex Chircop <alex.chircop@...>
Date: Friday, November 8, 2019 at 4:49 AM
To: "Quinton Hoole via Lists.Cncf.Io" <quinton=hoole.biz@...>, Liz Rice <liz@...>
Cc: "cncf-toc@..." <cncf-toc@...>
Subject: Re: [cncf-toc] SIG scopes
Having gone through some of the debates when we first put the SIG charters together, there are a few other considerations I'd like to add to the debate :-)
In general I think SIGs should bias towards having a broader rather than a narrower scope:
A larger/broader SIG community creates critical mass which helps participation and, more importantly, encourages collaboration and information sharing between different projects or initiatives
Narrow scopes tend to lead to ambiguity as to where different initiatives should sit - this can cause delays/debate - and this means a lot more "shepherding" by the TOC to help guide and liaise - which might hamper the original objective to allow the TOC to scale
This was part of the original governance/operating model for the SIGs: Each SIG was to have a number of co-chairs - specifically to allow load sharing and continuity over time. The focus for specific projects/initiatives is then applied to the tech lead role - of which there can be as many as needed based on the workload/diversity of topics in the SIG scope. This allows the tech leads to be focused on a specific area, whilst the co-chairs help manage & co-ordinate.
Of course, nothing is static and ideas & orgs evolve over time, so there are always changes that can be applied.
Also, agree with the points about getting content around SIGs on the website (which will help participation), better (and more explicit) management of SIG priorities (which I guess should also reflect the TOC priorities).
________________________________
From: cncf-toc@... <cncf-toc@...> on behalf of Quinton Hoole via Lists.Cncf.Io <quinton=hoole.biz@...>
Sent: 07 November 2019 22:01
To: Liz Rice <liz@...>
Cc: cncf-toc@... <cncf-toc@...>
Subject: Re: [cncf-toc] SIG scopes
Thanks Liz
This is exactly the discussion I hoped to spark, so I definitely don't mind your debate :-)
Michelle and I happened to have a chat about this today, as she mentioned, and will discuss further with the TOC.
In summary, my personal opinion is that we need to:
1. Agree what the scope of the CNCF is.
2. Partition that scope into bite-sized chunks that cover the entire scope (these were the original 7 proposed SIGs).
3. Make sure that each of the chunks is appropriately taken care of. Over time the details of "appropriately taken care of" will clearly change, as hot spots come and go (FaaS, Service Mesh, Secure Containers, Edge, ..... ), projects come and go, etc. In the extreme, a chunk may be completely dormant for a period of time, or temporarily focussed on one specific subset. But it's still a chunk of the logical total CNCF scope.
There are many different ways to execute on the above. The 7 originally proposed SIG's and their scopes are one way.
Other ways are fine, as long as they achieve the overall goal over time.
Q
There are several possible ways to implement the above strategy.
On Thu, Nov 7, 2019 at 11:01 AM Liz Rice <liz@...> wrote:
I've been mulling over Quinton's comments on the last TOC call about SIGs reducing their scope.
SIGs are there to help the TOC scale, with expertise and/or time that the TOC members don't necessarily have. It would be nice if the whole Cloud Native landscape were neatly divided up amongst SIGs, but I am sure that the landscape is evolving, and we're bound to end up with things that we didn't anticipate. The TOC remains the decision-making body, and it's also the place where we decide what to do with topics or projects that don't naturally fit in a SIG. So it's OK, and natural, if there are gaps between them.
SIGs (and the TOC for that matter) consist of volunteers, who have some finite amount of time to devote to SIG/TOC work. They'll probably achieve more if they stay focussed.
The TOC needs to help SIGs prioritize what they're doing. This week Joe and I have been working with SIG Security on exactly this, hopefully it will serve as a template for other TOC-SIG liaisons. I do think that as volunteers, SIG teams (through their chairs) should be able to influence these priorities.
We need to get away from submission-driven prioritization - it would be better to evaluate gaps in the landscape and consider possible alternative projects. So SIGs ideally *should* be focusing on particular areas within their scope
SIGs can evolve!
So with all that in mind I've come to the conclusion that actually a SIG reducing their scope could be a healthy sign of focus and enthusiasm. wdyt? Quinton, I hope you don't mind my debate/disagreement :-)
There's not a lot of participation yet in some of the SIGs. I'm hoping there are folks out there who would like to be on the TOC one day, and want to get relevant experience - being meaningfully involved in a SIG should be a great way to do that (it's one of the goals of the SIGs). So how can we get more folks actively involved?
Liz
--
Quinton Hoole
quinton@...
|
|
|
Good points. I love the content ideas, Michelle.
Alois suggested a SIG chairs f2f at KubeCon to share ideas if it's possible to find a good time
On 8 Nov 2019, 18:53 +0000, Joe Beda <jbeda@...>, wrote:
One other angle/comment: We have a model right now a SIG owning some level over oversight over a project. But the mapping may not be that clean. A project may be primarily in a specific space but there may be aspects of that that cross all the lines. (example is security, but there are others, I’m sure). We need to find the right way to involve the right SIGs at the right times.
Joe
From: <cncf-toc@...> on behalf of Alex Chircop <alex.chircop@...>
Date: Friday, November 8, 2019 at 4:49 AM
To: "Quinton Hoole via Lists.Cncf.Io" <quinton=hoole.biz@...>, Liz Rice <liz@...>
Cc: "cncf-toc@..." <cncf-toc@...>
Subject: Re: [cncf-toc] SIG scopes
Having gone through some of the debates when we first put the SIG charters together, there are a few other considerations I'd like to add to the debate :-)
In general I think SIGs should bias towards having a broader rather than a narrower scope:
- A larger/broader SIG community creates critical mass which helps participation and, more importantly, encourages collaboration and information sharing between different projects or initiatives
- Narrow scopes tend to lead to ambiguity as to where different initiatives should sit - this can cause delays/debate - and this means a lot more "shepherding" by the TOC to help guide and liaise - which might hamper the original objective to allow the TOC to scale
This was part of the original governance/operating model for the SIGs: Each SIG was to have a number of co-chairs - specifically to allow load sharing and continuity over time. The focus for specific projects/initiatives is then applied to the tech lead role - of which there can be as many as needed based on the workload/diversity of topics in the SIG scope. This allows the tech leads to be focused on a specific area, whilst the co-chairs help manage & co-ordinate.
Of course, nothing is static and ideas & orgs evolve over time, so there are always changes that can be applied.
Also, agree with the points about getting content around SIGs on the website (which will help participation), better (and more explicit) management of SIG priorities (which I guess should also reflect the TOC priorities).
From: cncf-toc@... <cncf-toc@...> on behalf of Quinton Hoole via Lists.Cncf.Io <quinton=hoole.biz@...>
Sent: 07 November 2019 22:01
To: Liz Rice <liz@...>
Cc: cncf-toc@... <cncf-toc@...>
Subject: Re: [cncf-toc] SIG scopes
Thanks Liz
This is exactly the discussion I hoped to spark, so I definitely don't mind your debate :-)
Michelle and I happened to have a chat about this today, as she mentioned, and will discuss further with the TOC.
In summary, my personal opinion is that we need to:
1. Agree what the scope of the CNCF is.
2. Partition that scope into bite-sized chunks that cover the entire scope (these were the original 7 proposed SIGs).
3. Make sure that each of the chunks is appropriately taken care of. Over time the details of "appropriately taken care of" will clearly change, as hot spots come and go (FaaS, Service Mesh, Secure Containers, Edge, ..... ), projects come and go, etc. In the extreme, a chunk may be completely dormant for a period of time, or temporarily focussed on one specific subset. But it's still a chunk of the logical total CNCF scope.
There are many different ways to execute on the above. The 7 originally proposed SIG's and their scopes are one way.
Other ways are fine, as long as they achieve the overall goal over time.
There are several possible ways to implement the above strategy.
On Thu, Nov 7, 2019 at 11:01 AM Liz Rice <liz@...> wrote:
I've been mulling over Quinton's comments on the last TOC call about SIGs reducing their scope.
- SIGs are there to help the TOC scale, with expertise and/or time that the TOC members don't necessarily have. It would be nice if the whole Cloud Native landscape were neatly divided up amongst SIGs, but I am sure that the landscape is evolving, and we're bound to end up with things that we didn't anticipate. The TOC remains the decision-making body, and it's also the place where we decide what to do with topics or projects that don't naturally fit in a SIG. So it's OK, and natural, if there are gaps between them.
- SIGs (and the TOC for that matter) consist of volunteers, who have some finite amount of time to devote to SIG/TOC work. They'll probably achieve more if they stay focussed.
- The TOC needs to help SIGs prioritize what they're doing. This week Joe and I have been working with SIG Security on exactly this, hopefully it will serve as a template for other TOC-SIG liaisons. I do think that as volunteers, SIG teams (through their chairs) should be able to influence these priorities.
- We need to get away from submission-driven prioritization - it would be better to evaluate gaps in the landscape and consider possible alternative projects. So SIGs ideally *should* be focusing on particular areas within their scope
- SIGs can evolve!
So with all that in mind I've come to the conclusion that actually a SIG reducing their scope could be a healthy sign of focus and enthusiasm. wdyt? Quinton, I hope you don't mind my debate/disagreement :-)
There's not a lot of participation yet in some of the SIGs. I'm hoping there are folks out there who would like to be on the TOC one day, and want to get relevant experience - being meaningfully involved in a SIG should be a great way to do that (it's one of the goals of the SIGs). So how can we get more folks actively involved?
--
|
|
|
One other angle/comment: We have a model right now a SIG owning some level over oversight over a project. But the mapping may not be that clean. A project may be primarily in a specific space but there may be aspects of that that cross
all the lines. (example is security, but there are others, I’m sure). We need to find the right way to involve the right SIGs at the right times.
Joe
From: <cncf-toc@...> on behalf of Alex Chircop <alex.chircop@...>
Date: Friday, November 8, 2019 at 4:49 AM
To: "Quinton Hoole via Lists.Cncf.Io" <quinton=hoole.biz@...>, Liz Rice <liz@...>
Cc: "cncf-toc@..." <cncf-toc@...>
Subject: Re: [cncf-toc] SIG scopes
Having gone through some of the debates when we first put the SIG charters together, there are a few other considerations I'd like to add to the debate :-)
In general I think SIGs should bias towards having a broader rather than a narrower scope:
-
A larger/broader SIG community creates critical mass which helps participation and, more importantly, encourages collaboration and information sharing between different projects or initiatives
-
Narrow scopes tend to lead to ambiguity as to where different initiatives should sit - this can cause delays/debate - and this means a lot more "shepherding" by the TOC to help guide and liaise - which might hamper the original
objective to allow the TOC to scale
This was part of the original governance/operating model for the SIGs: Each SIG was to have a number of co-chairs - specifically to allow load sharing and continuity over time. The focus for specific
projects/initiatives is then applied to the tech lead role - of which there can be as many as needed based on the workload/diversity of topics in the SIG scope. This allows the tech leads to be focused on a specific area, whilst the co-chairs help manage
& co-ordinate.
Of course, nothing is static and ideas & orgs evolve over time, so there are always changes that can be applied.
Also, agree with the points about getting content around SIGs on the website (which will help participation), better (and more explicit) management of SIG priorities (which I guess should also
reflect the TOC priorities).
toggle quoted message
Show quoted text
From: cncf-toc@... <cncf-toc@...> on behalf of Quinton Hoole via Lists.Cncf.Io <quinton=hoole.biz@...>
Sent: 07 November 2019 22:01
To: Liz Rice <liz@...>
Cc: cncf-toc@... <cncf-toc@...>
Subject: Re: [cncf-toc] SIG scopes
Thanks Liz
This is exactly the discussion I hoped to spark, so I definitely don't mind your debate :-)
Michelle and I happened to have a chat about this today, as she mentioned, and will discuss further with the TOC.
In summary, my personal opinion is that we need to:
1. Agree what the scope of the CNCF is.
2. Partition that scope into bite-sized chunks that cover the entire scope (these were the original 7 proposed SIGs).
3. Make sure that each of the chunks is appropriately taken care of. Over time the details of "appropriately taken care of" will clearly change, as hot spots come and go (FaaS, Service Mesh, Secure Containers, Edge, ..... ), projects come
and go, etc. In the extreme, a chunk may be completely dormant for a period of time, or temporarily focussed on one specific subset. But it's still a chunk of the logical total CNCF scope.
There are many different ways to execute on the above. The 7 originally proposed SIG's and their scopes are one way.
Other ways are fine, as long as they achieve the overall goal over time.
There are several possible ways to implement the above strategy.
On Thu, Nov 7, 2019 at 11:01 AM Liz Rice <liz@...> wrote:
I've been mulling over Quinton's comments on the last TOC call about SIGs reducing their scope.
-
SIGs are there to help the TOC scale, with expertise and/or time that the TOC members don't necessarily have. It would be nice if the whole Cloud Native landscape were neatly divided up amongst SIGs, but I am sure that the landscape is evolving, and we're bound
to end up with things that we didn't anticipate. The TOC remains the decision-making body, and it's also the place where we decide what to do with topics or projects that don't naturally fit in a SIG. So it's OK, and natural, if there are gaps between them.
-
SIGs (and the TOC for that matter) consist of volunteers, who have some finite amount of time to devote to SIG/TOC work. They'll probably achieve more if they stay focussed.
-
The TOC needs to help SIGs prioritize what they're doing. This week Joe and I have been working with SIG Security on exactly this, hopefully it will serve as a template for other TOC-SIG liaisons. I do think that as volunteers, SIG teams (through their chairs)
should be able to influence these priorities.
-
We need to get away from submission-driven prioritization - it would be better to evaluate gaps in the landscape and consider possible alternative projects. So SIGs ideally *should* be focusing on particular areas within their scope
-
SIGs can evolve!
So with all that in mind I've come to the conclusion that actually a SIG reducing their scope could be a healthy sign of focus and enthusiasm. wdyt? Quinton, I hope you don't mind my debate/disagreement :-)
There's not a lot of participation yet in some of the SIGs. I'm hoping there are folks out there who would like to be on the TOC one day, and want to get relevant experience - being meaningfully involved in a SIG should be a great way to
do that (it's one of the goals of the SIGs). So how can we get more folks actively involved?
--
|
|
|
Alex Chircop
Having gone through some of the debates when we first put the SIG charters together, there are a few other considerations I'd like to add to the debate :-)
In general I think SIGs should bias towards having a broader rather than a narrower scope:
- A larger/broader SIG community creates critical mass which helps participation and, more importantly, encourages collaboration and information sharing between different projects or initiatives
- Narrow scopes tend to lead to ambiguity as to where different initiatives should sit - this can cause delays/debate - and this means a lot more "shepherding" by the TOC to help guide and liaise - which might hamper the original objective to allow the TOC
to scale
This was part of the original governance/operating model for the SIGs: Each SIG was to have a number of co-chairs - specifically to allow load sharing and
continuity over time. The focus for specific projects/initiatives is then applied to the tech lead role - of which there can be as many as needed based on the workload/diversity of topics in the SIG scope. This allows the tech leads to be focused on a specific
area, whilst the co-chairs help manage & co-ordinate.
Of course, nothing is static and ideas & orgs evolve over time, so there are always changes that can be applied.
Also, agree with the points about getting content around SIGs on the website (which will help participation), better (and more explicit) management of SIG priorities (which I guess should also reflect the TOC priorities).
toggle quoted message
Show quoted text
From: cncf-toc@... <cncf-toc@...> on behalf of Quinton Hoole via Lists.Cncf.Io <quinton=hoole.biz@...>
Sent: 07 November 2019 22:01
To: Liz Rice <liz@...>
Cc: cncf-toc@... <cncf-toc@...>
Subject: Re: [cncf-toc] SIG scopes
Thanks Liz
This is exactly the discussion I hoped to spark, so I definitely don't mind your debate :-)
Michelle and I happened to have a chat about this today, as she mentioned, and will discuss further with the TOC.
In summary, my personal opinion is that we need to:
1. Agree what the scope of the CNCF is.
2. Partition that scope into bite-sized chunks that cover the entire scope (these were the original 7 proposed SIGs).
3. Make sure that each of the chunks is appropriately taken care of. Over time the details of "appropriately taken care of" will clearly change, as hot spots come and go (FaaS, Service Mesh, Secure Containers, Edge, ..... ), projects come and go, etc.
In the extreme, a chunk may be completely dormant for a period of time, or temporarily focussed on one specific subset. But it's still a chunk of the logical total CNCF scope.
There are many different ways to execute on the above. The 7 originally proposed SIG's and their scopes are one way.
Other ways are fine, as long as they achieve the overall goal over time.
Q
There are several possible ways to implement the above strategy.
On Thu, Nov 7, 2019 at 11:01 AM Liz Rice < liz@...> wrote:
I've been mulling over Quinton's comments on the last TOC call about SIGs reducing their scope.
- SIGs are there to help the TOC scale, with expertise and/or time that the TOC members don't necessarily have. It would be nice if the whole Cloud Native landscape were neatly divided up amongst SIGs, but I am sure that the landscape is evolving, and we're
bound to end up with things that we didn't anticipate. The TOC remains the decision-making body, and it's also the place where we decide what to do with topics or projects that don't naturally fit in a SIG. So it's OK, and natural, if there are gaps
between them.
- SIGs (and the TOC for that matter) consist of volunteers, who have some finite amount of time to devote to SIG/TOC work. They'll probably achieve more if they stay focussed.
- The TOC needs to help SIGs prioritize what they're doing. This week Joe and I have been working with SIG Security on exactly this, hopefully it will serve as a template for other TOC-SIG liaisons. I do think that as volunteers, SIG teams (through their
chairs) should be able to influence these priorities.
- We need to get away from submission-driven prioritization - it would be better to evaluate gaps in the landscape and consider possible alternative projects. So SIGs ideally *should* be focusing on particular areas within their scope
- SIGs can evolve!
So with all that in mind I've come to the conclusion that actually a SIG reducing their scope could be a healthy sign of focus and enthusiasm. wdyt? Quinton, I hope you don't mind my debate/disagreement :-)
There's not a lot of participation yet in some of the SIGs. I'm hoping there are folks out there who would like to be on the TOC one day, and want to get relevant experience - being meaningfully involved in a SIG should be a great way to do that (it's one of
the goals of the SIGs). So how can we get more folks actively involved?
Liz
--
|
|
|
Quinton Hoole <quinton@...>
Thanks Liz
This is exactly the discussion I hoped to spark, so I definitely don't mind your debate :-)
Michelle and I happened to have a chat about this today, as she mentioned, and will discuss further with the TOC.
In summary, my personal opinion is that we need to:
1. Agree what the scope of the CNCF is. 2. Partition that scope into bite-sized chunks that cover the entire scope (these were the original 7 proposed SIGs). 3. Make sure that each of the chunks is appropriately taken care of. Over time the details of "appropriately taken care of" will clearly change, as hot spots come and go (FaaS, Service Mesh, Secure Containers, Edge, ..... ), projects come and go, etc. In the extreme, a chunk may be completely dormant for a period of time, or temporarily focussed on one specific subset. But it's still a chunk of the logical total CNCF scope.
There are many different ways to execute on the above. The 7 originally proposed SIG's and their scopes are one way. Other ways are fine, as long as they achieve the overall goal over time.
Q
There are several possible ways to implement the above strategy.
On Thu, Nov 7, 2019 at 11:01 AM Liz Rice < liz@...> wrote:
I've been mulling over Quinton's comments on the last TOC call about SIGs reducing their scope.
- SIGs are there to help the TOC scale, with expertise and/or time that the TOC members don't necessarily have. It would be nice if the whole Cloud Native landscape were neatly divided up amongst SIGs, but I am sure that the landscape is evolving, and we're bound to end up with things that we didn't anticipate. The TOC remains the decision-making body, and it's also the place where we decide what to do with topics or projects that don't naturally fit in a SIG. So it's OK, and natural, if there are gaps between them.
- SIGs (and the TOC for that matter) consist of volunteers, who have some finite amount of time to devote to SIG/TOC work. They'll probably achieve more if they stay focussed.
- The TOC needs to help SIGs prioritize what they're doing. This week Joe and I have been working with SIG Security on exactly this, hopefully it will serve as a template for other TOC-SIG liaisons. I do think that as volunteers, SIG teams (through their chairs) should be able to influence these priorities.
- We need to get away from submission-driven prioritization - it would be better to evaluate gaps in the landscape and consider possible alternative projects. So SIGs ideally *should* be focusing on particular areas within their scope
- SIGs can evolve!
So with all that in mind I've come to the conclusion that actually a SIG reducing their scope could be a healthy sign of focus and enthusiasm. wdyt? Quinton, I hope you don't mind my debate/disagreement :-)
There's not a lot of participation yet in some of the SIGs. I'm hoping there are folks out there who would like to be on the TOC one day, and want to get relevant experience - being meaningfully involved in a SIG should be a great way to do that (it's one of the goals of the SIGs). So how can we get more folks actively involved?
Liz
|
|
|
Thanks for sharing your thoughts on this Liz. I agree with your bullet points especially around acknowledging that there are gaps and that the TOC is responsible when it comes to gaps (was just chatting with Quinton about this today). I'd like to talk further
on that topic of gaps when we meet in person and how to tactically handle them.
Here are some suggestions on getting people involved in SIGs to get the conversation rolling:
- Let's propose getting some content around SIGs (what they are, how to get involved, why someone may want to get involved) on the cncf.io website maybe under the "People" tab.
- Priorities (milestones, project boards), backlog items (issues), issue labels ("help wanted", "good first issue"), and on-boarding/contributing docs really help with getting people involved in open source projects, so perhaps we can learn from that and
build some guidance for SIG chairs and SIG repos around patterns that will help lower the barrier to entry for getting people involved in their SIGs.
Michelle
toggle quoted message
Show quoted text
From: cncf-toc@... <cncf-toc@...> on behalf of Liz Rice via Lists.Cncf.Io <liz=lizrice.com@...>
Sent: Thursday, November 7, 2019 2:00 PM
To: cncf-toc@... <cncf-toc@...>
Cc: cncf-toc@... <cncf-toc@...>
Subject: [cncf-toc] SIG scopes
I've been mulling over Quinton's comments on the last TOC call about SIGs reducing their scope.
- SIGs are there to help the TOC scale, with expertise and/or time that the TOC members don't necessarily have. It would be nice if the whole Cloud Native landscape were neatly divided up amongst SIGs, but I am sure that the landscape is evolving, and we're
bound to end up with things that we didn't anticipate. The TOC remains the decision-making body, and it's also the place where we decide what to do with topics or projects that don't naturally fit in a SIG. So it's OK, and natural, if there
are gaps between them.
- SIGs (and the TOC for that matter) consist of volunteers, who have some finite amount of time to devote to SIG/TOC work. They'll probably achieve more if they stay focussed.
- The TOC needs to help SIGs prioritize what they're doing. This week Joe and I have been working with SIG Security on exactly this, hopefully it will serve as a template for other TOC-SIG liaisons. I do think that as volunteers, SIG teams (through their
chairs) should be able to influence these priorities.
- We need to get away from submission-driven prioritization - it would be better to evaluate gaps in the landscape and consider possible alternative projects. So SIGs ideally *should* be focusing on particular areas within their scope
- SIGs can evolve!
So with all that in mind I've come to the conclusion that actually a SIG reducing their scope could be a healthy sign of focus and enthusiasm. wdyt? Quinton, I hope you don't mind my debate/disagreement :-)
There's not a lot of participation yet in some of the SIGs. I'm hoping there are folks out there who would like to be on the TOC one day, and want to get relevant experience - being meaningfully involved in a SIG should be a great way to do that (it's one of
the goals of the SIGs). So how can we get more folks actively involved?
Liz
|
|
|
I've been mulling over Quinton's comments on the last TOC call about SIGs reducing their scope.
- SIGs are there to help the TOC scale, with expertise and/or time that the TOC members don't necessarily have. It would be nice if the whole Cloud Native landscape were neatly divided up amongst SIGs, but I am sure that the landscape is evolving, and we're bound to end up with things that we didn't anticipate. The TOC remains the decision-making body, and it's also the place where we decide what to do with topics or projects that don't naturally fit in a SIG. So it's OK, and natural, if there are gaps between them.
- SIGs (and the TOC for that matter) consist of volunteers, who have some finite amount of time to devote to SIG/TOC work. They'll probably achieve more if they stay focussed.
- The TOC needs to help SIGs prioritize what they're doing. This week Joe and I have been working with SIG Security on exactly this, hopefully it will serve as a template for other TOC-SIG liaisons. I do think that as volunteers, SIG teams (through their chairs) should be able to influence these priorities.
- We need to get away from submission-driven prioritization - it would be better to evaluate gaps in the landscape and consider possible alternative projects. So SIGs ideally *should* be focusing on particular areas within their scope
- SIGs can evolve!
So with all that in mind I've come to the conclusion that actually a SIG reducing their scope could be a healthy sign of focus and enthusiasm. wdyt? Quinton, I hope you don't mind my debate/disagreement :-)
There's not a lot of participation yet in some of the SIGs. I'm hoping there are folks out there who would like to be on the TOC one day, and want to get relevant experience - being meaningfully involved in a SIG should be a great way to do that (it's one of the goals of the SIGs). So how can we get more folks actively involved?
Liz
|
|
|
Re: File systems unfit as distributed storage backends
Alex Chircop
It is indeed an interesting paper - metadata management, overwrites vs COW etc ... are all common problems with distributed storage solutions
🙂
toggle quoted message
Show quoted text
From: Alexis Richardson <alexis@...>
Sent: 06 November 2019 21:24
To: Alexis Richardson via cncf-toc <cncf-toc@...>; Alex Chircop <alex.chircop@...>
Subject: File systems unfit as distributed storage backends
|
|
|
Re: Falco DD & Request for Incubation Vote
Kris Nova <kris.nova@...>
Okay thanks for clarifying! Standing by if we can help. — Kris Nova Chief Open Source Advocate
On 6 Nov 2019, at 21:22, Alexis Richardson <alexis@...> wrote:
Previously we have had a period of general review, and then set a future date for a vote to ensure people make an effort to get comments in. A bit like preparing for an exam I guess.
Keep an eye on this list and your GH issue, as community comments may appear.
Hey all,
Also a quick point of clarification - are we on standby until further notice with a formal vote? Unsure what we mean when we say “set a timeline”?
—
Kris Nova
Chief Open Source Advocate
> On 6 Nov 2019, at 16:09, Kris Nova <kris.nova@...> wrote:
>
> Hey all,
>
> Strong +1 with Joe/Alexis
>
> Most of the Falco community will be at KubeCon as well if it would be helpful to meet in person to go over anything.
>
> Thanks for your time and consideration here.
>
> —
> Kris Nova
> Chief Open Source Advocate
>
>
>> On 6 Nov 2019, at 14:23, alexis richardson <alexis@...> wrote:
>>
>> Echoing Joe's call and amplifying to the TOC Contributors. With
>> Kubecon around the corner, I am sure almost everyone is jammed.
>>
>>> On Wed, Nov 6, 2019 at 2:17 PM Joe Beda via Lists.Cncf.Io
>>> <jbeda=vmware.com@...> wrote:
>>>
>>> Hello TOC folks – I’d love to help collect concerns/impressions/questions as we try and set a timeline to get a vote going.
>>>
>>>
>>>
>>> Joe
>>>
>>>
>>>
>>> From: <cncf-toc@...> on behalf of Michael Ducy <michael.ducy@...>
>>> Date: Wednesday, November 6, 2019 at 4:10 AM
>>> To: CNCF TOC <cncf-toc@...>
>>> Subject: [cncf-toc] Falco DD & Request for Incubation Vote
>>>
>>>
>>>
>>> TOC members;
>>>
>>>
>>>
>>> Joe Beda, assisted by Kris Nova and myself, has completed the technical due diligence for Falco, and we would like to request that a formal vote be held for moving Falco to incubation.
>>>
>>>
>>>
>>> As a reminder, our goals in moving to incubation include:
>>>
>>>
>>>
>>> * Moving Falco's build and release infrastructure to CNCF provided infrastructure.
>>>
>>> * Capturing and building on the current momentum of the project.
>>>
>>> * Publishing of end user case studies.
>>>
>>> * Further helping customers achieve compliance in Kubernetes/Cloud Native environments.
>>>
>>>
>>>
>>> Falco Due Diligence:
>>>
>>> https://docs.google.com/document/d/1TJCzW8dQ6858lw2UNY-H5LMnvEd4GzwjuOcDInimeyA/edit?ts=5dacfd96#heading=h.378jkvcve1nq
>>>
>>>
>>>
>>> Technical Explanation of Falco's Architecture and relationship to the Kernel/eBPF capture interface:
>>>
>>> https://sysdig.com/blog/understanding-common-library-implementation/
>>>
>>>
>>>
>>> Falco PR for Incubation:
>>>
>>> https://github.com/cncf/toc/pull/307
>>>
>>>
>>>
>>> Current Falco Release:
>>>
>>> https://github.com/falcosecurity/falco/releases/tag/0.18.0
>>>
>>>
>>>
>>>
>>>
>>> We look forward to feedback from the TOC and broader community.
>>>
>>>
>>>
>>> The Falco Team
>>>
>>>
>>
>>
>>
|
|
|
File systems unfit as distributed storage backends
|
|
|
Re: Falco DD & Request for Incubation Vote
Previously we have had a period of general review, and then set a future date for a vote to ensure people make an effort to get comments in. A bit like preparing for an exam I guess.
Keep an eye on this list and your GH issue, as community comments may appear.
Hey all,
Also a quick point of clarification - are we on standby until further notice with a formal vote? Unsure what we mean when we say “set a timeline”?
—
Kris Nova
Chief Open Source Advocate
> On 6 Nov 2019, at 16:09, Kris Nova <kris.nova@...> wrote:
>
> Hey all,
>
> Strong +1 with Joe/Alexis
>
> Most of the Falco community will be at KubeCon as well if it would be helpful to meet in person to go over anything.
>
> Thanks for your time and consideration here.
>
> —
> Kris Nova
> Chief Open Source Advocate
>
>
>> On 6 Nov 2019, at 14:23, alexis richardson <alexis@...> wrote:
>>
>> Echoing Joe's call and amplifying to the TOC Contributors. With
>> Kubecon around the corner, I am sure almost everyone is jammed.
>>
>>> On Wed, Nov 6, 2019 at 2:17 PM Joe Beda via Lists.Cncf.Io
>>> <jbeda=vmware.com@...> wrote:
>>>
>>> Hello TOC folks – I’d love to help collect concerns/impressions/questions as we try and set a timeline to get a vote going.
>>>
>>>
>>>
>>> Joe
>>>
>>>
>>>
>>> From: <cncf-toc@...> on behalf of Michael Ducy <michael.ducy@...>
>>> Date: Wednesday, November 6, 2019 at 4:10 AM
>>> To: CNCF TOC <cncf-toc@...>
>>> Subject: [cncf-toc] Falco DD & Request for Incubation Vote
>>>
>>>
>>>
>>> TOC members;
>>>
>>>
>>>
>>> Joe Beda, assisted by Kris Nova and myself, has completed the technical due diligence for Falco, and we would like to request that a formal vote be held for moving Falco to incubation.
>>>
>>>
>>>
>>> As a reminder, our goals in moving to incubation include:
>>>
>>>
>>>
>>> * Moving Falco's build and release infrastructure to CNCF provided infrastructure.
>>>
>>> * Capturing and building on the current momentum of the project.
>>>
>>> * Publishing of end user case studies.
>>>
>>> * Further helping customers achieve compliance in Kubernetes/Cloud Native environments.
>>>
>>>
>>>
>>> Falco Due Diligence:
>>>
>>> https://docs.google.com/document/d/1TJCzW8dQ6858lw2UNY-H5LMnvEd4GzwjuOcDInimeyA/edit?ts=5dacfd96#heading=h.378jkvcve1nq
>>>
>>>
>>>
>>> Technical Explanation of Falco's Architecture and relationship to the Kernel/eBPF capture interface:
>>>
>>> https://sysdig.com/blog/understanding-common-library-implementation/
>>>
>>>
>>>
>>> Falco PR for Incubation:
>>>
>>> https://github.com/cncf/toc/pull/307
>>>
>>>
>>>
>>> Current Falco Release:
>>>
>>> https://github.com/falcosecurity/falco/releases/tag/0.18.0
>>>
>>>
>>>
>>>
>>>
>>> We look forward to feedback from the TOC and broader community.
>>>
>>>
>>>
>>> The Falco Team
>>>
>>>
>>
>>
>>
|
|
|
Re: Falco DD & Request for Incubation Vote
Kris Nova <kris.nova@...>
Hey all,
Also a quick point of clarification - are we on standby until further notice with a formal vote? Unsure what we mean when we say “set a timeline”?
—
Kris Nova
Chief Open Source Advocate
toggle quoted message
Show quoted text
On 6 Nov 2019, at 16:09, Kris Nova <kris.nova@...> wrote:
Hey all,
Strong +1 with Joe/Alexis
Most of the Falco community will be at KubeCon as well if it would be helpful to meet in person to go over anything.
Thanks for your time and consideration here.
—
Kris Nova
Chief Open Source Advocate
On 6 Nov 2019, at 14:23, alexis richardson <alexis@...> wrote:
Echoing Joe's call and amplifying to the TOC Contributors. With
Kubecon around the corner, I am sure almost everyone is jammed.
On Wed, Nov 6, 2019 at 2:17 PM Joe Beda via Lists.Cncf.Io
<jbeda=vmware.com@...> wrote:
Hello TOC folks – I’d love to help collect concerns/impressions/questions as we try and set a timeline to get a vote going.
Joe
From: <cncf-toc@...> on behalf of Michael Ducy <michael.ducy@...>
Date: Wednesday, November 6, 2019 at 4:10 AM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] Falco DD & Request for Incubation Vote
TOC members;
Joe Beda, assisted by Kris Nova and myself, has completed the technical due diligence for Falco, and we would like to request that a formal vote be held for moving Falco to incubation.
As a reminder, our goals in moving to incubation include:
* Moving Falco's build and release infrastructure to CNCF provided infrastructure.
* Capturing and building on the current momentum of the project.
* Publishing of end user case studies.
* Further helping customers achieve compliance in Kubernetes/Cloud Native environments.
Falco Due Diligence:
https://docs.google.com/document/d/1TJCzW8dQ6858lw2UNY-H5LMnvEd4GzwjuOcDInimeyA/edit?ts=5dacfd96#heading=h.378jkvcve1nq
Technical Explanation of Falco's Architecture and relationship to the Kernel/eBPF capture interface:
https://sysdig.com/blog/understanding-common-library-implementation/
Falco PR for Incubation:
https://github.com/cncf/toc/pull/307
Current Falco Release:
https://github.com/falcosecurity/falco/releases/tag/0.18.0
We look forward to feedback from the TOC and broader community.
The Falco Team
|
|
|
Re: Falco DD & Request for Incubation Vote
Kris Nova <kris.nova@...>
Hey all,
Strong +1 with Joe/Alexis
Most of the Falco community will be at KubeCon as well if it would be helpful to meet in person to go over anything.
Thanks for your time and consideration here.
—
Kris Nova
Chief Open Source Advocate
toggle quoted message
Show quoted text
On 6 Nov 2019, at 14:23, alexis richardson <alexis@...> wrote:
Echoing Joe's call and amplifying to the TOC Contributors. With
Kubecon around the corner, I am sure almost everyone is jammed.
On Wed, Nov 6, 2019 at 2:17 PM Joe Beda via Lists.Cncf.Io
<jbeda=vmware.com@...> wrote:
Hello TOC folks – I’d love to help collect concerns/impressions/questions as we try and set a timeline to get a vote going.
Joe
From: <cncf-toc@...> on behalf of Michael Ducy <michael.ducy@...>
Date: Wednesday, November 6, 2019 at 4:10 AM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] Falco DD & Request for Incubation Vote
TOC members;
Joe Beda, assisted by Kris Nova and myself, has completed the technical due diligence for Falco, and we would like to request that a formal vote be held for moving Falco to incubation.
As a reminder, our goals in moving to incubation include:
* Moving Falco's build and release infrastructure to CNCF provided infrastructure.
* Capturing and building on the current momentum of the project.
* Publishing of end user case studies.
* Further helping customers achieve compliance in Kubernetes/Cloud Native environments.
Falco Due Diligence:
https://docs.google.com/document/d/1TJCzW8dQ6858lw2UNY-H5LMnvEd4GzwjuOcDInimeyA/edit?ts=5dacfd96#heading=h.378jkvcve1nq
Technical Explanation of Falco's Architecture and relationship to the Kernel/eBPF capture interface:
https://sysdig.com/blog/understanding-common-library-implementation/
Falco PR for Incubation:
https://github.com/cncf/toc/pull/307
Current Falco Release:
https://github.com/falcosecurity/falco/releases/tag/0.18.0
We look forward to feedback from the TOC and broader community.
The Falco Team
|
|
|
Re: Falco DD & Request for Incubation Vote
Echoing Joe's call and amplifying to the TOC Contributors. With Kubecon around the corner, I am sure almost everyone is jammed. On Wed, Nov 6, 2019 at 2:17 PM Joe Beda via Lists.Cncf.Io <jbeda=vmware.com@...> wrote:
Hello TOC folks – I’d love to help collect concerns/impressions/questions as we try and set a timeline to get a vote going.
Joe
From: <cncf-toc@...> on behalf of Michael Ducy <michael.ducy@...>
Date: Wednesday, November 6, 2019 at 4:10 AM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] Falco DD & Request for Incubation Vote
TOC members;
Joe Beda, assisted by Kris Nova and myself, has completed the technical due diligence for Falco, and we would like to request that a formal vote be held for moving Falco to incubation.
As a reminder, our goals in moving to incubation include:
* Moving Falco's build and release infrastructure to CNCF provided infrastructure.
* Capturing and building on the current momentum of the project.
* Publishing of end user case studies.
* Further helping customers achieve compliance in Kubernetes/Cloud Native environments.
Falco Due Diligence:
https://docs.google.com/document/d/1TJCzW8dQ6858lw2UNY-H5LMnvEd4GzwjuOcDInimeyA/edit?ts=5dacfd96#heading=h.378jkvcve1nq
Technical Explanation of Falco's Architecture and relationship to the Kernel/eBPF capture interface:
https://sysdig.com/blog/understanding-common-library-implementation/
Falco PR for Incubation:
https://github.com/cncf/toc/pull/307
Current Falco Release:
https://github.com/falcosecurity/falco/releases/tag/0.18.0
We look forward to feedback from the TOC and broader community.
The Falco Team
|
|
|
Re: Falco DD & Request for Incubation Vote
Hello TOC folks – I’d love to help collect concerns/impressions/questions as we try and set a timeline to get a vote going.
Joe
From: <cncf-toc@...> on behalf of Michael Ducy <michael.ducy@...>
Date: Wednesday, November 6, 2019 at 4:10 AM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] Falco DD & Request for Incubation Vote
TOC members;
Joe Beda, assisted by Kris Nova and myself, has completed the technical due diligence for Falco, and we would like to request that a formal vote be held for moving Falco to incubation.
As a reminder, our goals in moving to incubation include:
* Moving Falco's build and release infrastructure to CNCF provided infrastructure.
* Capturing and building on the current momentum of the project.
* Publishing of end user case studies.
* Further helping customers achieve compliance in Kubernetes/Cloud Native environments.
Technical Explanation of Falco's Architecture and relationship to the Kernel/eBPF capture interface:
We look forward to feedback from the TOC and broader community.
|
|
|
Propose to add Volcano as CNCF Sandbox
Hi team, We'd like to propose Volcano as CNCF sandbox :) Volcano is a Kubernetes Native Batch System, which provides features to run batch workload (e.g. AI/ML, BigData, HPC) on Kubernetes. Please refer to PR for more detail: https://github.com/cncf/toc/pull/318If any suggestion/comments, please let me know :) -- Klaus
|
|
|
Falco DD & Request for Incubation Vote
TOC members;
Joe Beda, assisted by Kris Nova and myself, has completed the technical due diligence for Falco, and we would like to request that a formal vote be held for moving Falco to incubation.
As a reminder, our goals in moving to incubation include:
* Moving Falco's build and release infrastructure to CNCF provided infrastructure. * Capturing and building on the current momentum of the project. * Publishing of end user case studies. * Further helping customers achieve compliance in Kubernetes/Cloud Native environments.
Falco Due Diligence:
Technical Explanation of Falco's Architecture and relationship to the Kernel/eBPF capture interface:
Falco PR for Incubation:
Current Falco Release:
We look forward to feedback from the TOC and broader community.
The Falco Team
|
|
|
[RESULT] Vitess graduation (APPROVED)
Chris Aniszczyk
The Vitess project has been approved to the graduated maturity level:
|
|
|
