Date   

Re: FOSS Governance Library

Josh Berkus
 

On 9/29/20 9:45 AM, Chris Aniszczyk wrote:
This is great! 

Here's another solid resource that we put together last year that covers
the "openness of projects" along with some criteria to look at.
Is there a referencable online version of that paper?


--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO


Re: "Steering committee" discussion

Liz Rice
 

I think my wording could be better - the graduation requirement should be for functional community control of the project roadmap (not merely a plan for a community-controlled roadmap) 

On Tue, 29 Sep 2020 at 18:52, Alexis Richardson <alexis@...> wrote:
"Projects struggling to get maintainers when the owning entity is unwilling to give up control to the community"

This mostly does not happen.  Although due to some bad actors, it can.  Mostly projects are a handful of people on a mission, struggling to make it work, in the face of massive demands and uncertainty.

"What would the mechanism used to be sure that a “plan” for a community controlled roadmap becomes a reality?"

The SC model could generate 
* quarterly roadmap
* contributor ladder
* contingency plan

a






On Tue, Sep 29, 2020 at 6:48 PM Bob Wise (AWS) via lists.cncf.io <wisebob=amazon.com@...> wrote:
















What would the mechanism used to be sure that a “plan” for a community controlled roadmap becomes a reality? At present, holding graduation as the milestone for that is, imho, one of the most critical functions the CNCF has.



 



Projects struggling to get maintainers when the owning entity is unwilling to give up control to the community seems like a natural consequence.



 



-bw



 





From: <cncf-toc@...> on behalf of Liz Rice <liz@...>


Date: Tuesday, September 29, 2020 at 10:44 AM


To: "cncf-toc@..." <cncf-toc@...>


Subject: [EXTERNAL] [cncf-toc] "Steering committee" discussion







 


















CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless

you can confirm the sender and know the content is safe.










 







Thanks everyone who came to the TOC call today - with extra thanks to Alexis for initiating the idea in the first place. I've tried to capture the key points:





 





Problem statement summary: projects that are controlled by a single vendor struggle to meet the current graduation requirement to have maintainers from multiple organizations (for valid reasons such as, they tend to hire the folks

who are expert in that project). This multi-organization requirement is intended to address two concerns: 







1. longevity of the project (in the event that a vendor is acquired or goes out of business)









2. ensuring that the project roadmap is community controlled, and not only run in the commercial interest of the vendor (we want to avoid feature hold-back)







We recognize that the current multi-org requirement may not be the only (or even necessarily the best) way to address those concerns







 







Key points











  • As a graduation requirement, a project should demonstrate a plan for both 1. longevity plan and 2. community-controlled roadmap 


  •  


  •  


  • As now, "maintainers" from a range of organizations is one way to address these points. A steering committee governance model can be another valid model. As at present, TOC isn't going to mandate any particular governance model (though we can discuss guidance

    / ideas / recommendations with projects). The TOC remains the final arbiter of what is considered an acceptable governance model.  


  • Steering committees shouldn't be imposed on a project, we believe they will only be successful if they reflect the community surrounding the project (which can include end users and other vendors, and doesn't have to be limited to code committers)


  • Historically, one reason for projects to struggle to meet the current multi-org maintainer requirement is an inability to attract new maintainers. SIG Contrib Strategy is here to help! As a graduation requirement, a project should have a defined contributor

    ladder that describes how someone can get involved, and the steps they need to take to reach a leadership role within a project. 


  • As previously discussed we should tidy up the language about "maintainer" to make sure that it's clear that governance models can involve non-coding contributors and community members (e.g. a steering committee could involve end users driving the roadmap) 


  • There is interest in the idea of "badging" for projects that could give end users other information (one example suggested was an indicator of how many commercial vendors offer support for a project). WG Governance are working on a proposal for this. 




If this broadly reflects the consensus we can start on wordsmithing the graduation requirement changes in GitHub. 









 







Many thanks everyone for your comments and feedback around these ideas! 







 







Liz 







 







 
































Re: "Steering committee" discussion

alexis richardson
 

"Projects struggling to get maintainers when the owning entity is unwilling to give up control to the community"

This mostly does not happen.  Although due to some bad actors, it can.  Mostly projects are a handful of people on a mission, struggling to make it work, in the face of massive demands and uncertainty.

"What would the mechanism used to be sure that a “plan” for a community controlled roadmap becomes a reality?"

The SC model could generate 
* quarterly roadmap
* contributor ladder
* contingency plan

a






On Tue, Sep 29, 2020 at 6:48 PM Bob Wise (AWS) via lists.cncf.io <wisebob=amazon.com@...> wrote:

What would the mechanism used to be sure that a “plan” for a community controlled roadmap becomes a reality? At present, holding graduation as the milestone for that is, imho, one of the most critical functions the CNCF has.

 

Projects struggling to get maintainers when the owning entity is unwilling to give up control to the community seems like a natural consequence.

 

-bw

 

