1. cncf-toc@lists.cncf.io
  2. Messages
   Date   
[VOTE] rkt archiving

Chris Aniszczyk
 

Hey all, I'd like to formally call the vote to archive the rkt project based on our previous multiple discussions on this topic across a few TOC meetings.

Please vote (+1/0/-1) by replying to this thread; the full proposal located here: https://github.com/cncf/toc/pull/262

This is our first project we are archiving based on our new process so I want to be diligent and take the extra time, on top of explaining what archiving means for a project: https://github.com/cncf/toc/blob/master/process/archiving.md

- CNCF will no longer provide support for the project via service desk
- CNCF will list archived projects online
- Trademarks and domain names of archived projects are still hosted neutrally by the CNCF and the Linux Foundation
- CNCF can provide services such as documentation updates to help transition users.
- Other CNCF marketing activities will no longer be provided for the project (like space at conferences)

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community.

--
Chris Aniszczyk (@cra) | +1-512-961-6719
Draft of Application Delivery SIG Charter available

Reitbauer, Alois <alois.reitbauer@...>
 

The first draft of the application delivery SIG charter is available here [1]. We ask everyone on the mailing list as well as the TOC for feedback.

 

Please let us know as well if you want us to schedule a call with the TOC to discuss the charter and related activities of the application delivery SIG.

 

 

// Alois

 

 

[1] https://docs.google.com/document/d/1PpHh9D1rE7efR4mX_ClQC1V_piCiP5KMgCpbJp3zMDw/edit?pli=1#

 

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4040 Linz, Austria, Freistädterstraße 313

Re: Bias and publishing guidance from CNCF

alexis richardson
 

+1 for "review", +1 for learning from ACM & academia

I still think we cannot pretend to be unbiased. Even algos are biased.

On Thu, Aug 1, 2019 at 2:27 PM Matt Farina <matt@...> wrote:

Thanks for kicking off this thread, Gareth.

I'm reminded of a couple things when it comes to attribution and bias:

Academic and society papers (e.g., ACM) have author attribution including institution. The ACM template goes so far as to include the department. https://www.acm.org/publications/proceedings-template
In journalistic publications associations and their context are documented. Whether they are the reporters (e.g., they have shares in a company they are writing about) or even those of the publication they are writing for (e.g., the publications parent company owns who they are writing about).


I would hope we have a review process for any documentation being produced. We review PRs, editors review books and papers, and we should have a documented process for reviewing documentation produced by the TOC/SIGs.

Would a template for these papers make sense with a template section on the authors leading or requiring them to disclose their organizations be useful?

I know the apps space has A LOT of projects, products, and companies. I've seen numerous people share different ideas of what they think should be in it. Some are looking for any little thing that can be a competitive advantage to differentiate themselves. I would suggest a good process to look out for the best interest of the end users while attempting to limit bias or at least disclose it well.

- Matt Farina

On Thu, Aug 1, 2019, at 8:49 AM, Liz Rice wrote:

Agreed, this is an important point, and good to expose to sunlight.

I like Alexis’ authorship statements and the point about listing authors and their affiliations.

Sometimes people’s biases might not even be obvious to their co-collaborators, so I think it would be appropriate to have some explicit guidelines that individuals are expected to flag up when they have a COI.

For example if a SIG is doing an assessment on project X, contributors might explicitly say

“project X competes with project Y that I’m a maintainer of / I have contributed substantially to ” or
“project X is potentially competitive with a product from my company”.

And then

“as a result I don’t think it’s appropriate for me to take part in this assessment” or
“as a result I am knowledgeable in the area, so I’d like to contribute, but please flag if you think my biases are showing”


Liz
On 1 Aug 2019, 11:44 +0100, Sarah Allen <sarah@...>, wrote:

Thanks for raising this Gareth. This is an open issue for SIG Security where we have a growing number of individuals participating in assessments and an open issue to write up guidelines: https://github.com/cncf/sig-security/issues/156

Having guidance from the TOC would be very helpful to be able to reference, and I've written up a TOC issue here:
https://github.com/cncf/toc/issues/270

Sarah Allen
SIG-Security co-chair

On Thu, Aug 1, 2019 at 4:58 AM alexis richardson <alexis@...> wrote:

Thanks for posting this Gareth.

IMO it is better to be open about bias than to pretend it away.

