 Good afternoon. You have made it to the services for projects conversations around like the maintainers conversations about projects in CNCF and I am Amy Skavarta Perrin. I am your director of developer programs, and this is Jeefy. Hello, my name is Jeffrey Sika, but literally everyone knows me as Jeefy. I am a developer experience engineer at the CNCF, and I am a wee babby because I've only been there for about three months. And I have been at the CNCF for three years. My very first KubeCon was 2016 in Seattle, so I've seen a lot of changes in the community, and my focus today that I want to be able to talk with both folks here in the room and those virtually joining us is what CNCF does for projects, what it looks like to be able to graduate from being part of like the sandbox, moving to incubating, and moving to graduation, what that looks like. So there's a lot of different interesting pieces in here, and Jeefy is obviously going to help me with like what pieces really matter for projects. And it starts from the place of CNCF is here to be able to help build community. And we do that by being able to be a neutral home for projects to be able to come and collaborate and work together as an open community that then feeds into other projects and how they connect in. Projects are overseen by the Technical Oversight Committee. Some of you may have already participated in the Technical Oversight Committee panel. That was earlier today, and I can certainly go into more of that as well. But projects are chosen by the TOC. They apply through our application process. You can apply either as a sandbox project, which is one level. You can apply as an incubating project. And from there, you can then move to graduation. So sandbox is the very, very entry-level. The focus for the TOC around sandbox projects is really, this looks interesting. We are interested in this from a cloud-native landscape. We think this has potential. We're not necessarily sure where it's going to go. A sandbox project isn't necessarily like a hugely vetted project. There's not a lot of due diligence that goes into it. But it's an interesting part of the landscape. We like what we see. We like what we're seeing from that community. We want to be able to bring them in and help support them. Incubating is where the bar comes in a little bit higher. All projects get to be able to come in and apply to be able to move from sandbox or to join as an incubating project. That's the point where the Technical Oversight Committee does due diligence. Technical Oversight Committee also engages some of the technical advisory groups to be able to do review of the projects, get a sense of where their strengths are, where their weaknesses are, what things they want to be able to grow into, and give them some advice on where to be able to move towards next. From there, projects that move towards graduated is the highest level of maturity. Those projects also end up with a great deal of support. Incubating and graduating projects, because this is a talk about services for projects, they get space at KubeCon to be able to give a maintainer talk. We've introduced some new things around projects being able to have project meetings, which are intended to be able to have space for roadmaps, space for just conversations in person. We do online project office hours to be able to have the larger community get a sense of what like what their end user community, they don't get to see all the time, gets to be able to work with. So I will pause there. JP, what am I missing? Marketing support between sandbox, incubating, and graduate. Yeah, that's a really good point because the point around sandbox marketing is sandbox projects don't necessarily get a talk at KubeCon all by themselves. They are more than welcome to be able to go through our normal process to be able to kind of join the general program committee, but we reserve a maintainers track session for the graduated and incubating projects. Yeah. No, that's a good point. Oh, yeah, also swag. We do have a cloud native store. There is a cloud native store. The incubating graduated projects get included in there. We also have stickers for all of our other projects. So now that I've given a whole overview of kind of like the levels, where else do you think people will want to know about projects? If I have a new open source project, what levels like should I consider submitting it to sandbox or should I consider submitting to incubating? I assume I can't submit it to graduate it automatically. So tell me like where in my project's life like what maps to incubating? What maps to sandbox? So sandbox projects are a pretty quick application form. The technical oversight committee reviews once every two months roughly. It's scheduled depending and really they're just looking for something that is interesting that has potential and sometimes like a growing community behind it. If it's brand brand new, I'd really suggest that you wait a bit to be able to actually submit it into sandbox simply because you really want to be able to make sure that this is a viable enough project that you're interested enough that would benefit from being in the cloud native ecosystem just as part of the projects. From there, if you're a much more robust project, you might consider coming in and incubating. Incubating is the level where it's gone through due diligence. It's gone through the technical oversight committee. It's gone through some technical group review and people are generally excited and engaged. It is not currently possible to come in as a graduated project, although I think it's probably in the documentation that you could. But in the three years that I've been here, I've never seen that happen and I don't think it's like it wouldn't be, yeah, it's not something that people are really focused on right now. Yeah. What else am I missing? Go ahead. So I'm a medium-sized project I would consider. So I have, say, 50 active maintainers and maybe I have some sort of a committee. How can the CNCF help me with any governance issues? Yeah. So we have a few different groups that can help out with that. Obviously, you and I and staff can help provide guidance to projects around, hey, here's some of the things that we've seen work as governance models in the past. One thing that the TOC definitely wants to look at is a governance that is open, that people can participate into, that you have a way to be able to become a maintainer of a project. And from there, you have a way to be able to promote maintainers into different ranks. And that's not usually as important, but being able to say, hey, we choose who's here. There's a very clear process for how to be able to come in and out. So yes, you can talk to us as CNCF staff. You can also talk to a particular TAG, TAG contributor strategy. You can also email the TOC list, the full open technical oversight list, and see who else has advice. So there's lots of different resources. Great question. So if my project that I submit gets accepted to the CNCF, who owns the project? And I'm kind of alluding to trademarks. And that's fine. One of the things that the foundation provides is being a neutral home for IP. That means that the project itself then is still controlled, and all the things that go on day to day are still really left up to the project. All we do is the foundation is hold any kind of trademark or wordmark or anything around that in space so that the project can maintain continuity much longer term. So and it usually takes some time to be able to make sure that all of the legal paperwork is crossed off. But this is one of the services. And one of the reasons you would want to be able to put your project in the CNCF. So yeah, there's some there's some legal things involved. Talk to me about what services we provide for communities. Oh, that is a good question. So again, it kind of depends on the level of project. But we provide a space for projects to hold weekly or really whatever interval meetups. And then we help signal boost all of those meetups. In addition to that, we through our tags will actually be able to network other projects or neural project with other projects to try and grow your contributor base, especially if the topic or, you know, the problem that your project is trying to solve happens to coincide with, you know, some of the other ones. No, that is a great place to be able to talk about how we facilitate collaboration. We've been talking for probably like 10 minutes ish, what questions are there from the audience that we haven't answered? And I will walk or I will repeat the question for the recording. Yes, that's okay. You are right on time. So for the recording, the question is, can you talk about the relationship between the technical oversight committee, the technical advisory groups, and how projects interface and what they can expect as part of do or work with them. So we've got seven different tags. Those tags report up into the TOC. They each have a liaison, like one named person from the TOC is the person that like is like more or less responsible for the care and feeding of that tag. And usually it's someone that has knowledge or interest or expertise in that particular area. So that's kind of like the direct lines of like how they actually work. From there, the project relationship is usually like subject specific. So like app delivery, tag app delivery, which meets on Wednesdays, 8 a.m. Pacific comes by like there's a huge variety of projects that report back into them. Projects can come by and do presentations for the tag to be able to get an idea of what things should we improve, what things are you seeing on our roadmap that maybe we're not thinking about, like where just getting feedback and kind of just general awareness, because the technical advisory groups are really meant to be able to expand the reach of the TOC in a way that like a single person just can't do. So that's our area for, well, someone's really interested in being a part of the community and they're maybe not attached to a project directly, but a tag might be a really good fit. And they could be, unlike maintaining a project, which can be a lot of work, a tag can support pretty limited amounts of volunteer time and also lots of volunteer time. It really depends on your own kind of availability for that. What have I missed? So, if I am a project or, you know, how often do I interact with the TOC once I've been accepted, what can they offer me? So, from the Sandbox project, we've tried to be able to limit it down to just like a really lightweight annual review. And it's really just, it's a series of questions about like, hey, how you doing in there? I'm paraphrasing, there's a whole template for this. Hey, how are things? What things are you working on? What things do you wish you had more time for? Because that's always the case. And what can we do to help? And we've now changed the process within the Technical Oversight Committee to have this be a public and open meeting. Each project gets one slide and there's a technical oversight sponsor just for that one meeting who spent time being able to look at the project and kind of give them some recommendations on where to be able to grow. Because the idea about being in Sandbox is that you're trying to grow the community and you're trying to be able to expand things out. So, that's where you can expect from a Sandbox piece. For incubating and graduating, we really only have like a lot of interface time and a lot of interface time when they're trying to be able to move levels. So, good question. What other questions have I woken up with that particular answer? And feel free, this can go around, I'm sorry. So, one of the things as part of like interacting with a lot of projects, I'm more of a consumer of a project and very occasional contributor. Hence why kind of the tags and the like the TOC and stuff is appealing because I like obviously would have lots of feedback and things that like I want to see the community thrive. So, for instance, like testing, working with a lot of these projects and then testing, say, using Linked or something, writing Envoy scripts and stuff and then being able to test those in a reliable way that's going to be actually indicative of their performance or whatever. I'm guessing there's a tag group for or there's going to be opportunities to give that sort of feedback partly from a consumer side but also, I don't know, from a just kind of general overview of the project. One of the questions I heard in that was what testing resources would the CNCF be able to provide for a project as a maintainer? Okay, so the CNCF has a couple different ways for you to get, oh yeah, yeah. Thank you, thank you, sorry. The CNCF has a couple ways to try and enable that. In terms of actually helping with building those tests, we really try to leave that up to the project. We don't want to be very hands-on. There is certainly people within the community and maybe even within tags that can help with that. I will say I don't believe there's actually a tags specific to CI, so there's room for growth. Yeah, but there are two main things that the CNCF offers. There's the CNCF community cluster quote-unquote. It is a set of resources provided by Equinix Metal and pretty much anyone related to a project can apply and they get an Equinix Metal account and go to town. You have to provide some info like expected cost, what you're actually looking to do, and maybe we can help you in other ways. On top of that, there is what's called the CNCF credits program. That will handle things like if you need specific resources in AWS, specific resources in Azure. The CNCF works with these public cloud companies and we have a set of quota that we can then grant down to the different projects as they request them. There is kind of a third thing and that is GitHub actions. We really recommend projects start with GitHub actions and as they may outgrow GitHub actions or as they may need those specific cloud resources. At that point, we then go through the CNCF credits program and then give them access to those cloud resources, but then still use GitHub actions in order to just have runners spin up in those specific clouds. So to answer your question for, hey, is there like a tag working group? There was in fact a working group focused on CI. My thinking, and this is a long time ago and I'm now going to look at Tim Pepper. My thinking is that it went more back into Kubernetes, more proper in being like a tag, like a CNCF thing. However, the answer is we probably have something related to it just because I can't think of it off the top of my head as far as like, ah, yes, pop quiz. It doesn't mean we don't have anything. So, okay. Lisa, I'm going to pause and see if we've got any online questions. Okay. Nope, that's perfect. Yes, here. Oh, God. Hello. I'm curious what if the CNCF has any recommendations or resources to help manage. You talked about if you need it like Equinix Metal, they'll give you credentials, shared credential resources, like how would a project maintain passing those around? Is that on them to do it? Is there recommendations or guidance there? I can attempt to provide an answer and then Amy may slap me. Okay. So normally when you would make this request, we would send you an invite. You're actually the one that already sets up those credentials. So we're not necessarily passing credentials to you via an email and then the project has to do its thing. Usually it is, give us the emails of the accounts of the maintainers that you would like if they are not already in, there's a giant CSV file called maintainers.csv, which is public. So you would just say, yes, I just want my maintainers of the project. We would invite all of them and then it's on those maintainers to handle those credentials. The thing where I'm kind of going off the rails is there's also this password solution that the CNCF is starting to use that we may or may not look at being able to offer to other projects. So separately, there is a service that offers free use. It's one password, I believe. Yeah, one password. Yeah, one password does actually have a program for just any open source project to be able to come. Yeah, right. You don't have to be part of the CNCF to be able to use it, but that's one of our recommended solutions because obviously this is a challenging problem. You want to be able to have passwords in a safe-ish way, but also in a shared way. And that's one of our solutions. See, I hope to answer your question there. Turning wheels. Tim. So all of our projects are starting to grow up. You've described the flow towards graduation. We have more and more projects coming back in the day. It used to be like, hey, chat with Amy. She can help you out. Are there tips and tricks and tricks, pitfalls that you would recommend now that we're sort of growing up into having a ticket-based system? How do we give a good-formed request to you? No, that's a really good question because in large part when I joined, there were maybe like 42 projects. And the level of service that we provide hasn't changed. The method by which we actually try to be able to take those requests has started to be a little bit more focused. We have a Jira Service Desk. That Service Desk is our preferred method for being able to get things because it takes it out of my individual email box and puts it into several other people's mailboxes, which is highly desirable. It means that we have accountability for being able to make sure that things actually do get done. And it doesn't mean your question was, what is a well-formed request? And my well-formed answer is anything that's in Service Desk that's enough for us to be able to understand what it is that you're asking and giving us a chance to be able to like, oh, I think I know what the, give me a little bit more detail in here. I'm not sure if I understand. So that's really our preferred method, but yeah. Also, within Service Desk, there are certain categories for tickets. So like legal, usually dealing with trademarks and whatnot, IT support if a domain name needs to change. And like that, just knowing where that ticket should fall into there also helps because chances are something legal specific is pretty much going to go right to Amy. Another thing that we are working on is there are still certain processes and documentation that say, ping Amy and not, and maybe, you know, try and ping. This doesn't exist yet. Projects at CNCF.io in order for it to, you know, go to this group mailbox that everyone that's working on projects can do. So any request is a well-formed request as long as it's not help. That would be fine too. Help with, and then being willing to be able to come work with us on that. But one of the other things that's coming up around like how to be able to do requests is we'll also help out with white papers. So if a project wants to be able to do like a case study or a white paper or something, and yeah, okay, we've had 22 minutes, so we are well on time. Excellent. We're willing to be able to help projects with like, if you want something more polished, we can also work with you on that. And that just happened to come to mind for like, oh, something we haven't talked about. Security audits. And security audits. As you know, in Kubernetes, Kubernetes has had security audits. That's another thing that projects can come and request of us and we can kick those things off. So it's just super helpful. Pretty much anything that you have a request for for your project, if you're already accepted, please let us know. We're going to do our best to try and make it happen. All right. You first, then you, then you. Sorry, it's just in the order I saw. Really simple one from that one. Is there some of the services limited to incubating or, you know, if I'm, if you are a sandbox project, can you ask for a security assessment or some services limited to certain levels or something? So as a sandbox project, you're more likely to benefit from being able to work with tag security than trying to be able to get like a full loan security audit. So what we will do as a sandbox project come in is try to be able to match the level of effort with something that'll benefit you like pretty quickly. So like being able to do like a docs assessment for a sandbox project rather than like a whole like here's all the things that you should be doing. What we will usually try to do is to be able because sandbox is meant to be a growing place to be able to like, oh, we want to be able to show value and momentum. We'll focus on being able to do the smaller pieces first. Doesn't mean that you can't request it. Doesn't mean that like we can't figure out a way, but I want to be able to use the maximum like kind of like resources that we have to be able to benefit you. TOC has directed CNCF not to be able to do a ton of marketing for sandbox projects. That's how it is. So we figure out what makes the most sense for a project. So that's kind of like the only boundaries. What else? Oh, I was going to move on. But another thing that I tend to think about with sandbox projects, though, is it's more like a tech accelerator. Like it just gets you in the community and it gets you more eyes. So yeah, you're next. I'm a relatively new SIG lead with any of the Kubernetes project. And something I've seen happen at least twice is a external project coming to us and saying, hey, we would like to donate our project to to Kubernetes. Well, to your SIG usually is what they're saying. And in one case so far, it was already very popular and we did we end up adopting them and they're now owned by SIG, the SIG that I'm part of. And we had another one more recently that the initial advice was just to keep to keep growing the community on their side. But how do we evaluate our requests like that as to whether or not they should join be adopted by a SIG within the Kubernetes project or whether it's more suitable to be an independent project. This one is all you. So this is interesting because Kubernetes as a project in and of itself chooses all of its own sub projects like all by itself. They are more than willing to be able to come ask for guidance from staff and all of that. But typically, like that I would consider that to be somewhat out of scope for me personally to be able to say like, well, yes, there's a lot of different pieces in here that are really valuable, but I'm not the arbiter and nor would I be over in like the CNCF proper like the TOC like and I work with them closely, but we're not the arbiters of like, should you consider it? However, I think the sandbox project guidelines are still helpful to be able to know because what is consistent over on the TOC side may also be helpful for being able to have the SIG Kubernetes work. And I think the biggest thing that we are looking at right now is really momentum, that the project has taken off, that it's actively getting and been merging contributions rather than like, oh, yeah, we want the thing, but like, oh, actively being able to work on being able to say, here's our contributor base, here's how we're growing, here's how we can make sure that people that are contributing will come and stay and what that looks like for the longer term. So I answered it out of scope and then in scope. So yeah, if the project is is like more tangentially related to Kubernetes and SIG, like if I could imagine that it would be used outside the scope of Kubernetes, for example, because it's more to do with containers or something, could it be appropriate for me to recommend them approach the CNCF as a sandbox project instead? Yes, you stole one of my questions, which was mainly just around like what the relationship was between SIG and TAX, like Cuban 86 security and TAX security, which obviously if you want to expand on, then you can do, but my other question was around like open standards and governance. So you've obviously got a lot of projects. And whilst there is a massive desire for leaving those projects to like be autonomous and being more like kind of an advisory group, obviously with like the TAX and things, I guess from the CNCS point of view, like, or at least I would hope, that just like common things like using semantic versioning and like maybe certain levels of quality standards might be, or just even like open standards of like interoperability between the projects might be something that is you're already doing or is desirable, or what sort of, what sort of the deal with like open standards and governance between you and the projects? I have opinions, but you should probably answer this one. And I have, he has opinions and I have data. I think you are best served by going back to look at like the CNCF principles that were written down, they're in the TOC GitHub repo. And that actually I think would help answer your question more around, because what I heard in your question was philosophy for how do you handle like what the path forward is? And I think the mission statement is going to be much more helpful, because we don't, semantic versioning is particularly like kind of nitty gritty details. But I think being able to look at just the principles overall will probably give you a better sense of where that goes. And there was a two minute warning or no, that was that was someone wanted to question. Go ahead. One of the expectations. Hi, my name is Andres Vega. I'm a maintainer of Spiffy Inspire. I'm also a security technical leader for the security advisor group as testament, having been part of a project that's progressed from sandbox to currently having a proposal to graduate. I wanted to add a little bit of color to your question. One of the expectations along the progression for the project not only to grow in traction, but maturity as to follow software development best practices. And we measured that against a tool from the Linux foundation called the core infrastructure best practices batch. The expectation within the sandbox period is for the project to attain a passing. Versioning is one of the criteria. There's many different areas as part of it. I'd encourage you to check it out. From when you enter incubation, the requirements get slightly more stringent. And it's encouraged to pursue silver and gold. There's only a few projects that have attained these, but yeah. Awesome. One other thing that I kind of want to hop in on with that. There is a new tool and by new, I mean the last like two, two and a half months called CLO monitor.io. You can go there and it right now pretty much shows checklist for projects. What can they do? Sorry. What can they do in order to improve their score? We're doing things like judging them against open SSF standards all the way to like expected governing markdown files, things like that. Admittedly, the score is kind of arbitrary, like A is 75 to 100, B is 50 to 70. But ignoring the score, it does provide a very good checklist that projects of all maturity level can use in order to kind of figure out what they need to, the more stuff you have checked off, the better you're going to be and the more likely you're going to grow. Thanks. As a sandbox project, are there any resources available around communication, like meeting platforms or email things? So by default, any project that gets accepted, they will get their own mailing list and they can request pretty much as many as they want from us. And then on top of that, yes, in terms of like meeting resources, Zoom accounts, there's the community.cncf.io that's also kind of an event platform and a meeting platform, and there's even more getting rolled out. And that's just like, it doesn't matter what level project you're at, you get access to all of that. Yes, that is also in there. Oh, thank you. What about things like private mailing emails and security lists and essentially an area for privileged information to be shared? Those mailing lists do have settings and pretty much every project has something likecncf-project-priv or-security. Those only go to the people that are in that maintainer CSV file that I was talking about. And even then, again, projects can request specific email groups for very specific people, not even in the maintainers. It's very fluid. So pretty much if you have a request, you can make it and it's five minutes, boom, you have an email. Was that good? Sure. How do we request those as a group? Service desk. If you have access to service desk or one of the maintainers of the project has access to service desk, you can create a ticket, just specify which project you're looking, you're from, what mailing list you want and who you want on it, like a proposed name, and then, again, it's pretty easy for us to cut a new mailing list and then go to town. It's all part of lists.cncf.io. Nick, did you have one? Not this week. We'll be back at our desks in a bit. Not this week. Yeah, pretty much. All right. I was just going to say that Contra is an incubating project. We've got like a distributors list and a couple of other lists for that sort of thing. The distributors list is for telling people who do stuff that users go on tour, if we have a CVA or something like that. So yeah, you can absolutely use them for more private kind of stuff. Checking for online questions. Okay. Nope. Oh, it's fine. I am perfectly happy to be able to take one last question. Sail us away. Do you guys have day jobs other than doing CNCF stuff? This is the normal stuff. I guess beyond that is the amongst like the tech and TOC community and stuff. There's obviously a lot of people who are contributing from various different companies and things. I guess as you as sort of permanent people of CNCF, do you like checking with people making sure like, I mean, burnout, there's literally a talk I think going on right now about burnout. Do you like checking with people? Do you have like processes and stuff like that? Or is it pretty fluid? You answer this first. I want to go after. So I think the question that I heard in that was how do you keep yourself sane with all of these things running around? Is that that's a fair, like, yeah. In large part, we are a very supportive team. You're actually missing the third member of our tribe, Ihor. Ihor was working out of Ukraine up until February and yeah. So in large part, we have a really supportive team that is really good about being able to say, all right, here's what we're going to be able to like work on today. This is our focus for the week. This is like the things that we're going to be able to like work on being able to accomplish. And in large part, both of us have been kind of on the road to KubeCon. Like we're focusing on that. So we have a pretty good understanding of like the ebbs and flows around that internally, externally. Like the TOC meetings, I'm on them every week. We get like a chance to be able to get feedback from what's working out in the community, what things we need to be able to improve. We try to be able to get to most of the TAG meetings, but it's we're working on scaling. We're working on scaling. I came from being a Kubernetes contributor. First, a completely independent one. I worked at the University of Michigan and they didn't really support my open source contributions at first. Then they did, but still I had a day job. And that's kind of how my mentality has always been until I joined the NCF. I already was like in the mode of trying to prevent burnout and checking in with other people. So like it is not uncommon for me to message like one or two people a week and be like, how's it going? You doing all right? Or if something crazy is happening in the community, just pulling a few people into like a Slack or Discord chat and be like, all right, did anyone need to vent? So like that's kind of how we keep each other sane like community members. So yeah. Because I do have a day job and I am a NCF ambassador and I've never worked for the NCF. And I think the part of your question that I heard was when you don't work for the NCF, you know, how do you manage that? And I want to say, you know, Amy and Eora have been incredibly supportive with the ambassador program. There are monthly check-ins with us and then we check in with our communities. And it's just been a great resource for us. So definitely leverage these folks who are, you know, focused on the community and the NCF. And they're incredible. I mean, like when I Slack Amy, I get a response like so fast. It's ridiculous. I don't know how you do it. But they're incredibly responsive and they're just really warm and great people that really, really care about the community. So thank you for all the work that you do and all the support that you give us as community members and ambassadors. Thank you. And that completes our talk. Thank you so much.