From: <cncf-toc@...> on behalf of Liz Rice <liz@...>
Date: Tuesday, September 29, 2020 at 10:44 AM
To: "cncf-toc@..." <cncf-toc@...>
Subject: [EXTERNAL] [cncf-toc] "Steering committee" discussion

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

 

Thanks everyone who came to the TOC call today - with extra thanks to Alexis for initiating the idea in the first place. I've tried to capture the key points:

 

Problem statement summary: projects that are controlled by a single vendor struggle to meet the current graduation requirement to have maintainers from multiple organizations (for valid reasons such as, they tend to hire the folks who are expert in that project). This multi-organization requirement is intended to address two concerns: 

1. longevity of the project (in the event that a vendor is acquired or goes out of business)

2. ensuring that the project roadmap is community controlled, and not only run in the commercial interest of the vendor (we want to avoid feature hold-back)

We recognize that the current multi-org requirement may not be the only (or even necessarily the best) way to address those concerns

 

Key points

  • As a graduation requirement, a project should demonstrate a plan for both 1. longevity plan and 2. community-controlled roadmap 
  •  
  •  
  • As now, "maintainers" from a range of organizations is one way to address these points. A steering committee governance model can be another valid model. As at present, TOC isn't going to mandate any particular governance model (though we can discuss guidance / ideas / recommendations with projects). The TOC remains the final arbiter of what is considered an acceptable governance model.  
  • Steering committees shouldn't be imposed on a project, we believe they will only be successful if they reflect the community surrounding the project (which can include end users and other vendors, and doesn't have to be limited to code committers)
  • Historically, one reason for projects to struggle to meet the current multi-org maintainer requirement is an inability to attract new maintainers. SIG Contrib Strategy is here to help! As a graduation requirement, a project should have a defined contributor ladder that describes how someone can get involved, and the steps they need to take to reach a leadership role within a project. 
  • As previously discussed we should tidy up the language about "maintainer" to make sure that it's clear that governance models can involve non-coding contributors and community members (e.g. a steering committee could involve end users driving the roadmap) 
  • There is interest in the idea of "badging" for projects that could give end users other information (one example suggested was an indicator of how many commercial vendors offer support for a project). WG Governance are working on a proposal for this. 

If this broadly reflects the consensus we can start on wordsmithing the graduation requirement changes in GitHub. 

 

Many thanks everyone for your comments and feedback around these ideas! 

 

Liz 

 

 


Re: "Steering committee" discussion

Bob Wise (AWS)
 

What would the mechanism used to be sure that a “plan” for a community controlled roadmap becomes a reality? At present, holding graduation as the milestone for that is, imho, one of the most critical functions the CNCF has.

 

Projects struggling to get maintainers when the owning entity is unwilling to give up control to the community seems like a natural consequence.

 

-bw

 

From: <cncf-toc@...> on behalf of Liz Rice <liz@...>
Date: Tuesday, September 29, 2020 at 10:44 AM
To: "cncf-toc@..." <cncf-toc@...>
Subject: [EXTERNAL] [cncf-toc] "Steering committee" discussion

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

 

Thanks everyone who came to the TOC call today - with extra thanks to Alexis for initiating the idea in the first place. I've tried to capture the key points:

 

Problem statement summary: projects that are controlled by a single vendor struggle to meet the current graduation requirement to have maintainers from multiple organizations (for valid reasons such as, they tend to hire the folks who are expert in that project). This multi-organization requirement is intended to address two concerns: 

1. longevity of the project (in the event that a vendor is acquired or goes out of business)

2. ensuring that the project roadmap is community controlled, and not only run in the commercial interest of the vendor (we want to avoid feature hold-back)

We recognize that the current multi-org requirement may not be the only (or even necessarily the best) way to address those concerns

 

Key points

  • As a graduation requirement, a project should demonstrate a plan for both 1. longevity plan and 2. community-controlled roadmap 
  •  
  •  
  • As now, "maintainers" from a range of organizations is one way to address these points. A steering committee governance model can be another valid model. As at present, TOC isn't going to mandate any particular governance model (though we can discuss guidance / ideas / recommendations with projects). The TOC remains the final arbiter of what is considered an acceptable governance model.  
  • Steering committees shouldn't be imposed on a project, we believe they will only be successful if they reflect the community surrounding the project (which can include end users and other vendors, and doesn't have to be limited to code committers)
  • Historically, one reason for projects to struggle to meet the current multi-org maintainer requirement is an inability to attract new maintainers. SIG Contrib Strategy is here to help! As a graduation requirement, a project should have a defined contributor ladder that describes how someone can get involved, and the steps they need to take to reach a leadership role within a project. 
  • As previously discussed we should tidy up the language about "maintainer" to make sure that it's clear that governance models can involve non-coding contributors and community members (e.g. a steering committee could involve end users driving the roadmap) 
  • There is interest in the idea of "badging" for projects that could give end users other information (one example suggested was an indicator of how many commercial vendors offer support for a project). WG Governance are working on a proposal for this. 

If this broadly reflects the consensus we can start on wordsmithing the graduation requirement changes in GitHub. 

 

