 OK, of your life. Good. Shall I kick things off, and then you folks can take over? So this is Alexa speaking. I'm the TOC representative, along with Michelle, for this new CNCF SIG app delivery, which is forming. It has not fully formed yet. On this call are some initial volunteers from the community who hope to participate in getting the charter into shape. And some of you may have put your hat in the ring for being a chairperson. I believe, Winston, correct me if I wrong, we ended up with three chair seats that we're aiming to fill. Is that right? That's the general model, I think. I don't know if any changes were proposed for this particular SIG, but the general model was three chairs. I think we are vanilla. So actually, this is a good opportunity for me to ask everybody on the call if they understand what is expected around the chairs, and if this is all surprise to them, if this is all brand new to you, you should say so. We can talk through how it works. And Michelle posted a form to fill in on the new email list that you're all on, I think, a little while back. So can I just ask everybody if you're aware of the chair system? Hi, this is Cornalia from Box. This is my first SIG, so I love to make a summary of what that means. Okay, great. Quinton, do you want to talk us through the mechanics? Yeah, it's fairly straightforward. If you're familiar with Kubernetes SIGs, it's not that different from a point of view of leadership. So the idea is that there are typically two sets of tasks that are required to make these SIGs effective. The one set of tasks are very deeply technical and require typically quite a lot of time. In the case of these CNCF SIGs, those might involve reviewing code, digging through repositories, testing systems, this kind of stuff. And people with strong technical skills in the particular areas are required for that. Then the other set of tasks are, I don't mean them to sound any sort of less important, but they're more of a sort of an administrative nature, a leadership nature. So people making sure that all the stuff gets done on time, that meetings get held properly, that the right people are there, and that we're necessary if there are disputes that they get resolved in a sensible fashion, which require a significant amount of technical understanding of the domain, but don't necessarily require the same amount of detailed understanding and perhaps less time consuming. Does that make sense? Thank you for the overview. Okay. So if you are still thinking about being a chair and you'd like to put your name in the ring, and you haven't filled out the form, then please fill out the form. If you can't find the URL filling out the form, then you can post on the list or email me and Michelle directly. I was just proposing a change, if you simply made it. Okay, that's fine. Just so long as people can find the form, that's the main thing. Yeah, great. I think I just put it to the dock, so somebody has to accept it, I think. Oh, shit, okay. I'm not sure if I'm actually allowed to accept it. I think Michelle has to. Oh, okay. Sorry. So let me see if I can do that in a second. Secondly, let's move on to the charter itself, and I can talk a bit about the process here. These charters are individuals of the SIGs, the hope is that they follow a sort of similar pattern. They're supposed to be agreed by the initial community and reinforced by a combination of the SIG community itself acting normatively over time, as it calls suggests, but also with participation and interaction with the TOC, which can be mediated by myself and Michelle, but can also be direct. So once we've got up and running, the chairs and the community will have many interactions, with all of the TOC, and through that process, we'll get to a place where we have clear goals that we all agree on that are adding value around this particular segment of the market. Now, we want to get this charter into a place as soon as possible where it can be voted on, which means that it will be presented to the voting TOC on a public call, and it will be asked whether or not this is ready for a vote, and if people say it is ready for a vote, then a vote will be called, and it will need to be approved by Corum, as of the charter for the SIG, and after that, we're off to the races. I don't know whether the chairs need to be elected before or after that, I think they're basically decoupled, but we would like to have chairs voted very soon to align with kicking off the group officially as well. So it would be great, therefore, if we could get this charter into shape where it can be voted ASAP. Now, we need for that to happen for somebody to volunteer to be the chief editor of the document. Would anyone like to be either the chief editor or one of the two or three editors who get it into a readable form, taking into account all these lovely comments on the right-hand side? Yeah, I can take care of this if Michelle gives me the right access. Okay, this is Doug, it seems like it might be best to have a couple of people sort of have offline meetings to discuss each comment and stuff and sort of get agreement or consensus among those groups and then you can approve or reject the comments appropriately. And I wouldn't mind volunteering for that. Anyone else want to volunteer? Yeah, you have the two of us then. Yeah, I can be involved there as well. One caveat, I'm leaving for two weeks at the end of next week, but I'm available till the end of next week and then gone for two weeks. Well, if we can hopefully get this into at least a de-commented form by the end of next week, I think that'll be great progress anyway. So maybe the three of you could huddle offline to do that. Thank you. So why don't we go through the document together now, piece by piece and we can make sure we understand what it's saying, have discussions on points where there appears to be contention. Alice, do you want to lead us through that? Can you post a link to the document on the chat for Zoom? Alexis and Alois, just one suggestion given that Alexis only around for another 15, 20 minutes. I think that the main question that hasn't been answered yet is around whether the scope includes development or not. And I think it might be worth discussing that first and then going on to the other. By development, do you mean like IDEs and tools like that? Or do you mean other things? Yeah, I mean, what developers do? Like writing code, testing code, checking it in, deploying it, all that stuff. Right. Okay. I think that those are questions which we can certainly form a view on together, but it would be as they are big questions as I see Doug is posting about Paz in the chat as well. Whatever initial view that this group forms today, we should make sure that the people who are on the mailing list and Slack channel for the SIG as it is today have a chance to contribute and are aware that this is an important question that we're discussing. And secondly, I think we need to surface it to the TOC as well a little bit because these are kind of major strategic matters. But as a first step, yeah, before we go into the line by line, does anyone want to advocate strongly for or against developer tools being in the app delivery SIG? Part of why I'm involved in this working group is that there's a lot of gaps in our company in terms of where some of the things people are writing like Helm and other things start and where you actually have a working system. So part of my interest is working on that and I think it would involve at some point, completing the solution, at least what Kubernetes delivers to provide this. I don't know how we get to that without some sort of a development code or something. I guess maybe a good question to ask is, do we believe that stuff to be in scope for the CNCF? If it's out of scope for the CNCF, then we don't really have a problem. If it's in scope for the CNCF, but out of scope for this SIG, then which SIG is it in scope of? I think that's sort of, in my mind, the three questions we need to answer. One thing that we may end up doing with some of these areas is punting them into a subsidiary working group for the time being. So we're not trying to have too many SIGs at once to begin with. And there are things which are gonna slip out of the core charters of each SIG. So having them sort of tagged on the end of one of these SIGs in the form of a working group for now may be a good thing to do. But yes, I think starting with should cloud native, is there a such a thing as cloud native DevTools? And should they be part of the CNCF or something we can discuss and note down as a view at the top of this document based on this discussion? So does anyone have a strong view on that? Both of them are positive. You said, yeah, I want to work on this. Hi, I do. I think that if app delivery is about CI and things that you deal with a couple of times a day, that the development process where you're doing things many times an hour is a difference that matters, but also is clearly related. That it's the same thing, but done more often. And so yes, I think that app delivery being about how you get code into a cluster that you also want to do during development should fall under this chart. Right. Okay, that's a good point. So also Doug was plus one in the chat window and another person spoke forward. Does anyone want to offer a counter view? I'm not offering a counter view. So what I found very helpful, which we can also discuss on the mailing list. And I thought like on the major point, just started to write on these. It's a bit confusing because we have slack and the mailing list. So I started with the mailing list, but what would be actually deliverable speed? That's always helpful for me. I think that I want to work on something and differentiate a topic that's interesting. I think of, okay, in like three to six months, what could we actually have as an output of the working group we got in any topic? I think it makes sense to discuss it. But the way I would challenge it, what would be the outcome that we expect? Or deliverable, even if it's just a best practice document, doesn't need to be a standalone project or something. That's the way I would challenge it because otherwise it's part of the charter, but we don't know what we actually work against. Yeah, I put a fair amount of thought and detail, I think into the, and others as well. I was just the one who cleaned up the document, but the SIGS document produced by the TOC in the CNCF, sort of proposes that the primary responsibilities are one to educate end users and projects. So take all that information that's scattered all over the internet and condense it into more easily consumable forms. One form of those is white papers, the other one's presentation, other things. Secondly, is look at a sort of strategic view of the area. So if we believe the scope ranges from coding tools to CICD or whatever, I'm just making up words now, but whatever that scope is, what part of that do we want to have as part of the CNCF? Which parts do we want to keep outside of the CNCF? How do they interface with each other? Are we missing key projects? Do we think we need a CICD system, for example, whatever that may be? Do we need more than one? Answering all these questions, debating them out and answering them and coming up with a position that is recommended to the TOC who can then say, yes, we agree with you all, no, go back and do some more homework. We don't think that's a good idea. I think a target state for, you know, how you do application delivery would be a good starting point for us to agree on, I guess. I think, and I think, and people are writing tools in here, but I think it would be interesting to see how people have put together things around Kubernetes to do some of these things. And then maybe from that, you could infer maybe what a target state might look like or people might have target state like we do at our company that we could review and if other people have them and then maybe that could inform what that would be. And then you could go as far as you want after that. So during the last two CUBE comms and the serverless working group sessions, I kind of forced the audience to participate in a little bit of a birds with feather session just to get some input from them in terms of what they're doing with serverless or if they're not using it, why not? And it was actually really, really helpful for me to understand why more people haven't adopted serverless. And I think that the reactions I got also applied to containers in general, which is why I'm bringing it up here. And a lot of it was around things like they didn't know how to break up the model within the smaller pieces, whether it's for microservices or functions. They didn't know whether there was a sufficient tooling around getting their job done. And so I think that this topic sort of touches on those of that sort of concerns that I was hearing from the community. And that's kind of why I voted yes here is I felt like it's the CNCS job to help either produce or foster the production of answers to those concerns that what I was hearing from the community around how to actually make this stuff real. And that's why I go to death on this because I do think it's related to it. I think we have a reasonable amount of people who obviously vote for yes and those are going to contribute. And then there's a good point, also came up in the chat, especially the topic around development, local development, local debugging, as batches, how do you run your microservice with more and run those running in the cluster? But I think the agreement is overall in the beginning it's more as best practices and more as shared tool development practices across companies. And that would be valuable for people adopting it. Also heard that model is to micro-service discussion which must be a bit of a challenging topic. But I think the outcome overall is best practices and just having the collection I think makes sense. I think it's totally fair for a special interest group to have education material, blog posts, white papers, whatever it is. And I also believe it's helpful for people to have this in there. So let's, from that perspective, I'd say let's include it and also note what we want to produce in those areas so that people can jump in. Okay, one thing I've noticed, sorry, one brief comment, Alexis. I know that there is, so this is a fairly broad area if you go across all of IDEs and PASs and CI CDs and all sorts of other related technologies. And I know there's a concern that that may just be too broad to tackle as a new SIG. So one way of mitigating that is to say, over time, our scope is all of these things, but the first six months we're going to focus purely on one of them, maybe CI CD, which I think is probably one of the more pressing areas. Yeah, just a thought. Yeah, that's also the my proposal, I'd like to roadmap, what do we want to address when? Those areas where we're clear what we want to do, it's fine. Start there. Yeah. Yeah, I read app delivery to you, call CI CD. Not to us, I mean, at least at our company, we look at PAS layers being something different and different, then that's different than even the ID, so I mean. So another thing app delivery is very related to CI, I would prefer to see that we separate CI and CD with a clear boundary, because CI is more about how to shape your source code to a runnable image or runnable binary, but CD is more like how to shape your binary and image to real cluster and to running application, which has clear boundary here, which from this point with you, I think we may want to focus on the second part that in the CD part or app delivery part. I certainly agree with that, but I think others may have a different point of view. Yeah, we all think the common. I don't know, I guess the CI part of it to me is not, I mean, I wouldn't want to make it trivial, but it's not the critical part. I mean, it's more around how you build it and how you actually get it instantiated into a working application, so. Hi, this is Kunal. I have seen in practice at box that while CI and CD are definitely distinct, they do sometimes have very intricate relationships between themselves and feedback loops that have to be taken into account. So as an example, in some CIS, you can actually do a deployment in a sandbox environment. So there's a lot of correlation that happens between them. So even though we tried hard to separate those out, it's very hard to really draw a very clear hard boundary between them in my experience. I agree. Alexis, a question for you. So if one were to restrict this particular SIG to being purely CI CD, do you, all the other areas that have been discussed here, do you think those are not, don't belong in the CNCF in general? Or do you think they belong in a different SIG? I'd have them in different, I would have them in different SIGs. So I think this is an artifact of us trying to form some SIGs without forming lots and lots of them all the time. So I think for now, I'm happy with a sort of reasonably Catholic approach. But yes, if we did have the specification of just the CI-CD SIG, then I would be expecting other things to pop up elsewhere. I do think they're in scope for the CNCF at large. So I agree with the people earlier who were posing in favor of the idea of DevTools for the CNCF. Okay, so maybe a solution that keeps everyone happy, in particular yourself, because you are the TSC representative, is to have formal working groups. So the SIG covers all of the areas we mentioned, but it has formal working groups focused on specific areas, CI-CD being one of them, perhaps as being another one. And we explicitly focus on staffing the CI-CD working group first, and make sure that that is humming along nicely before we get distracted onto the other things, which perhaps it sounds like we think are perhaps less pressing. I think that would be one way of squaring this particular circle that I would support. Yeah, but also secondly, this point that we should definitely have separate CI-CD because especially the more you move to cloud-native, it becomes really two different disciplines. Yeah. Much different in a more holistic application, where more or less you're building the entire app and then ship it. So it's much closer together in a little microservice type of environment that moves more into the environment than parts that used to be, like take together later on part of the delivery process that you also see with best practices around the green deployments, canary deployments, these type of things. They can be treated very differently from building the actual artifact and how the artifact should behave. And also for us, we treat them differently. So we treat CI from CD, yeah, different things. What I just pasted in here, not to make the document even more crowded than Bessie, but I took this day one to the end operations model and maybe it helps us to say, okay, like because we talked about application delivery, to say, can we focus on these pieces and we definitely need further pieces? Just as a conversation story, not to take this as the final one, it was just... Okay, hold up. Hold on, Alois. I noticed that Michelle has now been able to join. Oh. So which is good, because I can drop off and I'm trying to hand over to her all at the same time. May I do that? Is that okay with everybody? I hope so. Okay, so Michelle, are you there? Yeah. Hey everyone. Sorry, I'm late. We started the call with a, describing what we're trying to do on this call, which is in a preliminary state still. These are initial members volunteering in the CNCF community to help set up the app delivery seg and get going. We hope to have future calls as well, of course, as well as using the mailing list and Slack. This call is currently being recorded and will be made public. The initial conversation was around the chairperson roles and a few people are new and were brought up to speed on what was going on there. And I reminded people that there is the opportunity to put your hat in the ring to volunteer to stand as one of the three chairs. And then Quinton talked people through a bit about the kind of template governance structure for these six that we've essentially inherited into this one. So then Alois added the link to the form that you created for chair nominations at the bottom of this document. After that, we moved on to a discussion about the charter. And I said that we have the goal of getting the charter voted through by the TOC as soon as possible. There were three volunteers to act as editors of the document. So they are Doug Davis, Alois from Denitrace and Quinton. And they're going to try and get some stuff done offline from this call in the next, I hope, 10 days. Quinton, I believe, is going away after that on a vacation. It would be great if we can get the comments off the document and get it into a readable form. I think that's the important first step. Then rather, I was proposing we'd go straight into discussing the charter, but it was pointed out there are a couple of quite big lumps in the carpet or elephants in the room, if you prefer that metaphor, around whether or not DevTools should be part of Cloud Native and thus whether they could be part of this thing and whether or not there's also the same question around Paz. So we've been discussing that since the beginning of the call and I imagine there'll be further discussion on that point. Henceforth, we should, I think, come to an initial view on these questions, write it into the document and advertise the question to other people who are not on the call, but in the group and also to the TOC who I imagine will have an opinion about what we want to do here too. Okay, does that make sense, Michelle? Yeah, thank you so much. Excellent summary, appreciate it. I'm going to drop off now and say thank you to everybody who's contributed so far. Thanks, Michelle, for joining and I'll leave you to it to decide whatever you want to do next. Take care, bye-bye. Thank you, bye. All right, so where are we in the discussion now? I think Ella was speaking. Do you want to complete your thought? Everybody's quiet. I think you're just agreeing that basically the DevTooling is in scope and the exact mechanism by which we do it is still TBD. But I think we're going to move on to other things like I suggested. The other, as you said, Elton in the room was whether PAS is part of it. And I just noticed someone else also added functions as a service and serverless as being out of scope. And I think we need to just talk about whether PAS, PAS or serverless or inner out of scope. Okay, great. Let's talk about PAS. Quinton, I know you had thoughts around that. So you want to share your thoughts around PAS being inner out? Yeah, maybe without being too vague. So I have a, whoops, feedback. Sorry, my Wi-Fi broke. That's okay. I think that everything that is in scope of the CNCF needs to be in scope of one of the SIGs. And right now we have, I think it is seven SIGs. And I think we need to, like if something that exists that we believe to be in scope of the CNCF, I think it should by definition be in scope of one of those seven SIGs. If that SIG decides that it is too big and has too much scope, then I think that SIG should elect to split in two and create a separate SIG to cover some subset of the area that they cover. So that's the general model I think makes sense. And I think what we have come to some kind of consensus on, or certainly Alexis agreed with it just before we joined Michelle was that in this particular case, all of this stuff that developers do from designing and writing code to testing it to pushing it through checking it into revision control systems. And the whole pipeline by which stuff eventually ends up in production is in scope. For this SIG, the concern was that it was too broad and that we would get perhaps defocused where perhaps there's a perception, I think that CICD is a small but important and urgent part of that process. And perhaps we should focus on that first. One mechanism which Alexis supported was to have working groups, focused on those specific areas. Cause clearly IDEs are related to but quite different from remote debuggers or PAS systems or CICD systems. But these things all overlap at some point, they all connect together. So I think that's where we got to. Okay, a question, what specific projects are you referring to that wouldn't have a home if PAS was out of scope? I wasn't actually referring to specific projects that we have today. I was more reflecting on the fact that the CNCF is there to encourage use and successful adoption of cloud native technology. And part of that is providing people with knowledge and technology to make that possible. And I think we're missing some of those things at the moment. And it's a question of strategy as to, do we focus on building blocks and let vendors tie the building blocks together into products? I don't think we've sort of answered all of that stuff yet, but it seems that that problem is in scope for the CNCF and hence in scope for one of its SIGs. Probably this one. Yeah, the thing about PAS is that it encompasses lots of different components that work together to help this like workflow. And that might overlap with other SIGs like for example, like anything to do with monitoring and observability. So how do we deal with the fact that a PAS is not just something that's maybe something smaller, like it's not as well-scoped as developer tools or CI CD. It just ranges a bunch of SIGs. So that's, I think when Alexis and I were talking about this earlier, we were just concerned that PAS would overtake everything. But if there is a plan in place for us to focus on other types of things in working groups first and kind of punt that conversation until we come to a real life example, I think that plan makes sense. Okay, good. Yeah, I think I agree with you. As with regards overlap, I think we have that problem with all the SIGs and we just have to accept that there are, when you have a distributed storage system, it has networking and so therefore, there's an overlap there. When you have a distributed storage system, you have security, so there's overlap with a security SIG. And we just gonna have that all over the place. And I think acknowledging where those overlaps exist and just dealing with them sensibly is the approach I've suggested. And in the charter for the storage SIG, for example, we called out exactly all the overlap areas we were aware of and described briefly how we plan to address them. Okay, awesome. I mean, PAS feels like a large enough category that it could necessitate its own SIG. Could we not try to push that along? I think we should think about that when we come to that problem. But maybe acknowledging that, hey, we may need a new SIG, we may need something later down the line to iterate on. Makes sense to me. I don't wanna pre-optimize here and just make a new SIG for it. Especially if we don't have any projects at the moment that fall into that category unless I'm forgetting something. One of the things you have to also be a little bit concerned about is, and I do agree PAS can be kind of a large thing, but one of the things that I'm seeing in the industry today, especially with projects like Knative, is you're getting a very strong blurring of the lines between PAS, CAS, FAS, serverless, all of them. And what you'll see with something like Knative is it sort of brings them all together into one and says, I'm not gonna necessarily force you to pick a label, right? Just what are the functional aspects or functional characteristics you want of your container, right? Does it scale? Does it not? And that kind of stuff. And so I think trying to say, we're gonna have a PAS SIG, is then gonna ask the question of, okay, well, then do we need a container as a service SIG or a function SIG? And how do you force someone to pick something to live just in one of those categories? And I think that's gonna be really challenging. So I'd much prefer to start off with saying, we're gonna manage containers in general because that's the core of what Knative is all about. If for some reason down the road, we feel like there's something unique going on here that is worthy of sort of pulling out on its own and whether that's PAS or something else, then we can look at pulling it out. But I'd rather start off with the assumption that we're not gonna necessarily force people to make, what some people might view as sort of artificial distinctions between things into several little categories when we don't necessarily have to yet until we have proof that we need to. Does that make any sense? Yeah. I agree entirely. And that was the view that I put forward in one or other of the documents is that until you actually understand the space properly and until you actually know what these words mean and where they overlap, it's very difficult to draw those boundaries. So I would prefer to have a big amorphous blob which as you say is applications for cloud native and then tease it apart and figure out how it's actually done and how these various labels are used. I don't even think labels like PAS are used consistently. There are many, many things that call themselves PAS that are very different from each other. And so clarifying that in a white paper would, for example, be a very useful exercise at some point. Absolutely. I think this is a good transition into the FAS and serverless topic. So we do have the serverless working group. Have we discussed the future of that in this call yet? Nope. Okay, great. So Alexis and I were thinking that it would be great to pull that into that working group under the umbrella of the SIG for the short to medium term. And then as we evolve, like Quinton mentioned, as we tease things apart, what it means to run these applications or deliver these applications in cloud native environments as we progress, if that working group necessitates its own SIG, we can just go ahead and build that on SIG. That's the model that we had proposed in the charter. Do y'all have any thoughts on that? Yeah, as co-chair of the serverless working group, I wholeheartedly agree. Pull it in here. I don't see a difference between it. This is all just managing containers for me, so yes. Okay, awesome. Is anybody opposed? Is anybody with any objections? I agree with you as well. I think what we want to do here is really how we can push code from, can we get from code to code in production to eventually retire that code and serverless is just one way to do this. So I think it fits in well and the more different approaches we have, the more valuable. Excellent. Okay, so that was a pretty easy conversation. I'm feeling like we're all on the same page here about those two topics. Unless there's anything else, shall we move on to the next topic? I'm just looking at governance right now as the next topic. Okay. So we did talk about the relationship with the serverless working group and then if you scroll down, there's also the relationship between Kibran and SIG apps. So just to give a little bit of context here, I used to chair SIG apps. I co-founded SIG apps in Kubernetes and this was back then, we were working with the people who were developing the workloads API and we also had a bunch of people who were building tools on top of the API for Kubernetes in the same SIG. And what was nice about the SIG was early on, being in the same place for these two groups of people was beneficial for both parties because the workloads group got some feedback from their end users and their end users got to know what was about to happen, all the changes that were about to happen in the planning of this and they got to basically be a part of the planning of these APIs. So it was beneficial for both groups. Now it's evolved quite a bit. These APIs are almost stable. So I do see the evolution of SIG apps. Like I think in that evolution, some of the ecosystem tools that are part of that apps group, it makes sense to me for those to also be part of this group as well. So for example, Helm started out as a project under Kubernetes SIG apps. Now that project fits more under SIG app delivery. Does that make sense to everyone? Yeah, I totally agree with Michelle. Actually, I can see a very clear boundary between this SIG app. For my point of view, I think the SIG app is more focused on how we run the applications regarding multiple instances like workloads, like some instances related to all the strategy while the app delivery is more on the higher level to describe what the application, the deeper application to the platform. And the platform itself will use more like SIG app technology to run the applications. So I think it's very clear that Helm is moving to the app delivery more like the application for them. Okay, awesome. Does anyone have any other groups that we should include under cross group relationships? I think there's the CNCF CICD group. I don't know, they were fairly active a while back that we're gonna provide a CICD common CICD system for the CNCF projects. We should at least figure out where they are and what they're doing. And that seems like it would interact here. Yeah, that makes sense. Well, it's not a CNCF project. It is a Linux foundation project. I'm wondering about the CDF foundation groups in particular, Tecton. Yeah, that is actually the CDF. It's actually not related to CI, but this also raises a question that do we really focus on both of CICD or we just, you know, more focus on the CD part? I think that was the question that we discussed quite a bit earlier on in the call. I can't remember when you joined, but I think the decision was that it's all of it. Everything that is involved in taking code that has been written and getting it deployed effectively. And the CI and CD portion of that is a relatively small but important piece of that. Okay, that's clear. And even for the CD part, I don't know exactly about the CDF scope, but there is definitely also around deployment, best practices that can be shared. Like when we mentioned before, like blue-green deployments, dark deployments, can re-releases how to best implement them. I'm not sure how much the CDF really cares about those best practices rather than the tooling around it, but it's definitely a group that we should have a certain interaction with, whatever that means in practice. Yeah, actually, from my point of view, the CDF is more like the homes for the CD-related open source project, like Tecton, like Spinnaker, while in things like app delivery, we have more workers on the philosophy or the practices of how to trigger application, how to define the road strategy. We may be in the future, we may have some standard project like workflow engine, like road engine, which can be applied to every CD project. I think that it will be our goal. That's an excellent way to put it. I'm getting excited thinking about the kinds of documents we can come up with around that based on our collective experiences. The other thing I want to mention is that actually, there's a mission part recently in the Co-Native community, which is application definition. And if you have a help, if you have application definition, you may have something like a CDF, you may have Docker image, but all of these things actually have, you'll have gap from a real application. I think that it's also another goal that we may want to address or maybe discuss with CSXC, why are there CDF or any other things? Yeah, absolutely. That's one of the topics that's in scope for this SIG, so. It really makes sense. Definitely, before that. Thank you, whoever's sharing. I'll have a second, thanks. Okay, so we need to follow up with the, whatever happened to the CNCF-CID group. Quinn, did you have some time to follow up with that? Yeah, I can try. I think Chris Clemens in that crowd, Dan Cohen probably knows what's going on. Okay, feel free to loop me in a few lines. I know you're going to go on vacations, Dan, so. I'll click around and see what I can find out. Okay, thank you. Another important part of projects we should engage with is everything that's currently happening around operators. It's kind of weird that they're not really in any sort of CNCF project. I mean, the core goal of operators is to automate running apps on Kubernetes, so we would expect them to have a close relationship there, and I think we should at least engage with the projects there in whichever way, because they're kind of possibly like to seek apps to some extent because they're using the APIs, the API servers, and the API server there. I think operators per se is a topic that should somehow find its way into what we're working on here. I agree. There's some question whether operators should live in the CNCF, because if you have a specific operator for a specific technology, maybe that technology has its own foundation, and perhaps that foundation might want to own the operator since they're the most well-versed in that specific piece of technology. So there's some discussion around that, but I 100% agree that we should have those conversations and really take some initiative to figure out how we can get involved there and get some people, pull some people in from those projects. Part of it is actually to be tricky. I work with Xiang, so I know that Ray had actually had his own opinion on what operators should go into, which from my point of view is a little bit different from what we are talking about in the CNCF or the non-properties foundation. It's more like a production-level project right now. And actually from technical views, operator is actually another kind of controller of Kubernetes, so it's actually more related to the SIG app, what we actually discussed before, which maybe in the, it can be a corporate project of overcharging we are talking about, but I don't think it's actually being discussed at this part. Yeah, my point is also that it's less tightly coupled with what we're doing than most of the other topics we've spoken about. It's useful to know about, but not core. Also wonder whether, I'm not an expert on operators, but it seems to me that there's a relatively small amount of common operator stuff and the vast majority of the operator space is deep understanding of specific applications and writing operators that run them. And the commonality between those operators is not very great, but that's speculation on my part. Yeah, I would agree there. It's still hard to write operators to some extent. They are kind of useful for a lot of tasks. I think they're not at the level of simplicity that if you build your own microservice, you would write your own operator to run it. It wouldn't also be like the easiest way to go there. Still, I think as part of an application delivery sake, I really also want to focus on the operational best practices because I see a lot of the discussion, and also presentation is focused a lot on the CD part, so until the point that you ship something, but that's usually when the real fun starts when it starts to run out. So best practices from an operational perspective fit in there and that doesn't very touches the operators to some extent. Maybe just indirectly by saying, okay, these are the best practices how to run and manage services running on Kubernetes and see how this relates to this. But for me, it's important to go beyond, okay, we just deliver it. There's a lot of focus right now on the delivery, but that's on the operations piece, which is obviously eventually what you do most of your time when you're running out. Yeah, yeah. One of the example is that I will be very happy to see that in the CNCF sync app delivery, we can work out some practices of road strategies. And then all the other operators will try to apply these strategies in their own application management, which will be a good direction of how this seek cooperative is cooperative is the operator's community in this way. Yeah, that's an interesting point. For example, something to be working on right now that you more or less have a generic operator for something like the blue-green department, and you can just give it the service that it applies to. Yeah, exactly. But if not, everybody's reinventing the green department, which is... Yeah, they all have their own ways. There's no standard. There's actually a lot of things to do. That actually raises another question. Maybe I can ask it briefly. I know we're running out of time. But the whole concept of SRE, like the people who actually run these things and the additional sets of tools and processes that they use, presumably that all falls within the scope of the CNCF. We don't have a lot of that in the CNCF currently, but presumably it falls within the scope and could be seen to be in scope of this SIG. Or, I mean, right now we've got, you know, monitoring in an observability SIG. We've got these operators. We've got CICD, which falls into this SIG, but if you look at what an SRE team does at Google, for example, it's a pretty specific thing. And they have a bunch of tools and processes and best practices and things, and they're not really obviously covered by any of our existing SIGs. I guess that was a question to you, Michelle. Do you think that's in scope for the CNCF? Yeah, I'm still sitting on that one. I agree it's in scope of the CNCF. I think that we should keep an eye on that. I don't disagree. I just think it's tricky because I would wanna see some real-life examples of what those tools look like and what they encompass. But I agree, anything it takes to, anything that SRE team does, does, I can see that falling under this group, for sure, because you're operating your application, so. So my proposal would be to, as we discussed with other topics before as well, maybe to put it in the scope of the SIGs so that people know, okay, I'm an SRE, I have been running Kubernetes services for quite a while. I want to share my best practices. Who do I go to in the CNCF? They would know where to go to. But in the short term, like three to six months deliverables, you might not have any actual deliverables in there, which is, okay, we think that we could, if you want to work on this, come here, but right now there's no actual work plan for the next foreseeable months, which would be my approach and how to handle it. So that's why they would split up the scope and they deliverables, that should make it clear. But I think it's good to have it noted down that this is something we want to cover here. Yeah, let's put it down. I want to think about, like, a little bit more. Thanks for bringing that up, Quinn. Yeah, actually, Michelle just raised a very good point of view of how to evaluate if something is belonging to this thing or not. Actually, you can see there are multiple roles in the application delivery process, like there is developer, there is application operator, maybe there is some infrastructure operator or something more. So I think this thing is more related to application operator and also part of the developer themselves, not related to infra operators. It's a very interesting idea. Yeah, I agree with those personas for sure. So we have not even sure that it is necessary. Well, I think you could have it be defined by just one of those. So to use Google as an example, just because I'm familiar with it, you have developers who develop the stuff and are able to, you know, they do all the testing and they can even push it into production sometimes with SRE tools. Then you have the application SREs who run it, monitor it, get alerts, get working up in the middle of the night, et cetera, et cetera. And then you have infrastructure SREs who run, you know, the networks and the disks and all these kinds of things. And they're quite distinct groups and they have their own sets of tools and their own sets of processes. They're related, obviously, but they're very distinct. I'm not sure that all companies operate like that. In fact, I'm sure that not all companies operate like that. But as an idealized model, it's sort of works fairly well. I agree. Yeah. That's also, you know, I read a paper around these kinds of personas a while ago, but I feel like that paper is not really up to date anymore. So it'd be really interesting to continue this kind of discussion within this SIG around personas and roles and things like that. Because you're right, not every company operates the same way. They're distinct roles, but it'd be nice to kind of have some more discussion around what people are doing, what are some best practices for different types of companies, that kind of thing. Could you please just share the link of the paper or something? You can read it. Oh yeah, I'll have to dig it up. I was like three or four or five years ago. So I work for Engineering, which is a Paz company. And I was having, I had the same kind of question. So I'll dig it up. I'll see if I can find it. Okay, we have two minutes left on this call. So I just wanted to see if there are some action items we can talk about. So what do we think we need to be done here? I mean, we can continue this conversation over the next several days on the mailing list. Quinton, Lois, and who else volunteered to help edit the document? I did, this is Doug. Doug, okay, yeah, thank you. Do y'all plan to meet, or are we just gonna do this async? I think the plan was to set up a meeting to make up those notes. We just haven't done it yet. Okay, perfect. Okay, that sounds great. I think that some people, some things could just be edited in because they're not big discussion items. There is some typos and stuff that people were proposing. And my idea was for the bigger discussion items to start this right on the mailing list so that people can comment on them. So the next step is really packaging up what do we want to have on the, as a discussion on the mailing list and the other things, just get them all as into perspective of just minor editable changes. That feels like we actually resolved most of the disputes today. So it feels like most of the stuff that was not agreed upon in the current document with its comments has kind of been threshed out and agreed upon today. Yeah, I think the biggest thing is we just need right access to accept them. Okay, awesome. So let's go ahead and continue the conversation on the mailing list. If there is anything left, we'll edit the document, kind of finalizing package up so they can get it ready for the TOC. And I will keep tabs and continue participating in those discussions to help move it along as well. So yeah, I think that's a good stopping point. I just want to say thank you to everyone for showing up. I apologize for being late again, but I am so incredibly excited for this SIG. There's so much meat here, so much to dig into. So I'm excited about the white papers to come out and excited about the documents and these best practices. I think that's what I'm most passionate about. But yeah, I am really pumped. So thank you all for coming and we'll continue this discussion on the mailing list. Sounds good. I'll also share the video recording later today. Sorry, what was that? I'm also sharing the video recording so for people who couldn't join. Perfect. Excellent, thank you so much. Okay, thanks. Bye everyone.