We could state that documents coming from CNCF TOC & SIGs are marked
as "Authored by members of the CNCF community", and list all
contributors and affiliations. This would be in contrast to documents
commissioned by the CNCF organisation which are published as official
CNCF docs, authored by the CNCF staff.






On Thu, Aug 1, 2019 at 9:22 AM Gareth Rushgrove
<gareth@...> wrote:

Hi All

On a couple of calls yesterday (SIG Security, and discussions about
the proposed SIG App Delivery), the topic of bias or conflict of
interest came up. In discussion we thought it worth bringing to the
ToC, so here is an email.

One of the things being discussed as part of the SIG App Delivery
mission is "develop informational resources like guides, tutorials and
white papers". SIG Security produces recommendations for projects and
the ToC and is also looking at guidance. I'm sure other SIGs have in
mind to do something similar.

Part of the power of CNCF is it's a shared place for folks to
genuinely work together. But I don't think we should deny or otherwise
hide our bias, especially as we get into CNCF branded and published
material. I think most people want to do the right thing, but having
some guidance and discussion would help. Consider a few of the
following:

1. Conducting a private security review of a product associated with a
competitor
2. Guidance on <CNCF project> and <Cloud provider> written by <Cloud provider>
3. Tutorial on <CNCF project> which mentions <non-CNCF project>
4. Comparisons of <CNCF projects> and <non-CNCF projects>
5. Guidance on <CNCF project> which competes with <other CNCF project>
6. Guidance on <CNCF project> which competes with <non-CNCF project>
associated with <authors employee>
7. Organising a <CNCF branded event> which competes directly with
<CNCF member> event

Non of these are simply good or bad, context always matters. A few
things that could be discussed (not concrete suggestions, more to
start a conversation.)

1. All guidance carries authors and contributors and their affiliations
2. Contributors sign some impartiality document (social more than legal)
3. Clear review process which explicitly takes in bias
4. No single-vendor content attributed to CNCF

I think the ToC are probably _very_ aware of this sort of thing, but
as CNCF SIGs expand, more folks probably need to consider the same
things. I think CNCF affiliation is different from project
affiliation. Doing that collectively would be good. What processes do
we need in place? And are they SIG specific or more general? Is this
something folks care about?

Thanks

Gareth

--
Gareth Rushgrove
@garethr

devopsweekly.com
morethanseven.net
garethrushgrove.com
Re: Bias and publishing guidance from CNCF

Matt Farina
 

Thanks for kicking off this thread, Gareth.

I'm reminded of a couple things when it comes to attribution and bias:
  • Academic and society papers (e.g., ACM) have author attribution including institution. The ACM template goes so far as to include the department. https://www.acm.org/publications/proceedings-template
  • In journalistic publications associations and their context are documented. Whether they are the reporters (e.g., they have shares in a company they are writing about) or even those of the publication they are writing for (e.g., the publications parent company owns who they are writing about).

I would hope we have a review process for any documentation being produced. We review PRs, editors review books and papers, and we should have a documented process for reviewing documentation produced by the TOC/SIGs.

Would a template for these papers make sense with a template section on the authors leading or requiring them to disclose their organizations be useful?

I know the apps space has A LOT of projects, products, and companies. I've seen numerous people share different ideas of what they think should be in it. Some are looking for any little thing that can be a competitive advantage to differentiate themselves. I would suggest a good process to look out for the best interest of the end users while attempting to limit bias or at least disclose it well.

- Matt Farina

On Thu, Aug 1, 2019, at 8:49 AM, Liz Rice wrote:
Agreed, this is an important point, and good to expose to sunlight. 

I like Alexis’ authorship statements and the point about listing authors and their affiliations. 

Sometimes people’s biases might not even be obvious to their co-collaborators, so I think it would be appropriate to have some explicit guidelines that individuals are expected to flag up when they have a COI. 

For example if a SIG is doing an assessment on project X, contributors might explicitly say 
  • “project X competes with project Y that I’m a maintainer of / I have contributed substantially to ” or 
  • “project X is potentially competitive with a product from my company”. 
And then
  • “as a result I don’t think it’s appropriate for me to take part in this assessment” or
  • “as a result I am knowledgeable in the area, so I’d like to contribute, but please flag if you think my biases are showing”

Liz
On 1 Aug 2019, 11:44 +0100, Sarah Allen <sarah@...>, wrote:

Thanks for raising this Gareth.  This is an open issue for SIG Security where we have a growing number of individuals participating in assessments and an open issue to write up guidelines: https://github.com/cncf/sig-security/issues/156