Many thanks everyone for your comments and feedback around these ideas! 

 

Liz 

 

 


Re: "Steering committee" discussion

alexis richardson
 

I wish to note that it was @cra's idea. I just wrote about it and
then talked about it a lot.

On Tue, Sep 29, 2020 at 6:43 PM Liz Rice <liz@lizrice.com> wrote:

Thanks everyone who came to the TOC call today - with extra thanks to Alexis for initiating the idea in the first place. I've tried to capture the key points:

Problem statement summary: projects that are controlled by a single vendor struggle to meet the current graduation requirement to have maintainers from multiple organizations (for valid reasons such as, they tend to hire the folks who are expert in that project). This multi-organization requirement is intended to address two concerns:
1. longevity of the project (in the event that a vendor is acquired or goes out of business)
2. ensuring that the project roadmap is community controlled, and not only run in the commercial interest of the vendor (we want to avoid feature hold-back)
We recognize that the current multi-org requirement may not be the only (or even necessarily the best) way to address those concerns

Key points

As a graduation requirement, a project should demonstrate a plan for both 1. longevity plan and 2. community-controlled roadmap
As now, "maintainers" from a range of organizations is one way to address these points. A steering committee governance model can be another valid model. As at present, TOC isn't going to mandate any particular governance model (though we can discuss guidance / ideas / recommendations with projects). The TOC remains the final arbiter of what is considered an acceptable governance model.
Steering committees shouldn't be imposed on a project, we believe they will only be successful if they reflect the community surrounding the project (which can include end users and other vendors, and doesn't have to be limited to code committers)
Historically, one reason for projects to struggle to meet the current multi-org maintainer requirement is an inability to attract new maintainers. SIG Contrib Strategy is here to help! As a graduation requirement, a project should have a defined contributor ladder that describes how someone can get involved, and the steps they need to take to reach a leadership role within a project.
As previously discussed we should tidy up the language about "maintainer" to make sure that it's clear that governance models can involve non-coding contributors and community members (e.g. a steering committee could involve end users driving the roadmap)
There is interest in the idea of "badging" for projects that could give end users other information (one example suggested was an indicator of how many commercial vendors offer support for a project). WG Governance are working on a proposal for this.

If this broadly reflects the consensus we can start on wordsmithing the graduation requirement changes in GitHub.

Many thanks everyone for your comments and feedback around these ideas!

Liz



"Steering committee" discussion

Liz Rice
 

Thanks everyone who came to the TOC call today - with extra thanks to Alexis for initiating the idea in the first place. I've tried to capture the key points:

Problem statement summary: projects that are controlled by a single vendor struggle to meet the current graduation requirement to have maintainers from multiple organizations (for valid reasons such as, they tend to hire the folks who are expert in that project). This multi-organization requirement is intended to address two concerns: 
1. longevity of the project (in the event that a vendor is acquired or goes out of business)
2. ensuring that the project roadmap is community controlled, and not only run in the commercial interest of the vendor (we want to avoid feature hold-back)
We recognize that the current multi-org requirement may not be the only (or even necessarily the best) way to address those concerns

Key points
  • As a graduation requirement, a project should demonstrate a plan for both 1. longevity plan and 2. community-controlled roadmap 
  • As now, "maintainers" from a range of organizations is one way to address these points. A steering committee governance model can be another valid model. As at present, TOC isn't going to mandate any particular governance model (though we can discuss guidance / ideas / recommendations with projects). The TOC remains the final arbiter of what is considered an acceptable governance model.  
  • Steering committees shouldn't be imposed on a project, we believe they will only be successful if they reflect the community surrounding the project (which can include end users and other vendors, and doesn't have to be limited to code committers)
  • Historically, one reason for projects to struggle to meet the current multi-org maintainer requirement is an inability to attract new maintainers. SIG Contrib Strategy is here to help! As a graduation requirement, a project should have a defined contributor ladder that describes how someone can get involved, and the steps they need to take to reach a leadership role within a project. 
  • As previously discussed we should tidy up the language about "maintainer" to make sure that it's clear that governance models can involve non-coding contributors and community members (e.g. a steering committee could involve end users driving the roadmap) 
  • There is interest in the idea of "badging" for projects that could give end users other information (one example suggested was an indicator of how many commercial vendors offer support for a project). WG Governance are working on a proposal for this. 
If this broadly reflects the consensus we can start on wordsmithing the graduation requirement changes in GitHub. 

Many thanks everyone for your comments and feedback around these ideas! 

Liz 



Re: FOSS Governance Library

Chris Aniszczyk
 

This is great! 

Here's another solid resource that we put together last year that covers the "openness of projects" along with some criteria to look at.

On Tue, Sep 29, 2020 at 11:36 AM Matt Farina <matt@...> wrote:
Since we have been talking governance, I just noticed a new catalog of FOSS Governance documents launched. It's at https://fossgovernance.org/. It has pointers to many governance docs on many open source projects.

Cheers,
Matt



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


FOSS Governance Library

