Date   

Re: Maintainer Mailing List Confusion

Richard Hartmann
 

All agreed with Matt's points.

To add to this, Prometheus has its own mailing list, and this will be
true of others I suspect. We have had confusion about how mailing
lists are supposed to work in the past, as well.

In my opinion, a good setup would be:

1) Several CNCF-maintained mailing lists, one per project, OR used as
a forward to a maintainer-maintained list, at each project's choice
2) One CNCF-maintained mailing list for all projects, including all
maintainers, for general discussion amongst projects. All maintainers,
and some select CNCF staff, can send unmoderated.
3) One CNCF-maintained announcement list, with Reply-To: set to the
discussion list. Only CNCF staff, TOC, etc can send unmoderated.

The rationale for 3) being that 2) will sometimes delve into seemingly
endless discussion so it makes sense to allow people to filter 3)
higher.

There's a risk for 2) and TOC list overlapping. But as TOC list
currently functions as 2), that's not that bad.


Richard

PS: I was not aware of the list for all member project maintainers,
either. Where and how do I join?


Re: Maintainer Mailing List Confusion

Eduardo Silva
 

Hi, 

On Sat, Jan 18, 2020, 07:38 Matt Farina <matt@...> wrote:
I've been confused about this and I know others have been as well so I wanted to ?

My suggestion is one mailing list with all current CNCF project maintainers on it. What do people think? I'm specifically curious what other CNCF project maintainers think.

Yeah, good idea :)

I've always missed networking channels for maintainers, I mean "inter-projects".  

And for the upcoming CloudNativeCon, I think would be great if CNCF could arrange some lunch/dinner or networking event for "maintainers" where we can interact. 

Regards 

_,_


Re: [EXTERNAL] [cncf-toc] Idea: maintainers supporting each other / mailing list

Kiran Mova
 

+1 to this idea.


On Sat, Jan 18, 2020, 12:58 AM Matt Farina <matt@...> wrote:
We do have a maintainers mailing list but I don't see any activity between maintainers.

There's isn't a general mailing list that maintainers can use to contact each other. There is a mass distribution list (not on lists.cncf.io) where all content sent to it is moderated. Maintainers are very much silo'd from each other in the current setup.


Re: CNCF SIG Contributor Experience Proposal

Lee Calcote
 

+1 NB. This SIG stands to benefit all projects, and hopefully, help recognize all types of contributors (non-code). I’d like to see a contributor ladder come forth here.

- Lee

On Jan 17, 2020, at 4:48 PM, Paris Pittman via Lists.Cncf.Io <parispittman=google.com@...> wrote:

Hi TOC and community,

I'm watching the emails fly by re: maintainer things so figured no time like the present to send this start of a proposal along. I've been working on it for a few weeks and getting input. I think I'm a first-time poster, very-long-time lurker to this list, hello! 

I recently stepped back from my role as co-chair for Kubernetes Contributor Experience Special Interest Group that I held for 2 years. Sarah Novotny, Brian Grant, Phil Wittrock and many(!) others decided that a place for intentional contributor community building was necessary and I'm glad they did. I believe it's the secret sauce but yes - I'm bias. :)

A group like this[1] could help many stakeholders, as outlined in this work-in-progress doc, including engaging the end user community in new ways, and current cncf projects that don't have a ContribEx/CommComm (nod to nodejs). It's important to note in the out-of-scope section, this group isn't going to do the work for your project but will help you get there and learn together. I've spoken to some TOC members and many project maintainers about this. 

Notes:
  • This is a pretty broad charter that should absolutely be trimmed down after formation, discovery, and some other kick off activities. 
  • Left broad as most of the work will depend on the known gaps and the contributors/community members who step forward to help with them.

paris

[1] https://docs.google.com/document/d/1UYIp55jsEn7hSGHOh4sXXx_VnqPL0E0upsWCUZB5Tn8/edit?usp=sharing 






--

Paris Pittman
Kubernetes Community
Open Source Strategy, Google Cloud
345 Spear Street, San Francisco, 94105



Re: [EXTERNAL] Re: [cncf-toc] CNCF SIG Contributor Experience Proposal

Brendan Burns
 

+1 from me as well. Thanks Paris!



From: cncf-toc@... <cncf-toc@...> on behalf of Matt Klein via Lists.Cncf.Io <mattklein123=gmail.com@...>
Sent: Friday, January 17, 2020 4:43 PM
To: Paris Pittman <parispittman@...>
Cc: cncf-toc@... <cncf-toc@...>
Subject: [EXTERNAL] Re: [cncf-toc] CNCF SIG Contributor Experience Proposal
 
Big +1 from me. Very excited to see this SIG form as I think this is an area that many projects struggle with. The projects that don't struggle with this have some very overworked maintainers. ;)

On Fri, Jan 17, 2020 at 2:49 PM Paris Pittman via Lists.Cncf.Io <parispittman=google.com@...> wrote:
Hi TOC and community,

I'm watching the emails fly by re: maintainer things so figured no time like the present to send this start of a proposal along. I've been working on it for a few weeks and getting input. I think I'm a first-time poster, very-long-time lurker to this list, hello! 

I recently stepped back from my role as co-chair for Kubernetes Contributor Experience Special Interest Group that I held for 2 years. Sarah Novotny, Brian Grant, Phil Wittrock and many(!) others decided that a place for intentional contributor community building was necessary and I'm glad they did. I believe it's the secret sauce but yes - I'm bias. :)

A group like this[1] could help many stakeholders, as outlined in this work-in-progress doc, including engaging the end user community in new ways, and current cncf projects that don't have a ContribEx/CommComm (nod to nodejs). It's important to note in the out-of-scope section, this group isn't going to do the work for your project but will help you get there and learn together. I've spoken to some TOC members and many project maintainers about this. 

Notes:
  • This is a pretty broad charter that should absolutely be trimmed down after formation, discovery, and some other kick off activities. 
  • Left broad as most of the work will depend on the known gaps and the contributors/community members who step forward to help with them.

paris

[1] https://docs.google.com/document/d/1UYIp55jsEn7hSGHOh4sXXx_VnqPL0E0upsWCUZB5Tn8/edit?usp=sharing 






--

Paris Pittman

Kubernetes Community

Open Source Strategy, Google Cloud

345 Spear Street, San Francisco, 94105



Re: CNCF SIG Contributor Experience Proposal

Matt Klein
 