Having guidance from the TOC would be very helpful to be able to reference, and I've written up a TOC issue here:

Sarah Allen
SIG-Security co-chair

On Thu, Aug 1, 2019 at 4:58 AM alexis richardson <alexis@...> wrote:
Thanks for posting this Gareth.

IMO it is better to be open about bias than to pretend it away.

We could state that documents coming from CNCF TOC & SIGs are marked
as "Authored by members of the CNCF community", and list all
contributors and affiliations.  This would be in contrast to documents
commissioned by the CNCF organisation which are published as official
CNCF docs, authored by the CNCF staff.






On Thu, Aug 1, 2019 at 9:22 AM Gareth Rushgrove
<gareth@...> wrote:
>
> Hi All
>
> On a couple of calls yesterday (SIG Security, and discussions about
> the proposed SIG App Delivery), the topic of bias or conflict of
> interest came up. In discussion we thought it worth bringing to the
> ToC, so here is an email.
>
> One of the things being discussed as part of the SIG App Delivery
> mission is "develop informational resources like guides, tutorials and
> white papers". SIG Security produces recommendations for projects and
> the ToC and is also looking at guidance. I'm sure other SIGs have in
> mind to do something similar.
>
> Part of the power of CNCF is it's a shared place for folks to
> genuinely work together. But I don't think we should deny or otherwise
> hide our bias, especially as we get into CNCF branded and published
> material. I think most people want to do the right thing, but having
> some guidance and discussion would help. Consider a few of the
> following:
>
> 1. Conducting a private security review of a product associated with a
> competitor
> 2. Guidance on <CNCF project> and <Cloud provider> written by <Cloud provider>
> 3. Tutorial on <CNCF project> which mentions <non-CNCF project>
> 4. Comparisons of <CNCF projects> and <non-CNCF projects>
> 5. Guidance on <CNCF project> which competes with <other CNCF project>
> 6. Guidance on <CNCF project> which competes with <non-CNCF project>
> associated with <authors employee>
> 7. Organising a <CNCF branded event> which competes directly with
> <CNCF member> event
>
> Non of these are simply good or bad, context always matters. A few
> things that could be discussed (not concrete suggestions, more to
> start a conversation.)
>
> 1. All guidance carries authors and contributors and their affiliations
> 2. Contributors sign some impartiality document (social more than legal)
> 3. Clear review process which explicitly takes in bias
> 4. No single-vendor content attributed to CNCF
>
> I think the ToC are probably _very_ aware of this sort of thing, but
> as CNCF SIGs expand, more folks probably need to consider the same
> things. I think CNCF affiliation is different from project
> affiliation. Doing that collectively would be good. What processes do
> we need in place? And are they SIG specific or more general? Is this
> something folks care about?
>
> Thanks
>
> Gareth
>
> --
> Gareth Rushgrove
> @garethr
>
>
>
>
Re: Bias and publishing guidance from CNCF

Liz Rice
 

Agreed, this is an important point, and good to expose to sunlight. 

I like Alexis’ authorship statements and the point about listing authors and their affiliations. 

Sometimes people’s biases might not even be obvious to their co-collaborators, so I think it would be appropriate to have some explicit guidelines that individuals are expected to flag up when they have a COI. 

For example if a SIG is doing an assessment on project X, contributors might explicitly say 
  • “project X competes with project Y that I’m a maintainer of / I have contributed substantially to ” or 
  • “project X is potentially competitive with a product from my company”. 
And then
  • “as a result I don’t think it’s appropriate for me to take part in this assessment” or
  • “as a result I am knowledgeable in the area, so I’d like to contribute, but please flag if you think my biases are showing”

Liz
On 1 Aug 2019, 11:44 +0100, Sarah Allen <sarah@...>, wrote:

Thanks for raising this Gareth.  This is an open issue for SIG Security where we have a growing number of individuals participating in assessments and an open issue to write up guidelines: https://github.com/cncf/sig-security/issues/156

Having guidance from the TOC would be very helpful to be able to reference, and I've written up a TOC issue here:

Sarah Allen
SIG-Security co-chair

On Thu, Aug 1, 2019 at 4:58 AM alexis richardson <alexis@...> wrote:
Thanks for posting this Gareth.

IMO it is better to be open about bias than to pretend it away.