Matt Farina
 

Since we have been talking governance, I just noticed a new catalog of FOSS Governance documents launched. It's at https://fossgovernance.org/. It has pointers to many governance docs on many open source projects.

Cheers,
Matt


Re: OPA to graduation

Andrés Vega
 

Working in synchronicity from the authentication problem space adjacent to authorization, it has been fascinating to watch OPA evolve and grow in both adoption and maturity. 

In every SPIFFE and SPIRE conversation, OPA always surfaces as the best architectural fit for a comprehensive identity and authorization solution. While there is a learning curve to Rego, people do manage to wrap their heads around it as it pays dividends in return.

As Joe, I'd like to see overtime further standardization of the APIs. 

+1 NB


Andres


Agenda for TOC meeting for 9/29

Amye Scavarda Perrin
 

Hi all, 
We'll be meeting tomorrow at 8am Pacific, discussing graduation requirements around maintainer diversity. 



Thanks! 
-- amye 
--
Amye Scavarda Perrin | Program Manager | amye@...


Re: OPA to graduation

alexis richardson
 

Something something "doomed to reinvent lisp"...

+1, nb


On Mon, 28 Sep 2020, 20:14 Joe Beda, <jbeda@...> wrote:

+1 NB

 

Agree with Gareth that there is no silver bullet here.  Just like programming languages there are preferences and different needs and no one size fits all solution.

 

That being said, I think that OPA clearly hits a sweet spot and has a growing community. And the CNCF is welcoming to ~competing projects so graduating OPA doesn’t mean that other alternatives can’t also be supported and part of the CNCF umbrella.

 

One thing that I’d, personally, like to see is more standardization around the interfaces to these type of systems.  Is it possible to replace OPA with another similar system and not have to retool the APIs to the policy engine?  Would be interesting to standardize around some other interfaces to OPA too like the way that side-channel data is specified/presented and the way that decision information is surfaced back up to external monitoring/logging systems.  (I’ve passed this on to the OPA folks so it should be a surprise to them.)

 

Joe

 

From: cncf-toc@... <cncf-toc@...>
Date: Sunday, September 27, 2020 at 2:10 AM
To: gadi@... <gadi@...>
Cc: CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] OPA to graduation

+1 NB

I'm biased here, as one of the maintainers of the Conftest project
which is now part of OPA.

I wanted to address the point above about Rego.

I'm an unashamed DSL nerd. I was a user and contributor to Puppet and
then worked there. I was an early Docker user, gave talks about
Dockerfile and then worked at Docker. I originally built Conftest in
order to provide a better local developer experience to OPA because I
wanted to use Rego.

But, I'm also a fan of Chef. I spent last week putting together a
bunch of demos using Pulumi. I like general purpose programming
languages too.

Oh, and I like data as well. I contributed to Ansible. I wanted to
like Jsonnet, really like CUE, like aspects of YTT.

I can reason about the trade offs between these 3 different approaches
to configuration for what would be an unreasonable length of time for
most people. As a user and contributor I've been through a few
generations of tools in this space as a user and developer, and I
fully expect to see several more generations too. That's maddening to
some, and fun for me. I have strange hobbies.

The reality here is most end users have a strong preference for tools
in one of those groups at any given moment in time.
This isn't a new observation. It's worth reading the Configuration
Complexity Clock from back in 2012 as it's still as relevant here as
when it was written
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmikehadlow.blogspot.com%2F2012%2F05%2Fconfiguration-complexity-clock.html&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286664027&amp;sdata=Xf4EZ22F0EdT7e3PHtmBQcNVhfZlmpU%2B0MvddJM8BhE%3D&amp;reserved=0

That is to say we'll likely see 3 distinct policy approaches over
time, one DSL, one data and one general purpose language.
In fact we already see projects like k-rail (using Go for authoring
policies https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcruise-automation%2Fk-rail&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286664027&amp;sdata=S6iscJAvXQfHTLLDi6AIbWVwCi89SU3tjbfcAcM%2BzHI%3D&amp;reserved=0) and Kyverno
(using YAML for authoring https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnirmata%2Fkyverno&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286664027&amp;sdata=54ow6wTL166eK19uxAi7%2BZZkJ1a3IahR4YKm0RmZGeI%3D&amp;reserved=0)

OPA today focuses on one of these approaches, my experience tells me
there will always be folks who prefer one of the others, and that's
fine. The CNCF shouldn't enforce one approach or another, but look at
usage.