Big +1 from me. Very excited to see this SIG form as I think this is an area that many projects struggle with. The projects that don't struggle with this have some very overworked maintainers. ;)


On Fri, Jan 17, 2020 at 2:49 PM Paris Pittman via Lists.Cncf.Io <parispittman=google.com@...> wrote:
Hi TOC and community,

I'm watching the emails fly by re: maintainer things so figured no time like the present to send this start of a proposal along. I've been working on it for a few weeks and getting input. I think I'm a first-time poster, very-long-time lurker to this list, hello! 

I recently stepped back from my role as co-chair for Kubernetes Contributor Experience Special Interest Group that I held for 2 years. Sarah Novotny, Brian Grant, Phil Wittrock and many(!) others decided that a place for intentional contributor community building was necessary and I'm glad they did. I believe it's the secret sauce but yes - I'm bias. :)

A group like this[1] could help many stakeholders, as outlined in this work-in-progress doc, including engaging the end user community in new ways, and current cncf projects that don't have a ContribEx/CommComm (nod to nodejs). It's important to note in the out-of-scope section, this group isn't going to do the work for your project but will help you get there and learn together. I've spoken to some TOC members and many project maintainers about this. 

Notes:
  • This is a pretty broad charter that should absolutely be trimmed down after formation, discovery, and some other kick off activities. 
  • Left broad as most of the work will depend on the known gaps and the contributors/community members who step forward to help with them.

paris

[1] https://docs.google.com/document/d/1UYIp55jsEn7hSGHOh4sXXx_VnqPL0E0upsWCUZB5Tn8/edit?usp=sharing 






--

Paris Pittman

Kubernetes Community

Open Source Strategy, Google Cloud

345 Spear Street, San Francisco, 94105



CNCF SIG Contributor Experience Proposal

Paris Pittman <parispittman@...>
 

Hi TOC and community,

I'm watching the emails fly by re: maintainer things so figured no time like the present to send this start of a proposal along. I've been working on it for a few weeks and getting input. I think I'm a first-time poster, very-long-time lurker to this list, hello! 

I recently stepped back from my role as co-chair for Kubernetes Contributor Experience Special Interest Group that I held for 2 years. Sarah Novotny, Brian Grant, Phil Wittrock and many(!) others decided that a place for intentional contributor community building was necessary and I'm glad they did. I believe it's the secret sauce but yes - I'm bias. :)

A group like this[1] could help many stakeholders, as outlined in this work-in-progress doc, including engaging the end user community in new ways, and current cncf projects that don't have a ContribEx/CommComm (nod to nodejs). It's important to note in the out-of-scope section, this group isn't going to do the work for your project but will help you get there and learn together. I've spoken to some TOC members and many project maintainers about this. 

Notes:
  • This is a pretty broad charter that should absolutely be trimmed down after formation, discovery, and some other kick off activities. 
  • Left broad as most of the work will depend on the known gaps and the contributors/community members who step forward to help with them.

paris

[1] https://docs.google.com/document/d/1UYIp55jsEn7hSGHOh4sXXx_VnqPL0E0upsWCUZB5Tn8/edit?usp=sharing 






--

Paris Pittman

Kubernetes Community

Open Source Strategy, Google Cloud

345 Spear Street, San Francisco, 94105



[RESULT] ] Increase Sandbox requirement to three sponsors from the TOC (Approved)

Amye Scavarda Perrin
 

Liz Rice has called a vote on increasing the requirement to join Sandbox to three TOC sponsors (up from two) as we are increasing the size of the TOC from 9 to 11 seats.
This goes into effect with the seating of the 11 person TOC in February. 

+1, Binding: 6/9
Alexis Richardson: https://lists.cncf.io/g/cncf-toc/message/3976
Brian Grant: https://lists.cncf.io/g/cncf-toc/message/3978
Matt Klein: https://lists.cncf.io/g/cncf-toc/message/3979
Joe Beda: https://lists.cncf.io/g/cncf-toc/message/3983
Jeff Brewer: https://lists.cncf.io/g/cncf-toc/message/3996
Liz Rice: https://lists.cncf.io/g/cncf-toc/message/4088

1+ NB:
Shannon Williams: https://lists.cncf.io/g/cncf-toc/message/3980
Chris Short: https://lists.cncf.io/g/cncf-toc/message/3981
Jon Mittelhauser: https://lists.cncf.io/g/cncf-toc/message/3984
Kevin Ryan: https://lists.cncf.io/g/cncf-toc/message/3985
Richard Hartmann: https://lists.cncf.io/g/cncf-toc/message/3997
Thomas Mclennan: https://lists.cncf.io/g/cncf-toc/message/3998
Kiran Mova: https://lists.cncf.io/g/cncf-toc/message/4000

-1 NB:
Gerred Dillon: https://lists.cncf.io/g/cncf-toc/message/3999
--
Amye Scavarda Perrin | Program Manager | amye@...


Maintainer Mailing List Confusion

Matt Farina
 

I've been confused about this and I know others have been as well so I wanted to see If I have it right now and help others know how the CNCF project maintainer mailing lists work.

The details:

Each of the projects has a mailing lists on lists.cncf.io for its maintainers. This is a moderated list (if the others are like the one I'm on) so all the messages coming into the list from people not on the list are moderated. This is for each project individually.

There is a mailing list elsewhere (powered by Google Gsuite?) that takes in messages where they are moderated and then forwarded on to the individual project mailing lists.

So, for something to be sent to all the maintainers of all the projects it's first sent to the maintainers mailing list. It is them moderated. Once out of there it goes out to the other mailing lists. There it is moderated for each individual project. Then, it goes on to the maintainers.

This central lists is often (only ever?) used by the CNCF to communicate out things like election detail, GSoC, event announcements, etc. We end up seeing it in our moderation queue where we can see it, approve it, and send it out to maintainers.

A new maintainers list was just setup for cross projects. It's private-ish (as in more than just maintainers are on it). It's opt-in as I learned (I was a little confused on it).

If there is something that should be tweaked about this I'd love to know

My 2 Cents:

This structure makes it practically impossible for maintainers across projects to organize, help each other, share information, or be a resource to each other. Two levels of moderation for every message and the second is across every single project. This is pretty much unusable for anything other than announcements.

The new private list is opt-in. I doubt most maintainers know about it. As maintainers come and go from projects there is no way to keep it updated. Even if someone sends a message to the top level list and it's approved at all levels (currently needs 45 moderation approvals to get out to everyone) that only lets the people who are currently maintainers know.

This is not an idea communication situation for cross project communication. Can we do something better?

My suggestion is one mailing list with all current CNCF project maintainers on it. What do people think? I'm specifically curious what other CNCF project maintainers think.

- Matt Farina


Re: [EXTERNAL] [cncf-toc] Idea: maintainers supporting each other / mailing list

Matt Farina
 

We do have a maintainers mailing list but I don't see any activity between maintainers.

There's isn't a general mailing list that maintainers can use to contact each other. There is a mass distribution list (not on lists.cncf.io) where all content sent to it is moderated. Maintainers are very much silo'd from each other in the current setup.


Re: Idea: maintainers supporting each other / mailing list

Liz Rice
 

Thanks for raising this, it’s important for sure. 

Is this something that could / should fit in the remit of Paris’s proposed SIG Contribex? 

--
Liz Rice
@lizrice | lizrice.com | +44 (0) 780 126 1145



On 17 Jan 2020, at 17:18, Matt Farina <matt@...> wrote:

While we're talking about this...

If anyone needs someone to talk to or figure out how to deal with this stuff... I am happy to listen and share what I've learned. I feel like I have a system (that works for me) that doesn't leave me too stressed and I can still be productive enough with. I'm happy to share.


Re: [VOTE] Increase Sandbox requirement to three sponsors from the TOC

Liz Rice
 

+1 binding 
(explicitly adding my vote, after calling the vote!) 

--
Liz Rice
@lizrice | lizrice.com | +44 (0) 780 126 1145



On 2 Jan 2020, at 11:47, Kiran Mova <kiran.mova@...> wrote:

+1 NB - After the clarifications received via the comments on github. 
--
Kiran Mova  | Co-Founder, Chief Architect MayaData  | kiran.mova@...


On Sun, Dec 22, 2019 at 2:32 PM Richard Hartmann <richih@...> wrote:
+1 NB with Joe's considerations

Sent by mobile; please excuse my brevity.

On Tue, Dec 17, 2019, 23:21 Joe Beda via Lists.Cncf.Io <jbeda=vmware.com@...> wrote:

+1 assuming that this takes effect as the size of the TOC increases (as in we give folks fair warning that this will happen as we seat the new members)

 

From: <cncf-toc@...> on behalf of Liz Rice <liz@...>
Date: Tuesday, December 17, 2019 at 12:41 PM
To: "cncf-toc@..." <cncf-toc@...>
Subject: [cncf-toc] [VOTE] Increase Sandbox requirement to three sponsors from the TOC

 

As discussed earlier, I’m proposing that we change the requirement to join Sandbox to three TOC sponsors (up from two) as we are increasing the size of the TOC from 9 to 11 seats.


--

Liz Rice

@lizrice | lizrice.com | +44 (0) 780 126 1145



Re: Idea: maintainers supporting each other / mailing list

Matt Farina
 

While we're talking about this...

If anyone needs someone to talk to or figure out how to deal with this stuff... I am happy to listen and share what I've learned. I feel like I have a system (that works for me) that doesn't leave me too stressed and I can still be productive enough with. I'm happy to share.


Re: Idea: maintainers supporting each other / mailing list

Chris Aniszczyk
 

This is a no brainer, we will create a mailing list to start:

We are also gearing up for our bi-annual maintainer survey next month, so if you have questions or ideas on how to surface things via that please open up issues here: https://github.com/cncf/surveys/tree/master/maintainer/2019

On Fri, Jan 17, 2020 at 10:24 AM Richard Hartmann <richih@...> wrote:
I like this very much. I have been in this hole and it's
highly-nonobvious that this was even happening, or what, initially, to
do about it.

This could also be part of CloudNativeCons, though I am not sure about
timing, setting, framing. But it sounds like something people could
use. Plus, knowing each other in person, could help strengthen
inter-projects ties.





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


Re: Idea: maintainers supporting each other / mailing list

Yuri Shkuro
 

Brandon and I hosted two zoom meetings last year where we invited all the maintainers to give us feedback on what the CNCF can do for them. I learned a lot from those meetings including lots of maintainers have the same concerns and are often met with the same scenarios.

As I recall, there was even a long document that many people collaborated on. Was anything done to address the concerns of maintainers raised in that document & meetings?

On Fri, Jan 17, 2020 at 11:24 AM Richard Hartmann <richih@...> wrote:
I like this very much. I have been in this hole and it's
highly-nonobvious that this was even happening, or what, initially, to
do about it.

This could also be part of CloudNativeCons, though I am not sure about
timing, setting, framing. But it sounds like something people could
use. Plus, knowing each other in person, could help strengthen
inter-projects ties.




Re: Idea: maintainers supporting each other / mailing list

Richard Hartmann
 

I like this very much. I have been in this hole and it's
highly-nonobvious that this was even happening, or what, initially, to
do about it.

This could also be part of CloudNativeCons, though I am not sure about
timing, setting, framing. But it sounds like something people could
use. Plus, knowing each other in person, could help strengthen
inter-projects ties.


Re: [EXTERNAL] [cncf-toc] Idea: maintainers supporting each other / mailing list

Michelle Noorali
 

Thanks for bringing this up Matt. I agree many open source maintainers feel this way and we need to talk more about sustainable processes and expectations. We do have a maintainers mailing list but I don't see any activity between maintainers. I also don't know if it's private. Brandon and I hosted two zoom meetings last year where we invited all the maintainers to give us feedback on what the CNCF can do for them. I learned a lot from those meetings including lots of maintainers have the same concerns and are often met with the same scenarios. Perhaps, we could host quarterly zoom meetings for maintainers around topics related to burn out, code of conduct, common experiences, etc. to see where and how the CNCF can best help. A slack channel could also help create a daily support system and way to share experiences more frequently. Thoughts?


From: cncf-toc@... <cncf-toc@...> on behalf of Matt Farina via Lists.Cncf.Io <matt=mattfarina.com@...>
Sent: Friday, January 17, 2020 10:27 AM
To: CNCF TOC <cncf-toc@...>
Cc: cncf-toc@... <cncf-toc@...>
Subject: [EXTERNAL] [cncf-toc] Idea: maintainers supporting each other / mailing list
 
The maintainer of a popular Rust project quit this morning and took down the project. Buried in the post mortem:

Be a maintainer of large open source project is not a fun task. You alway face with rude and hate, everyone knows better how to build software, nobody wants to do home work and read docs and think a bit and very few provide any help.

If you maintain something that gets popular this is bound to happen. I appreciate that the CNCF requires maintainers from multiple organizations to graduate. This means the burnout of one person or organization isn't going to take down a project.

But, this doesn't do much for the mental health of the maintainers on the projects. Incubating and sandbox projects don't need to have multi-org maintainers so there is still risk. But, where is the CNCF support system to help them build more maintainers and deal with the stress that comes along with being popular? The stress isn't just expectations others put on us. We sometimes put it on ourselves.

With that in mind, can we start to build out a support system. I would suggest starting with a mailing list that's maintainers only. A place where we maintainers can talk about things in private. Seek help, share ideas, get advice from others going through it, and so forth. For some projects that overlap in space this would need to be done in the spirit of coopetition.

Thoughts?

- Matt Farina


Idea: maintainers supporting each other / mailing list

Matt Farina
 

The maintainer of a popular Rust project quit this morning and took down the project. Buried in the post mortem:

Be a maintainer of large open source project is not a fun task. You alway face with rude and hate, everyone knows better how to build software, nobody wants to do home work and read docs and think a bit and very few provide any help.

If you maintain something that gets popular this is bound to happen. I appreciate that the CNCF requires maintainers from multiple organizations to graduate. This means the burnout of one person or organization isn't going to take down a project.

But, this doesn't do much for the mental health of the maintainers on the projects. Incubating and sandbox projects don't need to have multi-org maintainers so there is still risk. But, where is the CNCF support system to help them build more maintainers and deal with the stress that comes along with being popular? The stress isn't just expectations others put on us. We sometimes put it on ourselves.

With that in mind, can we start to build out a support system. I would suggest starting with a mailing list that's maintainers only. A place where we maintainers can talk about things in private. Seek help, share ideas, get advice from others going through it, and so forth. For some projects that overlap in space this would need to be done in the spirit of coopetition.

Thoughts?

- Matt Farina


Re: Comment on Increase Sandbox requirement to three sponsors from the TOC

Gerred Dillon
 

Haven’t had a chance - I was on holidays myself which is why I didn’t jump back into this and other threads earlier earlier. Fresh thoughts as I return with a clear head. :) I will be in SIG App Delivery tomorrow and other SIG meetings as well, and of course reach out as well directly.

