1. Cncf-Toc
  2. Messages

Expanded

Topics Messages Polls
   Date   
[VOTE] Open Policy Agent from incubating to graduated

Amye Scavarda Perrin
 

The Open Policy Agent project has applied for graduation from incubation to graduated. (https://github.com/cncf/toc/pull/520)

The due diligence document can be found here: https://docs.google.com/document/d/19M5fTpe57rQIMNxawRl5wSWvJUapuzY-CkV4O5pvieU/edit
 
Brendan Burns has called for public comment: https://lists.cncf.io/g/cncf-toc/message/5281

Please vote (+1/0/-1) by replying to this thread.

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

--
Amye Scavarda Perrin | Program Manager | amye@...
Re: "Steering committee" discussion

alexis richardson
 

Matt

Thanks. A few quick comments (topline for speed).

CNCF Incubation tests for production use and technical DD. It has a
high bar. Graduation is oriented towards sustainability including
some of the matters you touch on below. Graduation is more about
sustainability and governance, than about production use. Those are
all related in the end of course.

I am a big fan of regular Q&A surveys with maintainers and users "and
more". They are a good way to assess health, eg "do you think the
project will make more progress in the next 12mo than in the last
12mo? why", and "are you aware of any bad actors".

In terms of attracting contributors: complex topic, but the SC can
help by being a lighthouse showing many ways to get involved, by
showcasing what direction and features need building, and by having
clear contributor paths.

a

On Wed, Sep 30, 2020 at 8:16 AM Matt Wilson <msw@...> wrote:

On Tue, Sep 29, 2020 at 11:05 AM, Liz Rice wrote:

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)
The start of your original email was clear, but the addition of the
word "plan" did make it a bit less so. Thank you for the clarification!

I've taken the liberty to re-format the thread below to inline replies
from earlier messages. I hope that the context doesn't change the
meaning of any quoted text from others.

On Tue, 29 Sep 2020 at 18:52, Alexis Richardson <alexis@...> wrote:
On Tue, Sep 29, 2020 at 10:48 AM, Bob Wise (AWS) 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.
I (speaking only for myself) would like to understand the function
better. As I understand it, CNCF graduation is a signal that the project
has attained a certain level of "maturity". This is like a "Good
Housekeeping Seal of Approval" that gives users/customers a signal that
they can confidently adopt the software. Maintaining a high quality bar
for graduation is important in building the ongoing strong brand of the
CNCF, which I think plays a key role in supporting beneficial ecosystems
that are part of building and sustaining open-source software.

However, I currently view graduation milestones with the same kind of
skepticism of some engineering "qualification" practices I've seen,
where a product or service is very intensely tested before it is
released using tools and procedures that are not integrated into a
continuous automated testing system. "Qualification" around a major
milestone event gives you a snapshot-in-time view of quality, but modern
software changes more rapidly, so you need to be qualifying
continuously.

So too open-source projects need to change. Communities evolve.
Practices change and adapt. Communities that are not able to change and
evolve are more likely to become dysfunctional. Rather than obsessing
about if a vendor's interest is holding back features, I think you
should investigate how contentious decisions are made, and how disputes
are resolved among stakeholders. The roadmap/features is only one thing
that a development community, or other stakeholders, might disagree
about.

Liz clarified (above) that a proposed concern is to require functional
community control over the roadmap. I would shorten it: require a
functional community (in contrast to a dysfunctional community). I think
you (the CNCF TOC by applying the graduation seal-of-approval) need to
understand what community processes look like in practice, and if is a
healthy dynamic that aligns well with what we've learned so far about
building sustainable open-source software development communities and
commercial ecosystems. That'd be a hard job that I do not envy.

One tool that can help assess how well a community is functioning is a
free-form response template. But more deeply than how is it functioning,
a response template can help trigger, and demonstrate, more mindfulness
in community architecture. One I like is included in Python PIP-8002,
https://www.python.org/dev/peps/pep-8002/#annex-1-template-questions
I think that a well functioning community is one that has a process that
enables the evolution of its policies and practices over time. I like
that this template asks these questions:

3. How do you like the process?
* Which parts work well?
* Which parts could work better?
* When it doesn't work well, how does it look like?
* What would you change if it were only up to you?
[...]
5. Process evolution
* How did this process evolve historically?
* How can it be changed in the future?

The SC model could generate
* quarterly roadmap
* contributor ladder
* contingency plan
From my perspective, I care very little about any of these things
(though I may not understand what you actually mean). An open-source
license is my ultimate contingency plan. What I'm looking for otherwise
is a strong, welcoming, self-governing community, along with committed
companies participating in a growing commercial ecosystem around the
software.