The Open Policy Agent community in general has also been working on
lowering the barrier to learning Rego. The rego playground in
particular is invaluable https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.openpolicyagent.org%2F&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&amp;sdata=aZZEpTkffy3nbwbuz71hBtK42qAQJtLpssRKNuz2PcI%3D&amp;reserved=0. Rego
adoption has been growing rapidly, it's nature means most rego is
written behind private repos but
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgithub%2Flinguist%2Fissues%2F4219&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&amp;sdata=gbLcPvm0txcoE%2B8QXBl0Tp3cMdL8shHqZML%2FXSk9NbY%3D&amp;reserved=0 shows 296 rego files
publicly on GitHub in January 2019. Today there are more than 6000
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsearch%3Futf8%3D%25E2%259C%2593%26type%3DCode%26ref%3Dsearchresults%26q%3Dextension%3Arego%2Bpackage%2BNOT%2Bnothack&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&amp;sdata=dq2gMhiDLnfHxlG3MxDWmeq1DzHjckN%2FfAmoaEvfenQ%3D&amp;reserved=0.
There has also been work done around sharing, so many end users can
use Open Policy Agent without needing to write rego. For instance we
were one of the first communities to define OCI Artifact metadata
(https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopen-policy-agent%2Fopa%2Fissues%2F1413&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&amp;sdata=BZPQBu4p2GzC7XsfDkvWBH4syELw6eoFCHE581CgFYM%3D&amp;reserved=0) which then
powers features like
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Faws.amazon.com%2Fblogs%2Fcontainers%2Foci-artifact-support-in-amazon-ecr%2F&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637367946286674021&amp;sdata=7zQ7z6Zpz%2BFr0%2FEycFdgOMI5aijqgV7Lk8VHpecewoY%3D&amp;reserved=0.

Hopefully that's a useful viewpoint and addition to the conversation.

Gareth





Re: OPA to graduation

Joe Beda <jbeda@...>
 

+1 NB

 

Agree with Gareth that there is no silver bullet here.  Just like programming languages there are preferences and different needs and no one size fits all solution.

 

That being said, I think that OPA clearly hits a sweet spot and has a growing community. And the CNCF is welcoming to ~competing projects so graduating OPA doesn’t mean that other alternatives can’t also be supported and part of the CNCF umbrella.

 

One thing that I’d, personally, like to see is more standardization around the interfaces to these type of systems.  Is it possible to replace OPA with another similar system and not have to retool the APIs to the policy engine?  Would be interesting to standardize around some other interfaces to OPA too like the way that side-channel data is specified/presented and the way that decision information is surfaced back up to external monitoring/logging systems.  (I’ve passed this on to the OPA folks so it should be a surprise to them.)

 

Joe

 

From: cncf-toc@... <cncf-toc@...>
Date: Sunday, September 27, 2020 at 2:10 AM
To: gadi@... <gadi@...>
Cc: CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] OPA to graduation

+1 NB

I'm biased here, as one of the maintainers of the Conftest project
which is now part of OPA.

I wanted to address the point above about Rego.

I'm an unashamed DSL nerd. I was a user and contributor to Puppet and
then worked there. I was an early Docker user, gave talks about
Dockerfile and then worked at Docker. I originally built Conftest in
order to provide a better local developer experience to OPA because I
wanted to use Rego.

But, I'm also a fan of Chef. I spent last week putting together a
bunch of demos using Pulumi. I like general purpose programming
languages too.

Oh, and I like data as well. I contributed to Ansible. I wanted to
like Jsonnet, really like CUE, like aspects of YTT.

I can reason about the trade offs between these 3 different approaches
to configuration for what would be an unreasonable length of time for
most people. As a user and contributor I've been through a few
generations of tools in this space as a user and developer, and I
fully expect to see several more generations too. That's maddening to
some, and fun for me. I have strange hobbies.

The reality here is most end users have a strong preference for tools
in one of those groups at any given moment in time.
This isn't a new observation. It's worth reading the Configuration
Complexity Clock from back in 2012 as it's still as relevant here as
when it was written
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmikehadlow.blogspot.com%2F2012%2F05%2Fconfiguration-complexity-clock.html&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286664027&amp;sdata=Xf4EZ22F0EdT7e3PHtmBQcNVhfZlmpU%2B0MvddJM8BhE%3D&amp;reserved=0

That is to say we'll likely see 3 distinct policy approaches over
time, one DSL, one data and one general purpose language.
In fact we already see projects like k-rail (using Go for authoring
policies https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcruise-automation%2Fk-rail&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286664027&amp;sdata=S6iscJAvXQfHTLLDi6AIbWVwCi89SU3tjbfcAcM%2BzHI%3D&amp;reserved=0) and Kyverno
(using YAML for authoring https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnirmata%2Fkyverno&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286664027&amp;sdata=54ow6wTL166eK19uxAi7%2BZZkJ1a3IahR4YKm0RmZGeI%3D&amp;reserved=0)

OPA today focuses on one of these approaches, my experience tells me
there will always be folks who prefer one of the others, and that's
fine. The CNCF shouldn't enforce one approach or another, but look at
usage.