On Jan 15, 2020, at 1:28 AM, Alexis Richardson <alexis@...> wrote:

Gerred

IMO that is very fair comment; and not far from what the TOC is
currently hoping to do. Have you spoken with any TOC members or SIG
leads about how best to get from here to there?

alexis

On Wed, Jan 15, 2020 at 12:23 AM Gerred Dillon <hello@...> wrote:

I feel that it’s less like the process is broken, but rather the perception the TOC is putting forth (by way of SIGs and increasing requirements) is that the process must scale and there’s uncertainty while figuring that out as new projects are proposed while others are in waiting stages.

It would be nice to find and hit a “reset” button on everything in flight, get as many TOC members, CNCF SIG chairs, and project stakeholders on the same page as possible, and have a fresh start.

For example, I still DO feel like “just” increasing the number of sponsors for sandbox is not the right decision. The results of this motion are still unclear. What does this affect? New projects? Projects moving through SIGs? Do existing sandbox projects need to find a third sponsor? Do the SIGs know what is being voted on when this comes to a binding vote, and have they discussed how this affects their charter and what they send to the TOC?

The purpose of this email (and I would hope is more appropriate for an issue and continued discussion) is not to answer these questions but as the engines of the TOC restart after the holidays, clear up what is actually being proposed and voted on. I stand by my -1 NB until these things are understood, but look forward to providing input to get to a supportive position - or at least have a very clear issue when I vote, no matter how that falls.

On Jan 15, 2020, at 1:02 AM, Alexis Richardson <alexis@...> wrote:
Vinod

Thanks for clarifying that. Normally when people say "partial" they
imply agency. I think you are saying that the Process is not clear
and (to your eyes) may be broken.

Can I ask please: are you aware that we stopped all new projects for
many months? That is why there is a backlog. We are trying to get
back on track. It is a lot of work, if you want to help.

a

On Tue, Jan 14, 2020 at 10:13 PM Vinod NA <vinod@...> wrote:

Hi Alex,

I am not accusing anyone. I am interested in more open-source projects joining the CNCF ecosystem and at the same time, improving the growth and health of those projects. I believe the current TOC process results in unfair treatment for open-source projects, and it makes some of them, wait more than a year to get TOC sponsors. I think the current TOC process is not following the CNCF principles mentioned below.

https://github.com/cncf/foundation/blob/master/charter.md#3-values

Thank you,

Vinod

On Mon, Jan 13, 2020 at 2:13 AM Alexis Richardson <alexis@...> wrote:

Vinod

Who are you accusing of being partial.

Alexis


On Sun, 12 Jan 2020, 23:53 Vinod NA, <vinod@...> wrote:

Thank you very much to all who were courageous enough to speak about the partiality. At some point, I felt I was a mad person.


@Matt, thank you very much for your input. I hope that the TOC will consider it. I think most of the other foundations are focusing on two levels. In the following CNCF documentation, it’s directing the sandbox as “experimental" projects. And it also says “It is expected that some Sandbox projects may fail”.

https://github.com/cncf/toc/blob/master/process/sandbox.md

IMHO I think too much red taping, unfair treatment should be avoided for the sandbox onboarding so that the process will align with the CNCF principles.


@Alexis, It’s good to know that your company has already reviewed the quality of the project and it's using it. Like Contour, other projects coming to CNCF may be also used by multiple other CNCF members and they might have also reviewed the quality. My kind request is to treat all incoming projects “fairly” and to put CNCF's interest first. I consider the TOC as a supreme court for the CNCF, I think that the TOC members should be like judges and make a judgment based on facts (keep their personal and professional interests aside).


My intention is only to propose improvements in the process so that this kind of partiality can be avoided in the future. I have mentioned it in the GitHub issue. The TOC members may have a different opinion and may consider that so far every submission is treated fairly and all submissions are completed in a fast manner, but as an individual who follows the TOC meeting recordings, presentations, TOC mailing list emails, I don’t have the same opinion. That’s why I have created a GitHub issue explaining issues at a high level, however, as the TOC couldn’t understand it, I have added more details and I've also included some examples. My intention wasn’t to hurt anybody’s feelings, I am really sorry if you have felt that way. But I do have the right to express my own opinion.