Projects struggling to get maintainers when the owning entity is
unwilling to give up control to the community seems like a natural
consequence.
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.
Yes, there are a number of reasons why a project may not attract
contributors. There are a number of case studies where the overall
sentiment and perception was that an open-source project was too closely
held by a single commercial entity. Sometimes that has practical impacts
in the sustainability of the ecosystem that builds, maintains, and
supports the software.

In my opinion (biased from my experience and perspective), a key case
study in Linux Foundation history is the Xen project. We are fortunate
that the late Lars Kurth documented this case study well, see
http://slideshare.net/xen_com_mgr/lceu13-xen-project-lessons-learned.
When we formed the Xen Project as a Linux Foundation collaborative
project, there were a number of _symptoms_ that indicated that the
community, the project, and the ecosystem around it were trending toward
unhealthy. This was a sustainability concern for many stakeholders,
including me. Forming the Xen Project was only _part_ of addressing the
problem.

People who were most familiar with the Xen community were aware of some
the underlying causes of these symptoms, which were reflected in a
larger "image" problem for the project. Over many years the project and
its community gained a reputation of being difficult to work with,
inwardly focused, and not collaborative with other significant parts of
the open-source software ecosystem on which Xen was built--namely Linux
and QEMU, both of which were extensively modified and maintained as
separate "out of tree / not upstream" development branches for many
years. Some would call the software "forked".

At the time we formed the Xen Project at LF, it already had core
maintainers for multiple organizations, despite having earned a
reputation of being too closely held by Citrix. There are examples of
healthy projects with a small number of people from one organization
with "commit bit" access to the canonical repository, and also examples
of unhealthy projects that have people from multiple organizations with
"commit bit" access. So, I generally agree that the "multi-organization"
criterion is not a good one on its own. It _might_ be a symptom that
there's something else going on that deserves additional investigation.

So, TL;DR? Building a sustainable community is complex. The things that
may be the actual underlying risk factors in sustainability/longevity
may not be obvious in a surface level inspection. A plan is no guarantee
of future success. I think it takes applying mindful, intentional
community-building practices and a willingness to adapt.

--msw
Re: "Steering committee" discussion

Matt Wilson
 

On Tue, Sep 29, 2020 at 11:05 AM, Liz Rice wrote:

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)
The start of your original email was clear, but the addition of the
word "plan" did make it a bit less so. Thank you for the clarification!

I've taken the liberty to re-format the thread below to inline replies
from earlier messages. I hope that the context doesn't change the
meaning of any quoted text from others.

On Tue, 29 Sep 2020 at 18:52, Alexis Richardson <alexis@...> wrote:
On Tue, Sep 29, 2020 at 10:48 AM, Bob Wise (AWS) 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.
I (speaking only for myself) would like to understand the function
better. As I understand it, CNCF graduation is a signal that the project
has attained a certain level of "maturity". This is like a "Good
Housekeeping Seal of Approval" that gives users/customers a signal that
they can confidently adopt the software. Maintaining a high quality bar
for graduation is important in building the ongoing strong brand of the
CNCF, which I think plays a key role in supporting beneficial ecosystems
that are part of building and sustaining open-source software.

However, I currently view graduation milestones with the same kind of
skepticism of some engineering "qualification" practices I've seen,
where a product or service is very intensely tested before it is
released using tools and procedures that are not integrated into a
continuous automated testing system. "Qualification" around a major
milestone event gives you a snapshot-in-time view of quality, but modern
software changes more rapidly, so you need to be qualifying
continuously.

So too open-source projects need to change. Communities evolve.
Practices change and adapt. Communities that are not able to change and
evolve are more likely to become dysfunctional. Rather than obsessing
about if a vendor's interest is holding back features, I think you
should investigate how contentious decisions are made, and how disputes
are resolved among stakeholders. The roadmap/features is only one thing
that a development community, or other stakeholders, might disagree
about.

Liz clarified (above) that a proposed concern is to require functional
community control over the roadmap. I would shorten it: require a
functional community (in contrast to a dysfunctional community). I think
you (the CNCF TOC by applying the graduation seal-of-approval) need to
understand what community processes look like in practice, and if is a
healthy dynamic that aligns well with what we've learned so far about
building sustainable open-source software development communities and
commercial ecosystems. That'd be a hard job that I do not envy.

One tool that can help assess how well a community is functioning is a
free-form response template. But more deeply than how is it functioning,
a response template can help trigger, and demonstrate, more mindfulness
in community architecture. One I like is included in Python PIP-8002,
https://www.python.org/dev/peps/pep-8002/#annex-1-template-questions
I think that a well functioning community is one that has a process that
enables the evolution of its policies and practices over time. I like
that this template asks these questions:

3. How do you like the process?
* Which parts work well?
* Which parts could work better?
* When it doesn't work well, how does it look like?
* What would you change if it were only up to you?
[...]
5. Process evolution
* How did this process evolve historically?
* How can it be changed in the future?

The SC model could generate
* quarterly roadmap
* contributor ladder
* contingency plan
From my perspective, I care very little about any of these things
(though I may not understand what you actually mean). An open-source
license is my ultimate contingency plan. What I'm looking for otherwise
is a strong, welcoming, self-governing community, along with committed
companies participating in a growing commercial ecosystem around the
software.

Projects struggling to get maintainers when the owning entity is
unwilling to give up control to the community seems like a natural
consequence.
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.
Yes, there are a number of reasons why a project may not attract
contributors. There are a number of case studies where the overall
sentiment and perception was that an open-source project was too closely
held by a single commercial entity. Sometimes that has practical impacts
in the sustainability of the ecosystem that builds, maintains, and
supports the software.

In my opinion (biased from my experience and perspective), a key case
study in Linux Foundation history is the Xen project. We are fortunate
that the late Lars Kurth documented this case study well, see
http://slideshare.net/xen_com_mgr/lceu13-xen-project-lessons-learned.
When we formed the Xen Project as a Linux Foundation collaborative
project, there were a number of _symptoms_ that indicated that the
community, the project, and the ecosystem around it were trending toward
unhealthy. This was a sustainability concern for many stakeholders,
including me. Forming the Xen Project was only _part_ of addressing the
problem.

People who were most familiar with the Xen community were aware of some
the underlying causes of these symptoms, which were reflected in a
larger "image" problem for the project. Over many years the project and
its community gained a reputation of being difficult to work with,
inwardly focused, and not collaborative with other significant parts of
the open-source software ecosystem on which Xen was built--namely Linux
and QEMU, both of which were extensively modified and maintained as
separate "out of tree / not upstream" development branches for many
years. Some would call the software "forked".

At the time we formed the Xen Project at LF, it already had core
maintainers for multiple organizations, despite having earned a
reputation of being too closely held by Citrix. There are examples of
healthy projects with a small number of people from one organization
with "commit bit" access to the canonical repository, and also examples
of unhealthy projects that have people from multiple organizations with
"commit bit" access. So, I generally agree that the "multi-organization"
criterion is not a good one on its own. It _might_ be a symptom that
there's something else going on that deserves additional investigation.

So, TL;DR? Building a sustainable community is complex. The things that
may be the actual underlying risk factors in sustainability/longevity
may not be obvious in a surface level inspection. A plan is no guarantee
of future success. I think it takes applying mindful, intentional
community-building practices and a willingness to adapt.

--msw
Re: "Steering committee" discussion

Josh Berkus
 

On 9/29/20 10:43 AM, Liz Rice wrote:
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
We talked about requiring three things from projects reaching Graduated
level:

1. A sustainability/longevity plan
2. A process for community feedback on the roadmap
3. Requiring "contributor ladder" process & documentation

If these three things are things that the TOC plans to require,
SIG-Contributor Strategy can work on writing guidance for them. The
"longevity" portion will require quite a bit of work, though, because
there's no real precedent for this that I know of.

--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO
Re: FOSS Governance Library

Paris Pittman
 

we have been building this for our research and references for the guidance we are creating. the foss governance library is an amazing resource.  

On Tue, Sep 29, 2020 at 12:42 PM Chris Aniszczyk <caniszczyk@...> wrote:
Nothing outside of the PDF, but it's been on the TODO list to convert it to markdown and put it somewhere.

I'll look at getting this done though if people find it useful.

On Tue, Sep 29, 2020 at 2:39 PM Josh Berkus <jberkus@...> wrote:
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







--
Chris Aniszczyk (@cra) | +1-512-961-6719
Re: FOSS Governance Library

Chris Aniszczyk
 

Nothing outside of the PDF, but it's been on the TODO list to convert it to markdown and put it somewhere.

I'll look at getting this done though if people find it useful.

On Tue, Sep 29, 2020 at 2:39 PM Josh Berkus <jberkus@...> wrote:
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



--
Chris Aniszczyk (@cra) | +1-512-961-6719
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@...> 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

lf_determiningopenness_ebook_071519.pdf

lf_determiningopenness_ebook_071519.pdf

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@...




signature.asc

signature.asc

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

Amye Scavarda Perrin
 

2681 - 2700 of 8027