The Open Policy Agent community in general has also been working on
lowering the barrier to learning Rego. The rego playground in
particular is invaluable https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.openpolicyagent.org%2F&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&amp;sdata=aZZEpTkffy3nbwbuz71hBtK42qAQJtLpssRKNuz2PcI%3D&amp;reserved=0. Rego
adoption has been growing rapidly, it's nature means most rego is
written behind private repos but
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgithub%2Flinguist%2Fissues%2F4219&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&amp;sdata=gbLcPvm0txcoE%2B8QXBl0Tp3cMdL8shHqZML%2FXSk9NbY%3D&amp;reserved=0 shows 296 rego files
publicly on GitHub in January 2019. Today there are more than 6000
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsearch%3Futf8%3D%25E2%259C%2593%26type%3DCode%26ref%3Dsearchresults%26q%3Dextension%3Arego%2Bpackage%2BNOT%2Bnothack&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&amp;sdata=dq2gMhiDLnfHxlG3MxDWmeq1DzHjckN%2FfAmoaEvfenQ%3D&amp;reserved=0.
There has also been work done around sharing, so many end users can
use Open Policy Agent without needing to write rego. For instance we
were one of the first communities to define OCI Artifact metadata
(https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopen-policy-agent%2Fopa%2Fissues%2F1413&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&amp;sdata=BZPQBu4p2GzC7XsfDkvWBH4syELw6eoFCHE581CgFYM%3D&amp;reserved=0) which then
powers features like
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Faws.amazon.com%2Fblogs%2Fcontainers%2Foci-artifact-support-in-amazon-ecr%2F&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637367946286674021&amp;sdata=7zQ7z6Zpz%2BFr0%2FEycFdgOMI5aijqgV7Lk8VHpecewoY%3D&amp;reserved=0.

Hopefully that's a useful viewpoint and addition to the conversation.

Gareth





Re: [RESULT] Emily Fox approved as co-chair for SIG Security

Santiago Torres Arias <santiago@...>
 

Congratulations, Emily!

On Mon, Sep 28, 2020 at 08:00:00AM -0700, Amye Scavarda Perrin wrote:
Emily Fox for SIG Security Chair:
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5303&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=cvOXQnL0uHd74hDyDWOe0iZEsP9S1ZpVsppc8T3glVw&e=

+1 Binding
7/10
Justin Cormack: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5312&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=6KQ1-f9Qvp8lvp7Dnek3HBZstjYYKfStdGKl5o_i5Ok&e=
Michelle Noorali: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5315&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=04IZ3omAAWlw-JHaDqfsb4JdiqPMRaw3dC5ZlzuvsOE&e=
Liz Rice: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5318&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=9U4PNNfAolse9EAB8_omh3CquTnAwt3YcYPDYgHpW4k&e=
Alena Prokharchyk: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5319&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=zZKRzCO4AxhiTQp1jPX3pB-yRja2YHy7_JTEGAGf-a8&e=
Katie Gamanji: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5325&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=MWg6pjA2b84djDnWe8icF7t4cyk8_moubqjUDkwNWdY&e=
Saad Ali: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5326&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=6andbIBlUzi2azRgy9IMRV8XE0FThjPrtUtBxJVQRmo&e=
Matt Klein: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5327&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=wayaW7SMvyJSwgvdHEF2adUjgYcwY8GGeVyGj7BxMro&e=

+1 NB
Justin Cappos https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5304&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=VgDz3A2vY0X9uu-FtyYvpLLBu40Z1YyBFpT3gr5IYm0&e=
Brandon Lum: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5305&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=_NXLFJGgnHPNekVKtBnWJ-PyrVBPCZfv7V-tw_BreUs&e=
Chase Pettet:https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5306&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=rXQfIwsfZPgIL6W5QVunCwXtSCTTRFBCqoLzNo5AWac&e=
Paris Pittman: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5307&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=YhRp-Pnu64zHYnjyG7iu5sQVB5-94jE6gecu5V_WWtE&e=
John Hillegass: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5308&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=dKFlVv-NvximxcyfrSHllJUQDAE3SD6nYJKjVp_HKxs&e=
Sarah Allen: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5309&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=_ozh93VFV5t9upw3ZHWLOhy9EdXOU9Y19ghJIp_QgmE&e=
Gadi Naor: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5310&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=hEV8M6oi_ucj7LDSkLXqVa7xAk-psCTsJn-jTjMF8Jk&e=
Frederick Kautz: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5311&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=CZpg03KmYvGx4SZVmfa1q4ycqZtijdQVjn6rj6weWAE&e=
Santiago Torres Arias: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5313&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=3pqvOZcIYtQYTDNAlGW6cZDpD6BOcbjG7FECxDY4t_0&e=
Andrew Martin: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5314&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=zUdOgoorgfkYG_RU0grNuZ-FtUR7HmEQVYsg47ipKXc&e=
Ricardo Aravena: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5316&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=hAn7nQ66xhQo_9G7Ll9jmvp13aexdz43itWcNRpkHqE&e=
Siddharth Bhadri: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5320&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=DBmDhSYdY66kvFj0Sve0CJHprzNq4xvQ3TT6QylVgrU&e=
Ashutosh Narkar: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5321&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=gqSIjvPUb_Ul1jqaPQ4PrTrxW6Fo2MmqFrjAq67XEO8&e=
Andrés Vega: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5323&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=WIKFfvVmV4Ftavv48jonyHUqj-fx0MOjgCByR1ldYRk&e=