We could state that documents coming from CNCF TOC & SIGs are marked
as "Authored by members of the CNCF community", and list all
contributors and affiliations.  This would be in contrast to documents
commissioned by the CNCF organisation which are published as official
CNCF docs, authored by the CNCF staff.






On Thu, Aug 1, 2019 at 9:22 AM Gareth Rushgrove
<gareth@...> wrote:
>
> Hi All
>
> On a couple of calls yesterday (SIG Security, and discussions about
> the proposed SIG App Delivery), the topic of bias or conflict of
> interest came up. In discussion we thought it worth bringing to the
> ToC, so here is an email.
>
> One of the things being discussed as part of the SIG App Delivery
> mission is "develop informational resources like guides, tutorials and
> white papers". SIG Security produces recommendations for projects and
> the ToC and is also looking at guidance. I'm sure other SIGs have in
> mind to do something similar.
>
> Part of the power of CNCF is it's a shared place for folks to
> genuinely work together. But I don't think we should deny or otherwise
> hide our bias, especially as we get into CNCF branded and published
> material. I think most people want to do the right thing, but having
> some guidance and discussion would help. Consider a few of the
> following:
>
> 1. Conducting a private security review of a product associated with a
> competitor
> 2. Guidance on <CNCF project> and <Cloud provider> written by <Cloud provider>
> 3. Tutorial on <CNCF project> which mentions <non-CNCF project>
> 4. Comparisons of <CNCF projects> and <non-CNCF projects>
> 5. Guidance on <CNCF project> which competes with <other CNCF project>
> 6. Guidance on <CNCF project> which competes with <non-CNCF project>
> associated with <authors employee>
> 7. Organising a <CNCF branded event> which competes directly with
> <CNCF member> event
>
> Non of these are simply good or bad, context always matters. A few
> things that could be discussed (not concrete suggestions, more to
> start a conversation.)
>
> 1. All guidance carries authors and contributors and their affiliations
> 2. Contributors sign some impartiality document (social more than legal)
> 3. Clear review process which explicitly takes in bias
> 4. No single-vendor content attributed to CNCF
>
> I think the ToC are probably _very_ aware of this sort of thing, but
> as CNCF SIGs expand, more folks probably need to consider the same
> things. I think CNCF affiliation is different from project
> affiliation. Doing that collectively would be good. What processes do
> we need in place? And are they SIG specific or more general? Is this
> something folks care about?
>
> Thanks
>
> Gareth
>
> --
> Gareth Rushgrove
> @garethr
>
> devopsweekly.com
> morethanseven.net
> garethrushgrove.com
>
>
>
Re: Bias and publishing guidance from CNCF

Sarah Allen
 

Thanks for raising this Gareth.  This is an open issue for SIG Security where we have a growing number of individuals participating in assessments and an open issue to write up guidelines: https://github.com/cncf/sig-security/issues/156

Having guidance from the TOC would be very helpful to be able to reference, and I've written up a TOC issue here:

Sarah Allen
SIG-Security co-chair

On Thu, Aug 1, 2019 at 4:58 AM alexis richardson <alexis@...> wrote:
Thanks for posting this Gareth.

IMO it is better to be open about bias than to pretend it away.

We could state that documents coming from CNCF TOC & SIGs are marked
as "Authored by members of the CNCF community", and list all
contributors and affiliations.  This would be in contrast to documents
commissioned by the CNCF organisation which are published as official
CNCF docs, authored by the CNCF staff.






