 Alright, welcome everyone. It is July 31, 2019. This meeting is being recorded. This is the CMCF SIG app delivery call. Today on the call, Alexis and I would like to discuss number one, the charter and finalizing the charter, talking about any last points that we want to discuss before we send it off to the TOC to get voted on. And then the second thing that we'll discuss is just like answer any questions around being SIG chair. That application is open. We encourage anyone who is interested to fill out the application. So I'll paste in the relevant links here in a second. Yeah, if you are not speaking, please go ahead and mute. And if my background gets annoying, let me know, and I will mute too. Okay, I'll share my screen with the charter and then we'll talk about the comments that are still on the charter one second. Can everyone see the charter document? Yep, I can see it. Okay, great. Alright, so the first comment that we had, Liz Rice, who chairs the TOC, had a comment around listing the current projects. So we had some of the projects listed in the charter originally, but I think they were taken out. But I think it was Alice who, yeah, it was Alice who mentioned that we could add some related projects in this sample list of in-scope items. Yeah, I'll put that in there later today. Okay. The reason, by the way, why we took them out for everyone on the call, we had lots and lots of projects listed in there that somehow fall into some of the areas. And we could make this list endless like a landscape. So what we'll do, we will just put in a note on related CNCF projects. Obviously, there's more projects out there, but people just kept adding more open source projects. But I'll take care of this later today. Yeah, I think that's a great idea. Thank you. Okay. And then the second one, Gareth, you had added something around testing. Yes, actually, I just caught that I hadn't added it there. I'd suggested adding a line in the areas considered in scope. And I think someone picked that one earlier. I think like we had like designing, developing, bundling, deploying, configuration management, delivery, release management and operations. I think it's worth calling out like validation and testing. I think I put in the comment, I'm slightly biased. I'd hack on a bunch of open source things in that space. But I think as this, there are other things there. And I think it sort of goes hand in hand with developing things, testing things, you know, sort of. Yeah, I think that makes sense. We just didn't put it in there. So any objections? Okay. All right. All right, the projects. Okay, how do you see this working in those areas that have significant overlaps with other states? For example, do you see this thing providing tooling assessments of any projects in the same way that you can provide security assessment of non security as well as security projects might be worth saying something explicit to be scope the non management aspects of projects in the space is covered by other states. I'll see you want to go ahead and explain your point to that. Yeah, my point is, as we were going through the charter thing, the key difference between this second law and some of the other six, that this has a peer end user application developer as a refocus. So there will be overlaps, for example, a security space, but this is really related to application development on top of the other projects rather than building the core infrastructure technologies themselves. So I think the overlap is more than intended. Just the area of work might be different and rather complimentary to some extent, obviously these schools would think about how things should be used as well. But this is really how I see people building apps and we're using these technologies rather than how technologies like security scanners or even Kubernetes as it is built at its core. I think one of the things that like related to someone of the points in the mission as well, which was like to develop informational resources. I think it's probably worth calling out in the charter just to avoid later confusion. Like is that restricted to just CNCF projects, just open source projects or any projects? Obviously, a number of us here where multiple hats, like some of us work for software vendors that sell provided software, some of us work on open source things in that context, some of us work on open source things outside that. And so there's the risk that like, well, basically, there's not a risk there's a reality of all of those like guides carrying some bias. And I think it's just worth if that's not a bad thing, that's how we all make money and try to make things better. But I think it's worth calling that out in the charter somehow. If that makes sense. Gareth. Yeah, you say that again, but a few words. I'll try. So one of the outputs mentioned is like guidance white papers coming from ultimately the CNCF. And obviously we all any of the authors of that are going to bring some level of bias. I think it's worth calling out in the charter how we consider to like square that. What's the result? What was that? Who said that? Sorry, somebody responded. Okay, maybe it was just noise. I agree, Gareth, that it's worth calling this out. This topic of bias come up again and again and again when we discuss the CIGs and you know, the TOC as an organization, either the nine voted in people already have struggled on a few occasions with discussions around bias explicit or implicit. And I think it only gets more complex, potentially, if you start having these opt-in CIGs. So I think, you know, maybe we can't come up with an answer today. But I mean, we could have sort of some agreed standard practice for all the CIGs in the CNCF in which it is made clear that any outputs of a CIG are community-based outputs and not the official position of any one organization, including the CNCF and the Linux Foundation itself. They may be superseded by other things. They represent a set of opinions of people in the community who have spent time focusing on this problem. And you know, in order to, you know, if you really want to go one step further, you should list the names of the authors or yeah, you know, whatever is the right practice there. But I think that it is a reasonable consideration. It's something we'll have to learn how to deal with over time. Yeah. So do we want to start by adding a section in the charter? I'm not sure with that section. I think it's, sorry to interrupt. I think this is one that the TOC has to figure out as a general thing for all CIGs. But Gareth, if you want to suggest some language, email it to Michelle, myself and Liz. We can take it to the other TOC folks or just put it on the CNCF TOC list as a topic. That would actually be a good thing to do. Yes. Yeah. Yeah. I agree with my general. I think it will be amplified when they're like with this things focus on guidance. That's just a good way of bringing it up at the TOC. And sorry, so since I seem to have the mic right now, may I continue with a related point. Recently, a couple of projects that are definitely would belong in this in the focus area of the CIG that do application definition work have approached the CNCF to talk about potentially, you know, being sandbox projects and so forth. And there was some TOC discussion about this which led to the conclusion that one of the one of the potentially useful things this group could do quite soon is take the survey document that you, Gareth, created originally and Brian Grant has extended since you created it and basically tidy all of that up a bit and provide a bit of a explanation of what the heck is going on in this space because there is certainly a lot happening in this space and we will not understand it if we treat all of those 95 projects as trying to solve the same problem. So I don't know what other people think but in terms of a strawman initial deliverable, it would be nice to see something in that area because, you know, people say what's the difference between Docker compose and CNAB and, you know, case sonnet and dot, dot, dot. It's been a fast-moving space as well and like that, like a lot of those projects that were quite very, very similar two years ago actually now no longer exist like for all intensive purposes that they were frozen in time at that point. So there's been a lot of experimentation in the space and fewer things that have broken out. That was also the idea to have criteria for certain, say, use cases and what tools should provide and that might tie in there nicely so that people cannot simply claim I want to, because one question that came up in some discussion we had was, okay, let's create a landscape for all the tools out there and every put renderer wants to be in every part of the landscape. I think we as a SIG have at least the chance to say, well, if you want to be in box XYZ, you have to provide at least these capabilities, not just claim as part of your product marketing that you're doing XYZ. So maybe like a survey like this or some type of definition, it's super helpful there as well and to that also relates to the topic of bias because if we at least can agree on what makes up a solution in a certain area with use cases should be supported and which functionality should be supported and we have an agreement on this with users kind of the bias that you otherwise might have on recommendations. The six areas considered in scope of the SIG are actually pretty good here I think. Like there are six areas there that's a nice like not too large, not too small number. Coming back to, go ahead Yara. Coming back to this application man's tooling, I think Alois hit on a good point whereas we just assigned the first donor that this tooling that we're talking about, you know, hits end users. I think we could go a bit further and say, okay, well we're talking about application management related tooling which, you know, we see from the perspective of end users is really broad so maybe application operators and application developers because when I read this section, you know, it's in depth but it's also very broad and, you know, a lot can fall into this particular bullet point. Would any baby be opposed to me adding that to the to this bullet point or do we want to talk about whether we want to add the end user point or it's really loud? Yeah, I think the list could be a bit shorter and a bit more condensed. I can take another I could take another stab at the call because some of those pieces could actually build could be put together like the debugging is definitely developer focus, deployment configuration, more of a DevOps focus, interoperating should be there anyways and could probably be put out there management because I can try I think to condense them a bit more and we had the target audiences in there before which has kicked them out because we thought they're implicitly mentioned by what we're doing so if we talk about why do we need developers but I agree that the list is a bit long and it can be pretty much everything or nothing. I'm not the biggest fan of this list Edo so I think condensing it down a bit makes sense. Okay, sounds good. Gerard, did I cut you off? Nope, I'm good, I think it might have been some background. Okay, all right, there are, let's see, we have the roadmap. Do we want to add the survey topic to the roadmap or do we feel like the, well the white paper is a very specific deliverable? Do we feel like that covers it? Alex, do you have any thoughts here? I think we should call it out as a specific item. Okay, would you mind adding it to the doc? I'll do it right now, yeah hang on a second, can you post the link to the doc into the chat just on the right here in Zoom? Thanks. So we've done, well is it like going back we did two things that are somewhat distinct. One was the end user survey, the sort of the application survey, that was, that covered lots of busy end user questions like what people were doing. Alongside that we did the whole like more landscapy big list of that horrifying spreadsheet of tools. So they were mainly separate in that one was mainly sort of book research and one was mainly an end user survey. I'm not sure if we're conflating those two things or viewing them as the same or viewing one as more interesting than the other. Can you share both as links? Maybe I'll dig out, give me a second, I'll dig out the links from the previous ones. Because we might want, I think we might want to update one both or I'll just be a few minutes but I'll come back in a few. While Alexis is writing that up I'll just go ahead and make the announcement that again the SIG chairs application form is available and the link is in the operation section of this. We're looking for three SIG chairs and all the information about what that entails is in the form itself. And so we'll go ahead and close that form tomorrow night. So it's Thursday 11.59 and so if you're interested please go ahead and excuse me, I'm on the mute. Does anybody have any questions? Hey I have a quick question of what's highlighted right there right now. Yeah so like um does that not cover something like the CNAB project? I don't know because the CNAB project can cover both infrastructure and application components. Right. So I think this is more like OCI type things. Okay, okay. Okay, does anybody have any questions around governance and how we relate to other bodies, organized bodies of people, groups of people? Can you explain like the difference between SIG apps really quick? Yeah, yeah. So you know SIG apps started as a place where tooling on top of Kubernetes would come to demo and talk to the what used to be a smaller body of people, smaller different people who were also working on the Workloads API because that related most to the application level tooling and so there was this nice feedback loop there. Since the Workloads API is now stable before it wasn't so it was necessary for all these people to kind of be in the same room to really be on the lookout for these big changes that had effects on. Now that's not so much the case so there will be some overlap with Kubernetes SIG apps. So some of the tooling may want to come into the CNTF SIG app delivery wherever it makes sense and we just wanted to recognize that here. We'll focus on end-to-end aspects of application delivery while Kubernetes SIG apps will focus on tooling that's specifically just related to Kubernetes. Terrifying. Yeah thanks. Okay. Any more questions? I'm going to check the chat here. Okay Gareth just posted the links. Let us know when you're ready. Again we have a Slack channel and we have a mailing list. We need to update this. Okay go ahead Alexis take it away. Okay you can accept my change now. Thanks. So are there any other changes in here that we need to discuss? I don't think so. Great. I still think that it'd be nice to condense the list. Yeah the application management related tooling is just it is too sprawly. Can you just get it down to five or six things? Yeah I'll get it down. Okay thanks. So what I also will do I will also look into the CNTF projects pieces and the CNTF projects that are related what they're covering and then condensing it down to also what they're working on right now because technically that will be what we're working on right now anyways. Yeah understood. So I think Alice it sounds like you are going to be the the last person to touch this document before it can be declared ready for broader review is that correct? Yeah I was anybody else was to change something but that should be the last change. I'll send it to the Slack channel once I'm done. Actually I would go straight ahead and send it to the both the Slack channel and the AppSig and also to the TOC list. Okay post it on the TOC that's the main thing is getting it onto the TOC list and saying that the you know first draft of the charter from the AppDev SIG is available for review. The next steps are following broader review will come up with a final version of the charter for a vote. All right and also you could say if anyone would like to schedule time on the main TOC calls to discuss this please let Liz and Chris and Amy know. I will. Thanks amazing. Lastly if you did edit this document and review this document please add your name to the talk where it says reviewed by. That's the blame section. Yeah thank you. Does anybody have anything else they want to discuss Alexis? Do you have any other items? No. Not everything I wanted. Okay then shall we call it? All right. Yes. Sounds good. Thank you so much for joining everyone. See you next time. Bye. Cheers.