--
Amye Scavarda Perrin | Program Manager | amye@linuxfoundation.org





[RESULT] Emily Fox approved as co-chair for SIG Security

Amye Scavarda Perrin
 


Re: OPA to graduation

Jim Bugwadia
 

+1 NB

I am a maintainer of Kyverno (https://github.com/nirmata/kyverno/blob/master/README.md), which as mentioned above is an alternative to OPA/Gatekeeper. We believe that policies are essential to wider (and safer) enterprise adoption of Kubernetes, which is why we built Kyverno to be easy to use and maintain for all Kubernetes users.

I agree with all the points above on the steep learning curve and ongoing challenges of managing OPA policies in Rego. However, my understanding of the incubating-to-graduation requirements is that they are based on project usage and maturity. 

Assuming OPA meets all listed graduation requirements, and assuming that there will be other alternatives like Kyverno, etc. that will ideally become part of the CNCF ecosystem (Kyverno is planning sandbox submission), I see overall value and benefits in OPA graduating to help promote one available approach for managing policies in Kubernetes.

Regards,

Jim

On Sun, Sep 27, 2020 at 2:10 AM Gareth Rushgrove <gareth@...> wrote:
+1 NB

I'm biased here, as one of the maintainers of the Conftest project
which is now part of OPA.

I wanted to address the point above about Rego.

I'm an unashamed DSL nerd. I was a user and contributor to Puppet and
then worked there. I was an early Docker user, gave talks about
Dockerfile and then worked at Docker. I originally built Conftest in
order to provide a better local developer experience to OPA because I
wanted to use Rego.

But, I'm also a fan of Chef. I spent last week putting together a
bunch of demos using Pulumi. I like general purpose programming
languages too.

Oh, and I like data as well. I contributed to Ansible. I wanted to
like Jsonnet, really like CUE, like aspects of YTT.

I can reason about the trade offs between these 3 different approaches
to configuration for what would be an unreasonable length of time for
most people. As a user and contributor I've been through a few
generations of tools in this space as a user and developer, and I
fully expect to see several more generations too. That's maddening to
some, and fun for me. I have strange hobbies.

The reality here is most end users have a strong preference for tools
in one of those groups at any given moment in time.
This isn't a new observation. It's worth reading the Configuration
Complexity Clock from back in 2012 as it's still as relevant here as
when it was written
https://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html

That is to say we'll likely see 3 distinct policy approaches over
time, one DSL, one data and one general purpose language.
In fact we already see projects like k-rail (using Go for authoring
policies https://github.com/cruise-automation/k-rail) and Kyverno
(using YAML for authoring https://github.com/nirmata/kyverno)

OPA today focuses on one of these approaches, my experience tells me
there will always be folks who prefer one of the others, and that's
fine. The CNCF shouldn't enforce one approach or another, but look at
usage.

The Open Policy Agent community in general has also been working on
lowering the barrier to learning Rego. The rego playground in
particular is invaluable https://play.openpolicyagent.org/. Rego
adoption has been growing rapidly, it's nature means most rego is
written behind private repos but
https://github.com/github/linguist/issues/4219 shows 296 rego files
publicly on GitHub in January 2019. Today there are more than 6000
https://github.com/search?utf8=%E2%9C%93&type=Code&ref=searchresults&q=extension%3Arego+package+NOT+nothack.
There has also been work done around sharing, so many end users can
use Open Policy Agent without needing to write rego. For instance we
were one of the first communities to define OCI Artifact metadata
(https://github.com/open-policy-agent/opa/issues/1413) which then
powers features like
https://aws.amazon.com/blogs/containers/oci-artifact-support-in-amazon-ecr/.

Hopefully that's a useful viewpoint and addition to the conversation.

Gareth






Re: OPA to graduation

Gareth Rushgrove
 

+1 NB

I'm biased here, as one of the maintainers of the Conftest project
which is now part of OPA.

I wanted to address the point above about Rego.

I'm an unashamed DSL nerd. I was a user and contributor to Puppet and
then worked there. I was an early Docker user, gave talks about
Dockerfile and then worked at Docker. I originally built Conftest in
order to provide a better local developer experience to OPA because I
wanted to use Rego.

But, I'm also a fan of Chef. I spent last week putting together a
bunch of demos using Pulumi. I like general purpose programming
languages too.

Oh, and I like data as well. I contributed to Ansible. I wanted to
like Jsonnet, really like CUE, like aspects of YTT.

I can reason about the trade offs between these 3 different approaches
to configuration for what would be an unreasonable length of time for
most people. As a user and contributor I've been through a few
generations of tools in this space as a user and developer, and I
fully expect to see several more generations too. That's maddening to
some, and fun for me. I have strange hobbies.

The reality here is most end users have a strong preference for tools
in one of those groups at any given moment in time.
This isn't a new observation. It's worth reading the Configuration
Complexity Clock from back in 2012 as it's still as relevant here as
when it was written
https://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html

That is to say we'll likely see 3 distinct policy approaches over
time, one DSL, one data and one general purpose language.
In fact we already see projects like k-rail (using Go for authoring
policies https://github.com/cruise-automation/k-rail) and Kyverno
(using YAML for authoring https://github.com/nirmata/kyverno)

OPA today focuses on one of these approaches, my experience tells me
there will always be folks who prefer one of the others, and that's
fine. The CNCF shouldn't enforce one approach or another, but look at
usage.

The Open Policy Agent community in general has also been working on
lowering the barrier to learning Rego. The rego playground in
particular is invaluable https://play.openpolicyagent.org/. Rego
adoption has been growing rapidly, it's nature means most rego is
written behind private repos but
https://github.com/github/linguist/issues/4219 shows 296 rego files
publicly on GitHub in January 2019. Today there are more than 6000
https://github.com/search?utf8=%E2%9C%93&type=Code&ref=searchresults&q=extension%3Arego+package+NOT+nothack.
There has also been work done around sharing, so many end users can
use Open Policy Agent without needing to write rego. For instance we
were one of the first communities to define OCI Artifact metadata
(https://github.com/open-policy-agent/opa/issues/1413) which then
powers features like
https://aws.amazon.com/blogs/containers/oci-artifact-support-in-amazon-ecr/.

Hopefully that's a useful viewpoint and addition to the conversation.

Gareth


Re: OPA to graduation

Gadi Naor
 

-1 NB 

The community around this project is great and there is a consensus on problem space.

Having the benefit of solving and working with customers on Kubernetes security compliance and authorization challenges for quite some time, and integrating OPA as part of our engine - I've witnessed unanimous feedback that OPA REGO has a steep learning curve, and high touch ongoing costs.

Nowadays with building blocks such as WASM, and motion around IaC that use real programming languages (Pulumi & CDK) I believe the ecosystem should strive to make the life of engineering teams easier, possibly in their comfort zone programming language (hey, Go, JS ... can work fine on documents) rather than introducing a new, none intuitive, high touch programming language.

Also, with regards to OPA applications such as Gatekeeper , Kafka Authorizer, conftest and others - Are those OPA applications proposed for graduation? 
Gatekeeper constraints and templates is gr8 - and I'd vote to graduate Gatekeeper with at least none REGO working PoC.

Gadi


On Sat, Sep 19, 2020 at 7:49 PM <nuhamind2@...> wrote:
I believe similar point about the core-project/heart-of-the-system maintainership is raised on the past graduation proposal



--
Gadi NaorCTO

US.   2443 Fillmore St, San Francisco, CA, 94115
IL.    5 Miconis St, Tel Aviv, 6777214   
M. +972-52-6618811
Web.      www.alcide.io
GitHub. github.com/alcideio

Follow us on LinkedInFollow us on Twitter 


Securing Kubernetes & Service Mesh.
Anywhere.
Bridging Security & DevOps.

Cloud Native Virtual Summit is October 6-8.    Register HERE





CNCF Awards now open for nominations

Amye Scavarda Perrin
 

We're starting the nomination process for our ambassador, committer and community awards.


  • CNCF Top Ambassador: A champion for the cloud native space, this individual helps spread awareness of the CNCF (and its incubated projects). The CNCF Ambassador leverages multiple platforms, both online as well as speaking engagements, driving interest and excitement around the project.

  • CNCF Top Committer: This will recognize excellence in technical contributions to CNCF and its projects. The CNCF Top Committer has made key commits to projects and, more importantly, contributes in a way that benefits the project neutrally as a whole.

  • CNCF Chop Wood Carry Water: This is given to a community member who helps behind the scenes, dedicating countless hours of their time to open source projects + completing often thankless tasks for the ecosystem’s benefit. The winner of this award will be chosen by the TOC and CNCF Staff.


Nominations will open today, and close on October 16nd. We'll be announcing the awards at KubeCon + CloudNativeCon Virtual North America. Voting (open from October 19 through October 26th) will be performed using the CIVS tool, using emails from the CNCF database for the following groups:

CNCF Ambassadors are eligible to vote for the Top Ambassador
CNCF Maintainers are eligible to vote for the Top Committer


--
Amye Scavarda Perrin | Program Manager | amye@...


Re: [SIG-Security] Nomination of Emily Fox as co-chair

Matt Klein
 

+1

On Mon, Sep 21, 2020 at 4:13 PM Jeyappragash Jeyakeerthi <jj@...> wrote:

Dear Technical Oversight Committee,


Dan Shaw’s term as co-chair of SIG-Security has come to an end.  We would like to nominate Emily Fox as a new co-chair of SIG-Security  (requiring a 2/3rd vote in compliance with the cncf-sig elections process). 


Following are some of Emily’s accomplishments 


Thanks!

JJ in collaboration with other   SIG-Security co-chairs (Dan and Sarah) and TOC Liaisons Liz Rice & Justin Cormack



Re: [SIG-Security] Nomination of Emily Fox as co-chair

Saad Ali
 

+1 binding

Thank you for volunteering!

501 - 520 of 5841