On Thu, Aug 1, 2019 at 9:22 AM Gareth Rushgrove
<gareth@...> wrote:
>
> Hi All
>
> On a couple of calls yesterday (SIG Security, and discussions about
> the proposed SIG App Delivery), the topic of bias or conflict of
> interest came up. In discussion we thought it worth bringing to the
> ToC, so here is an email.
>
> One of the things being discussed as part of the SIG App Delivery
> mission is "develop informational resources like guides, tutorials and
> white papers". SIG Security produces recommendations for projects and
> the ToC and is also looking at guidance. I'm sure other SIGs have in
> mind to do something similar.
>
> Part of the power of CNCF is it's a shared place for folks to
> genuinely work together. But I don't think we should deny or otherwise
> hide our bias, especially as we get into CNCF branded and published
> material. I think most people want to do the right thing, but having
> some guidance and discussion would help. Consider a few of the
> following:
>
> 1. Conducting a private security review of a product associated with a
> competitor
> 2. Guidance on <CNCF project> and <Cloud provider> written by <Cloud provider>
> 3. Tutorial on <CNCF project> which mentions <non-CNCF project>
> 4. Comparisons of <CNCF projects> and <non-CNCF projects>
> 5. Guidance on <CNCF project> which competes with <other CNCF project>
> 6. Guidance on <CNCF project> which competes with <non-CNCF project>
> associated with <authors employee>
> 7. Organising a <CNCF branded event> which competes directly with
> <CNCF member> event
>
> Non of these are simply good or bad, context always matters. A few
> things that could be discussed (not concrete suggestions, more to
> start a conversation.)
>
> 1. All guidance carries authors and contributors and their affiliations
> 2. Contributors sign some impartiality document (social more than legal)
> 3. Clear review process which explicitly takes in bias
> 4. No single-vendor content attributed to CNCF
>
> I think the ToC are probably _very_ aware of this sort of thing, but
> as CNCF SIGs expand, more folks probably need to consider the same
> things. I think CNCF affiliation is different from project
> affiliation. Doing that collectively would be good. What processes do
> we need in place? And are they SIG specific or more general? Is this
> something folks care about?
>
> Thanks
>
> Gareth
>
> --
> Gareth Rushgrove
> @garethr
>
> devopsweekly.com
> morethanseven.net
> garethrushgrove.com
>
>
>
Re: Bias and publishing guidance from CNCF

alexis richardson
 

Thanks for posting this Gareth.

IMO it is better to be open about bias than to pretend it away.

We could state that documents coming from CNCF TOC & SIGs are marked
as "Authored by members of the CNCF community", and list all
contributors and affiliations. This would be in contrast to documents
commissioned by the CNCF organisation which are published as official
CNCF docs, authored by the CNCF staff.






On Thu, Aug 1, 2019 at 9:22 AM Gareth Rushgrove
<gareth@...> wrote:

Hi All

On a couple of calls yesterday (SIG Security, and discussions about
the proposed SIG App Delivery), the topic of bias or conflict of
interest came up. In discussion we thought it worth bringing to the
ToC, so here is an email.

One of the things being discussed as part of the SIG App Delivery
mission is "develop informational resources like guides, tutorials and
white papers". SIG Security produces recommendations for projects and
the ToC and is also looking at guidance. I'm sure other SIGs have in
mind to do something similar.

Part of the power of CNCF is it's a shared place for folks to
genuinely work together. But I don't think we should deny or otherwise
hide our bias, especially as we get into CNCF branded and published
material. I think most people want to do the right thing, but having
some guidance and discussion would help. Consider a few of the
following:

1. Conducting a private security review of a product associated with a
competitor
2. Guidance on <CNCF project> and <Cloud provider> written by <Cloud provider>
3. Tutorial on <CNCF project> which mentions <non-CNCF project>
4. Comparisons of <CNCF projects> and <non-CNCF projects>
5. Guidance on <CNCF project> which competes with <other CNCF project>
6. Guidance on <CNCF project> which competes with <non-CNCF project>
associated with <authors employee>
7. Organising a <CNCF branded event> which competes directly with
<CNCF member> event

Non of these are simply good or bad, context always matters. A few
things that could be discussed (not concrete suggestions, more to
start a conversation.)

1. All guidance carries authors and contributors and their affiliations
2. Contributors sign some impartiality document (social more than legal)
3. Clear review process which explicitly takes in bias
4. No single-vendor content attributed to CNCF

I think the ToC are probably _very_ aware of this sort of thing, but
as CNCF SIGs expand, more folks probably need to consider the same
things. I think CNCF affiliation is different from project
affiliation. Doing that collectively would be good. What processes do
we need in place? And are they SIG specific or more general? Is this
something folks care about?

Thanks

Gareth

--
Gareth Rushgrove
@garethr

devopsweekly.com
morethanseven.net
garethrushgrove.com
Bias and publishing guidance from CNCF

Gareth Rushgrove
 

Hi All

On a couple of calls yesterday (SIG Security, and discussions about
the proposed SIG App Delivery), the topic of bias or conflict of
interest came up. In discussion we thought it worth bringing to the
ToC, so here is an email.

One of the things being discussed as part of the SIG App Delivery
mission is "develop informational resources like guides, tutorials and
white papers". SIG Security produces recommendations for projects and
the ToC and is also looking at guidance. I'm sure other SIGs have in
mind to do something similar.