Feel free to comment your views on the GitHub issue ( https://github.com/cncf/toc/issues/331 ). I am not interested in spamming many people and that's why I was trying to avoid communication in the mailing list and focus on the GitHub issue.


@Liz, CNCF should be fair to all projects and at least let them know what they have to do to get "SPONSOR". Also, I think it would become a better experience for the projects if all the TOCs are aligned with the CNCF, TOC principles and process.


Sandbox projects waiting for TOC sponsors

( 7 Months ) https://github.com/cncf/toc/pull/261

( 8 Months ) https://github.com/cncf/toc/pull/255

( 9 Months ) https://github.com/cncf/toc/pull/237

( 1 Year ) https://github.com/cncf/toc/pull/189

( 1 Year and 6 months ) https://github.com/cncf/toc/issues/128

( 1 Year and 9 months ) https://github.com/cncf/toc/issues/103


Incubation projects waiting for TOC sponsors

( 3 Months ) https://github.com/cncf/toc/pull/303


Apologies if my words have hurt anyone. My intention was only to point out the unfair treatment and I am not suggesting that this may have happened intentionally. However, I do want to emphasize the flows in the existing process which lead to this type of issues.


On Fri, Jan 10, 2020 at 6:39 PM Liz Rice <liz@...> wrote:

I think it could be good to acknowledge the frustration.


Absolutely - acknowledged!

And believe me we really are working to try to address this. Getting the SIGs set up is intended to help us scale, and we are working to streamline the process, document it and make it more transparent, and set better time expectations.

As one example, the current suggestion we’re working on includes the project presentation for Sandbox being done to a SIG rather than to the whole TOC.

I really do feel bad for maintainers who have been trying to get attention to their projects while we’re working through this. Sorry.

Speaking of which, if you are waiting to progress your project’s proposal, please check its status on the backlog and let Amye know if anything looks wrong or is missing.

--
Liz Rice
@lizrice | lizrice.com | +44 (0) 780 126 1145



On 10 Jan 2020, at 15:23, Matt Farina <matt@...> wrote:

I think it could be good to acknowledge the frustration. There are open sandbox proposals that are many months old (including one from January a year ago). Sandbox projects are scheduled to demo in a TOC meeting as part of their process to find sponsors. Yet, the last public TOC meeting with quorum was in October. It's been a quarter since a meeting with quorum. If a sandbox project presents what sponsors will be there to see it?

When a project comes along that gets sponsors quickly, even without a demo, it's bound to be frustrating for people who are already frustrated while trying to work through the CNCF processes to find sponsors. I would be frustrated if I were going through this.

I would like to see changes, too.

While CNCF is different from Apache, the Apache Foundation does some rather nice things to help people. They've been around longer and have had time to put time into this. For example, going through their processes and getting help through it is all documented . It would be fantastic if the process, and how to get help, were documented more clearly. It's more than process documentation.

I also wonder, what would make a good CNCF project? I'm not sure that's entirely clear to everyone. If the basics were documented it would let potential projects self filter and it would give clarity to the process in the spirit of openness. Projects proposing themselves could show how they would be a good CNCF project to make it easier for TOC members to assess.

GitHub and devstats look at how quickly a project responds to issues and PRs. Developers like to know these things about projects. If the TOC and the supporting system around sandbox projects were to get easier and more efficient for everyone, I think, it would be a good thing.

Just my 2 cents.

- Matt Farina


On Fri, Jan 10, 2020, at 4:38 AM, Alexis Richardson wrote:

Vinod

The reason I am happy to sponsor Contour is because my team has used it and think it is of a very high quality. I do not need to see a presentation to reach that decision. Regardless of what level the project applies for.

Your comments about the TOC members deciding to sponsor at Sandbox and then finding out the project is applying for incubation, and drawing some sinister conclusion, are mistaken and should be withdrawn.

You make a number of other comparisons with keycloak and other projects. These comparisons are incorrect.

If contour is to be accepted as a project it will follow a process and, so far, it is doing so. For example please note that TOC sponsorship provides no guarantee that a project will pass DD for incubation. In fact, at incubation level the purpose of sponsorship is to get permission to move to the DD stage.

Alexis




On Fri, 10 Jan 2020, 01:26 Vinod NA, <vinod@...> wrote:

I also agree with Gerred about the recent submission. Many of you may have missed it as the project got sponsored super fast.

Every project coming to join the CNCF family should be treated fairly. The TOC should consider the fact that they are willing to donate their project to the CNCF foundation and not to other foundations.

Quoting Chris "TOC members are expected to act in the interest of CNCF and not their employers". I also think that TOC members should act in the interest of CNCF, not in their personal or their employer's interest. The TOC membership should uphold the CNCF and TOC principles.

I have seen different projects treated differently during their submission.

I am not against the following project joining CNCF and I believe more projects should join the CNCF family. I am just unhappy with the partiality.

For a recent submission, the TOC members got too excited and sponsored the project, without even any presentation and not completely reviewing the content of the pull request. Only after sponsoring, the TOC members have realized that the project is asking for an incubation maturity level and they thought it was a sandbox. I don't know what was the urgency to get this project sponsored, compared to the other ones which are waiting nearly a year and one even got rejected after not having a sponsor after a year. Now TOC has instructed the SIG-network to review it. I don't understand the purpose of this review. This is like a group of judges already made a judgment and then they're requesting the police officers to investigate it.

When Keycloak requested to join as a sandbox, the TOC was concerned about the governance and the team responded with their open governance and published ( https://github.com/keycloak/keycloak/blob/master/GOVERNANCE.md ). Even though the project team has only asked for Sandbox maturity, the TOC was considering it like an Incubator/Graduation project. The project answered the questions and TOC didn't ask any further questions and didn't mention which CNCF or TOC principle Keycloak didn't meet, it was just rejected saying no "SPONSOR" after waiting a year.

Keycloak is already used by CNCF member companies. I don't think the decision to reject the project without even accepting it in the sandbox level is in the CNCF community's best interest.

More details will be added in this GitHub issue = https://github.com/cncf/toc/issues/331

On Fri, 10 Jan 2020, 10:57 Liz Rice, <liz@...> wrote:

Sorry, I am missing something - which projects are proposing to skip the process? And (bearing mind the TOC have to sponsor / vote) do you see support from TOC members for them skipping the process?

--
Liz Rice
@lizrice | lizrice.com | +44 (0) 780 126 1145


On 10 Jan 2020, at 03:57, Gerred Dillon <hello@...> wrote:

Combining a few messages here -

The motivation for the increase makes sense. From a multi-vendor control standpoint, I will move to +1 NB on this particular issue.

That said, I'm sitting on a draft of collected thoughts, of which I will refine and post tomorrow - but in short I feel like change does need to be made, especially in light of other projects that proposed in the past days to skip the process demanded of projects included in the CNCF. This felt like a very clear violation of responsibility to the members that make up the CNCF, it's governing bodies, and those rely upon their decision making processes - and it's been made clear that without someone concerned about it, existing processes are potentially too easy to short-circuit.

On Thu, Jan 9, 2020 at 10:36 PM Matt Farina <matt@...> wrote:


To add a little more context...

The TOC is expanding from 9 to 11 members and a single company (or group of companies under the same umbrella) can have 2 members on it.

The current sandbox process only requires 2 TOC members to sponsor a project. This means a single company with two members is able to add any sandbox project they want.

The CNCF charter notes:

The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects


If the CNCF processes allows a situation for a single vendor to have the ability to add any sandbox projects they like is this enabling vendor neutrality and the charter would like?

An argument has been made it's not so the TOC sponsors should expand to 3 to require multiple organizations to be involved in sponsoring. This is what expanding to 3 TOC sponsors gives us.

Many projects are waiting almost a year to get a “Sponsor”, and others get rejected after a year without getting a “Sponsor”.


This must be frustrating for the people working on those projects.

I would like to see the TOC make some changes to address this problem. A clear documented processes and methodology. Something people on the projects can understand, follow, and depend on.

On Thu, Jan 9, 2020, at 11:42 AM, Vinod NA wrote:

-1 NB ( I am not in favor of sponsoring concept at all )

I think sponsoring will lead to "King Makers" situation which is against the TOC principle.

I don’t agree that the CNCF sandbox entry barrier is low. Many projects are waiting almost a year to get a “Sponsor”, and others get rejected after a year without getting a “Sponsor”.

I don’t fully agree with the concept that all sandbox projects should graduate. Sandbox then won’t be the ideal name for this stage then. Ideally, all projects should graduate and the CNCF should build sustainable ecosystems for it but there are many other factors that the TOC or CNCF can't control. Projects may go to archives from any stage. The "rkt " project is an example of it.

I agree that the TOC review shouldn’t be a tick-the-box exercise. TOC should make the judgment based on facts, not based on what they like or dislike. A TOC member won’t necessarily get enthusiastic about a project if he/she knows very well about that project's domain and technology stack. Also, the TOC does not pick a “winning stack” as per the TOC's operating principles document.

I have opened an issue in the TOC repo with more details, feel free to comment your thoughts there.

https://github.com/cncf/toc/issues/331


On Thu, 9 Jan 2020, 16:24 Liz Rice, <liz@...> wrote:

Hi Gerred,

I wanted to follow up with a few thoughts on your comment here.

Although the barrier to entry for Sandbox is intended to be low, we want to make sure that the projects that come in have a good chance of making it to incubation and graduation. Potential sponsors from the TOC should have confidence that the project is on the right path towards those criteria. It would be doing a disservice to a project if we were to accept it without that confidence.

Acceptance to the CNCF at any level should never be just a tick-the-box exercise. The TOC should always be able to exercise their judgement and discretion. At the Sandbox level, if there aren’t enough TOC members with the confidence and enthusiasm in a project to step forward as sponsors, then it doesn’t get accepted.

I hope that helps,
Liz

--
Liz Rice
@lizrice | lizrice.com | +44 (0) 780 126 1145


On 28 Dec 2019, at 06:07, Gerred Dillon <hello@...> wrote:

-1 non-binding

i'm not thrilled with how the sandbox has already changed without a controlled burn rate, i disagree with this motion without other changes to the sandbox process happening. kudo has already been given -1s on sandbox inclusion based on incubating/graduating requirements in private as negative votes for inclusion -- despite communication that these weren't requirements. sandbox is either inclusive or it's not, and i'd rather inclusion at this stage, given there are no marketing expectations or official endorsement of these projects by the CNCF.

On Fri, Dec 27, 2019 at 4:24 PM Thomas Mclennan <Thomas.mc@...> wrote:

+1 non-binding











Re: Comment on Increase Sandbox requirement to three sponsors from the TOC

alexis richardson
 

Gerred

IMO that is very fair comment; and not far from what the TOC is
currently hoping to do. Have you spoken with any TOC members or SIG
leads about how best to get from here to there?

alexis

On Wed, Jan 15, 2020 at 12:23 AM Gerred Dillon <hello@...> wrote:

I feel that it’s less like the process is broken, but rather the perception the TOC is putting forth (by way of SIGs and increasing requirements) is that the process must scale and there’s uncertainty while figuring that out as new projects are proposed while others are in waiting stages.

It would be nice to find and hit a “reset” button on everything in flight, get as many TOC members, CNCF SIG chairs, and project stakeholders on the same page as possible, and have a fresh start.

For example, I still DO feel like “just” increasing the number of sponsors for sandbox is not the right decision. The results of this motion are still unclear. What does this affect? New projects? Projects moving through SIGs? Do existing sandbox projects need to find a third sponsor? Do the SIGs know what is being voted on when this comes to a binding vote, and have they discussed how this affects their charter and what they send to the TOC?

The purpose of this email (and I would hope is more appropriate for an issue and continued discussion) is not to answer these questions but as the engines of the TOC restart after the holidays, clear up what is actually being proposed and voted on. I stand by my -1 NB until these things are understood, but look forward to providing input to get to a supportive position - or at least have a very clear issue when I vote, no matter how that falls.

On Jan 15, 2020, at 1:02 AM, Alexis Richardson <alexis@...> wrote:

Vinod

Thanks for clarifying that. Normally when people say "partial" they
imply agency. I think you are saying that the Process is not clear
and (to your eyes) may be broken.

Can I ask please: are you aware that we stopped all new projects for
many months? That is why there is a backlog. We are trying to get
back on track. It is a lot of work, if you want to help.

a

On Tue, Jan 14, 2020 at 10:13 PM Vinod NA <vinod@...> wrote:

Hi Alex,

I am not accusing anyone. I am interested in more open-source projects joining the CNCF ecosystem and at the same time, improving the growth and health of those projects. I believe the current TOC process results in unfair treatment for open-source projects, and it makes some of them, wait more than a year to get TOC sponsors. I think the current TOC process is not following the CNCF principles mentioned below.

https://github.com/cncf/foundation/blob/master/charter.md#3-values

Thank you,

Vinod

On Mon, Jan 13, 2020 at 2:13 AM Alexis Richardson <alexis@...> wrote:

Vinod

Who are you accusing of being partial.

Alexis


On Sun, 12 Jan 2020, 23:53 Vinod NA, <vinod@...> wrote:

Thank you very much to all who were courageous enough to speak about the partiality. At some point, I felt I was a mad person.


@Matt, thank you very much for your input. I hope that the TOC will consider it. I think most of the other foundations are focusing on two levels. In the following CNCF documentation, it’s directing the sandbox as “experimental" projects. And it also says “It is expected that some Sandbox projects may fail”.

https://github.com/cncf/toc/blob/master/process/sandbox.md

IMHO I think too much red taping, unfair treatment should be avoided for the sandbox onboarding so that the process will align with the CNCF principles.


@Alexis, It’s good to know that your company has already reviewed the quality of the project and it's using it. Like Contour, other projects coming to CNCF may be also used by multiple other CNCF members and they might have also reviewed the quality. My kind request is to treat all incoming projects “fairly” and to put CNCF's interest first. I consider the TOC as a supreme court for the CNCF, I think that the TOC members should be like judges and make a judgment based on facts (keep their personal and professional interests aside).


My intention is only to propose improvements in the process so that this kind of partiality can be avoided in the future. I have mentioned it in the GitHub issue. The TOC members may have a different opinion and may consider that so far every submission is treated fairly and all submissions are completed in a fast manner, but as an individual who follows the TOC meeting recordings, presentations, TOC mailing list emails, I don’t have the same opinion. That’s why I have created a GitHub issue explaining issues at a high level, however, as the TOC couldn’t understand it, I have added more details and I've also included some examples. My intention wasn’t to hurt anybody’s feelings, I am really sorry if you have felt that way. But I do have the right to express my own opinion.


Feel free to comment your views on the GitHub issue ( https://github.com/cncf/toc/issues/331 ). I am not interested in spamming many people and that's why I was trying to avoid communication in the mailing list and focus on the GitHub issue.


@Liz, CNCF should be fair to all projects and at least let them know what they have to do to get "SPONSOR". Also, I think it would become a better experience for the projects if all the TOCs are aligned with the CNCF, TOC principles and process.


Sandbox projects waiting for TOC sponsors

( 7 Months ) https://github.com/cncf/toc/pull/261

( 8 Months ) https://github.com/cncf/toc/pull/255

( 9 Months ) https://github.com/cncf/toc/pull/237

( 1 Year ) https://github.com/cncf/toc/pull/189

( 1 Year and 6 months ) https://github.com/cncf/toc/issues/128

( 1 Year and 9 months ) https://github.com/cncf/toc/issues/103


Incubation projects waiting for TOC sponsors

( 3 Months ) https://github.com/cncf/toc/pull/303


Apologies if my words have hurt anyone. My intention was only to point out the unfair treatment and I am not suggesting that this may have happened intentionally. However, I do want to emphasize the flows in the existing process which lead to this type of issues.


On Fri, Jan 10, 2020 at 6:39 PM Liz Rice <liz@...> wrote:

I think it could be good to acknowledge the frustration.


Absolutely - acknowledged!

And believe me we really are working to try to address this. Getting the SIGs set up is intended to help us scale, and we are working to streamline the process, document it and make it more transparent, and set better time expectations.

As one example, the current suggestion we’re working on includes the project presentation for Sandbox being done to a SIG rather than to the whole TOC.

I really do feel bad for maintainers who have been trying to get attention to their projects while we’re working through this. Sorry.

Speaking of which, if you are waiting to progress your project’s proposal, please check its status on the backlog and let Amye know if anything looks wrong or is missing.

--
Liz Rice
@lizrice | lizrice.com | +44 (0) 780 126 1145



On 10 Jan 2020, at 15:23, Matt Farina <matt@...> wrote:

I think it could be good to acknowledge the frustration. There are open sandbox proposals that are many months old (including one from January a year ago). Sandbox projects are scheduled to demo in a TOC meeting as part of their process to find sponsors. Yet, the last public TOC meeting with quorum was in October. It's been a quarter since a meeting with quorum. If a sandbox project presents what sponsors will be there to see it?

When a project comes along that gets sponsors quickly, even without a demo, it's bound to be frustrating for people who are already frustrated while trying to work through the CNCF processes to find sponsors. I would be frustrated if I were going through this.

I would like to see changes, too.

While CNCF is different from Apache, the Apache Foundation does some rather nice things to help people. They've been around longer and have had time to put time into this. For example, going through their processes and getting help through it is all documented . It would be fantastic if the process, and how to get help, were documented more clearly. It's more than process documentation.

I also wonder, what would make a good CNCF project? I'm not sure that's entirely clear to everyone. If the basics were documented it would let potential projects self filter and it would give clarity to the process in the spirit of openness. Projects proposing themselves could show how they would be a good CNCF project to make it easier for TOC members to assess.

GitHub and devstats look at how quickly a project responds to issues and PRs. Developers like to know these things about projects. If the TOC and the supporting system around sandbox projects were to get easier and more efficient for everyone, I think, it would be a good thing.

Just my 2 cents.

- Matt Farina


On Fri, Jan 10, 2020, at 4:38 AM, Alexis Richardson wrote:

Vinod

The reason I am happy to sponsor Contour is because my team has used it and think it is of a very high quality. I do not need to see a presentation to reach that decision. Regardless of what level the project applies for.

Your comments about the TOC members deciding to sponsor at Sandbox and then finding out the project is applying for incubation, and drawing some sinister conclusion, are mistaken and should be withdrawn.

You make a number of other comparisons with keycloak and other projects. These comparisons are incorrect.

If contour is to be accepted as a project it will follow a process and, so far, it is doing so. For example please note that TOC sponsorship provides no guarantee that a project will pass DD for incubation. In fact, at incubation level the purpose of sponsorship is to get permission to move to the DD stage.

Alexis




On Fri, 10 Jan 2020, 01:26 Vinod NA, <vinod@...> wrote:

I also agree with Gerred about the recent submission. Many of you may have missed it as the project got sponsored super fast.

Every project coming to join the CNCF family should be treated fairly. The TOC should consider the fact that they are willing to donate their project to the CNCF foundation and not to other foundations.

Quoting Chris "TOC members are expected to act in the interest of CNCF and not their employers". I also think that TOC members should act in the interest of CNCF, not in their personal or their employer's interest. The TOC membership should uphold the CNCF and TOC principles.

I have seen different projects treated differently during their submission.

I am not against the following project joining CNCF and I believe more projects should join the CNCF family. I am just unhappy with the partiality.

For a recent submission, the TOC members got too excited and sponsored the project, without even any presentation and not completely reviewing the content of the pull request. Only after sponsoring, the TOC members have realized that the project is asking for an incubation maturity level and they thought it was a sandbox. I don't know what was the urgency to get this project sponsored, compared to the other ones which are waiting nearly a year and one even got rejected after not having a sponsor after a year. Now TOC has instructed the SIG-network to review it. I don't understand the purpose of this review. This is like a group of judges already made a judgment and then they're requesting the police officers to investigate it.

When Keycloak requested to join as a sandbox, the TOC was concerned about the governance and the team responded with their open governance and published ( https://github.com/keycloak/keycloak/blob/master/GOVERNANCE.md ). Even though the project team has only asked for Sandbox maturity, the TOC was considering it like an Incubator/Graduation project. The project answered the questions and TOC didn't ask any further questions and didn't mention which CNCF or TOC principle Keycloak didn't meet, it was just rejected saying no "SPONSOR" after waiting a year.

Keycloak is already used by CNCF member companies. I don't think the decision to reject the project without even accepting it in the sandbox level is in the CNCF community's best interest.

More details will be added in this GitHub issue = https://github.com/cncf/toc/issues/331

On Fri, 10 Jan 2020, 10:57 Liz Rice, <liz@...> wrote:

Sorry, I am missing something - which projects are proposing to skip the process? And (bearing mind the TOC have to sponsor / vote) do you see support from TOC members for them skipping the process?

--
Liz Rice
@lizrice | lizrice.com | +44 (0) 780 126 1145


On 10 Jan 2020, at 03:57, Gerred Dillon <hello@...> wrote:

Combining a few messages here -

The motivation for the increase makes sense. From a multi-vendor control standpoint, I will move to +1 NB on this particular issue.

That said, I'm sitting on a draft of collected thoughts, of which I will refine and post tomorrow - but in short I feel like change does need to be made, especially in light of other projects that proposed in the past days to skip the process demanded of projects included in the CNCF. This felt like a very clear violation of responsibility to the members that make up the CNCF, it's governing bodies, and those rely upon their decision making processes - and it's been made clear that without someone concerned about it, existing processes are potentially too easy to short-circuit.

On Thu, Jan 9, 2020 at 10:36 PM Matt Farina <matt@...> wrote:


To add a little more context...

The TOC is expanding from 9 to 11 members and a single company (or group of companies under the same umbrella) can have 2 members on it.

The current sandbox process only requires 2 TOC members to sponsor a project. This means a single company with two members is able to add any sandbox project they want.

The CNCF charter notes:

The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects


If the CNCF processes allows a situation for a single vendor to have the ability to add any sandbox projects they like is this enabling vendor neutrality and the charter would like?

An argument has been made it's not so the TOC sponsors should expand to 3 to require multiple organizations to be involved in sponsoring. This is what expanding to 3 TOC sponsors gives us.

Many projects are waiting almost a year to get a “Sponsor”, and others get rejected after a year without getting a “Sponsor”.


This must be frustrating for the people working on those projects.

I would like to see the TOC make some changes to address this problem. A clear documented processes and methodology. Something people on the projects can understand, follow, and depend on.

On Thu, Jan 9, 2020, at 11:42 AM, Vinod NA wrote:

-1 NB ( I am not in favor of sponsoring concept at all )

I think sponsoring will lead to "King Makers" situation which is against the TOC principle.

I don’t agree that the CNCF sandbox entry barrier is low. Many projects are waiting almost a year to get a “Sponsor”, and others get rejected after a year without getting a “Sponsor”.

I don’t fully agree with the concept that all sandbox projects should graduate. Sandbox then won’t be the ideal name for this stage then. Ideally, all projects should graduate and the CNCF should build sustainable ecosystems for it but there are many other factors that the TOC or CNCF can't control. Projects may go to archives from any stage. The "rkt " project is an example of it.

I agree that the TOC review shouldn’t be a tick-the-box exercise. TOC should make the judgment based on facts, not based on what they like or dislike. A TOC member won’t necessarily get enthusiastic about a project if he/she knows very well about that project's domain and technology stack. Also, the TOC does not pick a “winning stack” as per the TOC's operating principles document.

I have opened an issue in the TOC repo with more details, feel free to comment your thoughts there.

https://github.com/cncf/toc/issues/331


On Thu, 9 Jan 2020, 16:24 Liz Rice, <liz@...> wrote:

Hi Gerred,

I wanted to follow up with a few thoughts on your comment here.

Although the barrier to entry for Sandbox is intended to be low, we want to make sure that the projects that come in have a good chance of making it to incubation and graduation. Potential sponsors from the TOC should have confidence that the project is on the right path towards those criteria. It would be doing a disservice to a project if we were to accept it without that confidence.

Acceptance to the CNCF at any level should never be just a tick-the-box exercise. The TOC should always be able to exercise their judgement and discretion. At the Sandbox level, if there aren’t enough TOC members with the confidence and enthusiasm in a project to step forward as sponsors, then it doesn’t get accepted.

I hope that helps,
Liz

--
Liz Rice
@lizrice | lizrice.com | +44 (0) 780 126 1145


On 28 Dec 2019, at 06:07, Gerred Dillon <hello@...> wrote:

-1 non-binding

i'm not thrilled with how the sandbox has already changed without a controlled burn rate, i disagree with this motion without other changes to the sandbox process happening. kudo has already been given -1s on sandbox inclusion based on incubating/graduating requirements in private as negative votes for inclusion -- despite communication that these weren't requirements. sandbox is either inclusive or it's not, and i'd rather inclusion at this stage, given there are no marketing expectations or official endorsement of these projects by the CNCF.

On Fri, Dec 27, 2019 at 4:24 PM Thomas Mclennan <Thomas.mc@...> wrote:

+1 non-binding










3461 - 3480 of 7555