Part of the power of CNCF is it's a shared place for folks to
genuinely work together. But I don't think we should deny or otherwise
hide our bias, especially as we get into CNCF branded and published
material. I think most people want to do the right thing, but having
some guidance and discussion would help. Consider a few of the
following:

1. Conducting a private security review of a product associated with a
competitor
2. Guidance on <CNCF project> and <Cloud provider> written by <Cloud provider>
3. Tutorial on <CNCF project> which mentions <non-CNCF project>
4. Comparisons of <CNCF projects> and <non-CNCF projects>
5. Guidance on <CNCF project> which competes with <other CNCF project>
6. Guidance on <CNCF project> which competes with <non-CNCF project>
associated with <authors employee>
7. Organising a <CNCF branded event> which competes directly with
<CNCF member> event

Non of these are simply good or bad, context always matters. A few
things that could be discussed (not concrete suggestions, more to
start a conversation.)

1. All guidance carries authors and contributors and their affiliations
2. Contributors sign some impartiality document (social more than legal)
3. Clear review process which explicitly takes in bias
4. No single-vendor content attributed to CNCF

I think the ToC are probably _very_ aware of this sort of thing, but
as CNCF SIGs expand, more folks probably need to consider the same
things. I think CNCF affiliation is different from project
affiliation. Doing that collectively would be good. What processes do
we need in place? And are they SIG specific or more general? Is this
something folks care about?

Thanks

Gareth

--
Gareth Rushgrove
@garethr

devopsweekly.com
morethanseven.net
garethrushgrove.com
[cncf-enduser] Call for sponsors and speakers: Helm Summit, PromCon, EnvoyCon, and 4 other KubeCon Day 0 events

Chris Aniszczyk
 

FYI for prospectuses around CNCF project related events for organizations that are interested

---------- Forwarded message ---------
From: Dan Kohn <dan@...>
Date: Mon, Jul 29, 2019 at 11:04 AM
Subject: [cncf-enduser] Call for sponsors and speakers: Helm Summit, PromCon, EnvoyCon, and 4 other KubeCon Day 0 events
To: Dan Kohn <dan@...>
Cc: sponsor <sponsor@...>


CNCF is helping to organize 7 project-specific events: Helm Summit (Amsterdam, September 11-12), PromCon (Munich, November 7-8), EnvoyCon, ServiceMeshCon, Observability Practictioners Summit, FoundationDB Summit, and Cloud Native Security Day. The latter 5 are KubeCon + CloudNativeCon Day 0 co-located events, taking place in San Diego on November 18.


To ensure the success of these invaluable events, I’m asking for your help. 


First, sponsorship helps us bring these events to the developers, architects, and technical leaders in the industry. It gets your company in front of this audience. You can download the comprehensive prospectus for details (and it’s attached) and see page 10 for a summary. Please followup to sponsor@... or schedule a call with Kathy to discuss sponsorship opportunities.  


Second, the CFPs for four of these events are still open. Please encourage your team to apply. Below is a summary of the opportunities:


Helm Summit - September 11-12 in Amsterdam  

Sold out last year with 300 attendees and is expected to sell out again this year. Diamond ($15k + 5min keynote) and Platinum ($10k) sponsorships are available. Deadline to sponsor is August 12. 


PromCon - November 7-8 in Munich

Expected to have 200+ attendees. Diamond ($11k), Gold ($3,250), Silver ($1,250), Social, and Diversity sponsorships available. The CFP closes July 31. Deadline to sponsor is October 4.


KubeCon + CloudNativeCon San Diego Day 0 Co-located Events held on November 18: 


EnvoyCon 

Had over 350 attendees last year. Diamond ($20k + 5min speaking opp), Platinum ($15k), Gold ($10k), Silver ($5k), Social, and Diversity sponsorships are available. Deadline to sponsor is September 20.


ServiceMeshCon

ServiceMeshCon is a new event this year. We are anticipating 200 attendees. Diamond (sold out), Platinum ($10k), and Gold ($5k) sponsorships are available. The CFP closes August 30. Deadline to sponsor is September 20.


Observability Practitioners Summit - covering OpenTelemetry/OpenTracing, Prometheus, and Fluentd

There were 220 attendees last year and we are expecting 600 this year. Diamond ($25k + 10min lightning talk), Platinum ($15k), and Gold ($10k) sponsorships available. The CFP closes August 30. Deadline to sponsor is September 20.


Cloud Native Security Day

Cloud Native Security Day is a new event this year. We are anticipating 100 attendees. The sessions are being curated by the CNCF Security SIG.  Diamond ($20k + 5min keynote), Platinum ($15k), and Gold ($10k) sponsorships available. Deadline to sponsor is September 20.


As always, I appreciate your support and involvement in CNCF-organized events. 

--
Dan Kohn <dan@...>
Executive Director, Cloud Native Computing Foundation https://www.cncf.io
+1-415-233-1000 https://www.dankohn.com



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

PDF
sponsor-cncf-20190729.pdf

CNCF TOC Project Presentation Meeting Schedule Change

Taylor Waggoner
 

Hi everyone,

The TOC Project Presentation meetings will now be held on the 3rd Tuesday of the month instead of the 2nd Tuesday.  We have updated the meeting invitation to reflect this change.

Please let me know if there are any questions.

Thank you,

Taylor Waggoner
Sr. Operations Analyst  - Cloud Native Computing Foundation
Location & Time-zone: Portland, OR - PT
web: https://www.cncf.io/
email:  twaggoner@...

TOC meeting notes

Liz Rice
 

Hi everyone, 

We held a closed TOC meeting this week and made progress on the project proposal backlog. The meeting notes are now added to the working doc.

Liz 
Re: RFC: Thanos/KubeVirt/In-Toto

Richard Hartmann
 

Three cheers for Thanos!

On Tue, Jul 9, 2019 at 6:48 PM Chris Aniszczyk
<caniszczyk@...> wrote:

Hey all, we had three project proposal presentations from the community today:

https://docs.google.com/presentation/d/1jhzJlSAAJNNil1nIYp60eSMH3LPd6AwqHLt3vEAzMSg/edit#slide=id.g25ca91f87f_0_0

Thanos (sandbox): https://github.com/cncf/toc/pull/256
KubeVirt (sandbox): https://github.com/cncf/toc/pull/265
In-toto (incubation): https://github.com/cncf/toc/pull/252

Please feel free to make any comments+questions as adopters/users to the PRs. We are tracking the progress of the projects through sponsorship/voting here: https://github.com/cncf/toc/projects/3

--
Chris Aniszczyk (@cra) | +1-512-961-6719
Re: RFC: Thanos/KubeVirt/In-Toto

Joe Beda <jbeda@...>
 

For the record, I volunteered to sponsor also during the meeting.

On 7/9/19, 9:50 AM, "cncf-toc@... on behalf of alexis richardson" <cncf-toc@... on behalf of alexis@...> wrote:

I am happy to sponsor Thanos for CNCF Sandbox.

On Tue, Jul 9, 2019 at 5:48 PM Chris Aniszczyk
<caniszczyk@...> wrote:
>
> Hey all, we had three project proposal presentations from the community today:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fpresentation%2Fd%2F1jhzJlSAAJNNil1nIYp60eSMH3LPd6AwqHLt3vEAzMSg%2Fedit%23slide%3Did.g25ca91f87f_0_0&;data=02%7C01%7Cjbeda%40vmware.com%7C8cfb6b53c458456ffae608d7048d9209%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636982878427024201&amp;sdata=pDwv0EEriOKjih3uvG8LzNmF8RFhQ5ltwsKFNWLxQ3I%3D&amp;reserved=0
>
> Thanos (sandbox): https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcncf%2Ftoc%2Fpull%2F256&;data=02%7C01%7Cjbeda%40vmware.com%7C8cfb6b53c458456ffae608d7048d9209%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636982878427024201&amp;sdata=YyiH%2BCyKPRYuYyFW4TElxTRZzvONHQivAmycw0QbE%2BU%3D&amp;reserved=0
> KubeVirt (sandbox): https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcncf%2Ftoc%2Fpull%2F265&;data=02%7C01%7Cjbeda%40vmware.com%7C8cfb6b53c458456ffae608d7048d9209%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636982878427034211&amp;sdata=M6Le%2BJbM8JwdNAuVZ2xGfEFljj9EtugDGeuoPjv%2FExI%3D&amp;reserved=0
> In-toto (incubation): https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcncf%2Ftoc%2Fpull%2F252&;data=02%7C01%7Cjbeda%40vmware.com%7C8cfb6b53c458456ffae608d7048d9209%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636982878427034211&amp;sdata=CRVXZRQFGe8L2TJwcpV0JDx4zU0mbYhQwBn%2B6xFHwW4%3D&amp;reserved=0
>
> Please feel free to make any comments+questions as adopters/users to the PRs. We are tracking the progress of the projects through sponsorship/voting here: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcncf%2Ftoc%2Fprojects%2F3&;data=02%7C01%7Cjbeda%40vmware.com%7C8cfb6b53c458456ffae608d7048d9209%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636982878427034211&amp;sdata=tvbhVNVfXnTta4FHOD%2FZzluUVv1MtOfIMncJInscZ0c%3D&amp;reserved=0
>
> --
> Chris Aniszczyk (@cra) | +1-512-961-6719
>
Re: RFC: Thanos/KubeVirt/In-Toto

alexis richardson
 

I am happy to sponsor Thanos for CNCF Sandbox.

On Tue, Jul 9, 2019 at 5:48 PM Chris Aniszczyk
<caniszczyk@...> wrote:

Hey all, we had three project proposal presentations from the community today:

https://docs.google.com/presentation/d/1jhzJlSAAJNNil1nIYp60eSMH3LPd6AwqHLt3vEAzMSg/edit#slide=id.g25ca91f87f_0_0

Thanos (sandbox): https://github.com/cncf/toc/pull/256
KubeVirt (sandbox): https://github.com/cncf/toc/pull/265
In-toto (incubation): https://github.com/cncf/toc/pull/252

Please feel free to make any comments+questions as adopters/users to the PRs. We are tracking the progress of the projects through sponsorship/voting here: https://github.com/cncf/toc/projects/3

--
Chris Aniszczyk (@cra) | +1-512-961-6719
RFC: Thanos/KubeVirt/In-Toto

Chris Aniszczyk
 

Hey all, we had three project proposal presentations from the community today:

https://docs.google.com/presentation/d/1jhzJlSAAJNNil1nIYp60eSMH3LPd6AwqHLt3vEAzMSg/edit#slide=id.g25ca91f87f_0_0


Please feel free to make any comments+questions as adopters/users to the PRs. We are tracking the progress of the projects through sponsorship/voting here: https://github.com/cncf/toc/projects/3

--
Chris Aniszczyk (@cra) | +1-512-961-6719
TOC Agenda for 7/9/2019

Chris Aniszczyk
 

Hey all, the agenda for tomorrow's community presentation meeting is here:


We will be hearing from the kubevirt, in-toto and thanos projects.

See you tomorrow!

--
Chris Aniszczyk (@cra) | +1-512-961-6719
Re: Project Process flow chart....

Alex Chircop
 

Hi,

Further to this thread, the CNCF Storage SIG has been prepping a simple questionnaire:


The idea was to provide a baseline that would help a project to prepare for a presentation to the SIG, and then helps the SIG share the collated information with the TOC.

All feedback and comments would be appreciated!

Kind Regards,
Alex


From: cncf-toc@... <cncf-toc@...> on behalf of Brendan Burns via Lists.Cncf.Io <bburns=microsoft.com@...>
Sent: 05 July 2019 21:41
To: CNCF TOC
Cc: cncf-toc@...
Subject: [cncf-toc] Project Process flow chart....
 
Folks,
I'm quite tardy, but I created the proposed flow-chart for the project adoption process as discussed 2 meetings ago:


Comments please!

Thanks
--brendan
Re: Project Process flow chart....

Eduardo Silva
 

Hi, 

I would suggest the workflow states that the project must exist and have a minimum of adoption, otherwise, it could lead to "elevator pitch" to validate ideas.



On Fri, Jul 5, 2019 at 2:42 PM Brendan Burns via Lists.Cncf.Io <bburns=microsoft.com@...> wrote:
Folks,
I'm quite tardy, but I created the proposed flow-chart for the project adoption process as discussed 2 meetings ago:


Comments please!

Thanks
--brendan




--

Eduardo Silva
Principal Engineer  | Arm
. . . . . . . . . . . . . . . . . . . . . . . . . . . 
m. +506 70138007
Arm.com
Treasuredata.com


   
Project Process flow chart....

Brendan Burns
 

Folks,
I'm quite tardy, but I created the proposed flow-chart for the project adoption process as discussed 2 meetings ago:


Comments please!

Thanks
--brendan
CFP Reminder for KubeCon + CloudNativeCon NA (closes July 12th)

Chris Aniszczyk
 

Just a friendly reminder that the CFP for KubeCon + CloudNativeCon NA closes soon:

Please get your submissions in by July 12th.

--
Chris Aniszczyk (@cra) | +1-512-961-6719
4461 - 4480 of 7942