 Hey, everybody, just give me a minute to get organized here. All right. Thank you, Chad. I didn't realize I got the date wrong. All right, let's start doing a roll call stuff. Clemens, are you there? I am, I am. All right, Dan Barker. Here. All right, Jim Curtis. Jim, are you there? Not yet, he's working on it. Are you there? Yep. All right, cool. Matt Rakeski. All right. David Lyle. Yes, I'm here. You're on. You're on either. What about Jim Curtis again? I'm here. All right. What about Jim Curtis? Okay. What about Thomas? I'm here. All right. I'm sorry. I'm always saying it the wrong way. Yeah, I'm here. Thank you. I apologize. Yum. Hey, I'm here. All right. I think that's everybody so far. Cool. Oh, Steve. Are you there? I'm here. Make the window a little bigger. Okay. Chad, are you there? Chad, you might be on mute. I'm going to have to sort of go back around to him. Lee, are you there? It's Jim Curtis. Jim Curtis. Okay. Hey, Jim. Hey, Dennis Lee. Hey, Lee. Okay, Jim, I got you. Yep. Hey guys, I'm here. It's Chad. Oh, hey, Chad. Cool. Thank you. And Mr. Mark peak. Excellent. Thank you. William. William, are you there yet? Ben. Ben, are you there? What about David Lyle? Oh, did I get you twice? Oh, sorry. Sorry. Okay. This is then I am here. Okay. That's fine. Give my regrets. That's okay. I'll, you, I heard you once. That's all that's necessary. Stanley, are you there? Hello. Sven. Yes. Thank you. Let's see. Klaus, are you there? Yes. Excellent. Rachel, are you there? Yeah, I'm here with Sarah also. Hi. Hey, Sarah. John Mitchell. Good morning. Hello. Austin, are you there? Just joined. Hi, Doug. Excellent. Hello. I know I missed somebody in this list. William, are you there yet? William. Is it the same person? Oh, yeah. Unusual. Usually he's there. Okay. John Mitchell. I got you. Right. Is there anybody on the call who I did not. Work with an asterisk. I think I got everybody except William. After you did roll call. I'm sorry. I couldn't hear you Sarah. Say that again. So yeah, I added Rachel and Sarah. You don't after you went through the asterisks. Oh my, I was never mind. Kathy, are you there? Yeah, I'm here. All right, cool. Thank you. What about Eric? Erickson? Eric, are you there? Yes. Can you hear me? Yes. Okay. Okay. All right. We're going to get started in just a second. So Mark Fisher. Are you there? Mark. I'm here. Yes. Thank you. Excellent. Last chance, William. Okay. What about Sean? I'm going to say it wrong. Feldman. Excellent. Yeah. I think I said fieldman last time. Okay. Tell you what, I think that's everybody. We'll circle back around later. So let's go ahead and jump to the agenda. Hey, Doug. Do you mind if I do a couple of quick introductions for some, for some newcomers. First off, super excited to have Eric Erickson from Nordstrom join the call. I've been going out and trying to seek some new perspectives to join this working group. People who aren't focused on providing infrastructure as a service specifically. So I've invited Eric, who is very popular in the service community in general and looking forward to his perspective as well as I think, is there anyone from Accenture here on the call? I think Sven's on the call. Yes. Yeah. I see him on the list here. There we go. Sorry. Yeah. Awesome. Yep. Yes. So Sven does a lot of serverless things and open source things over Accenture. And again, I think that they have a useful perspective that they could lend and excited to just, you know, have, have these new perspectives join the effort. That's great. Thank you. And welcome guys. Thanks. Thank you. Awesome. Thank you everyone. All right. All right. So let's jump right into the agenda. So couples, we still have some outstanding action items for people to do is please get when you get a chance, take a look at yours. I don't want to spend too much time there. Just another reminder for Kubecon face to face. There's a doodle poll. It's not that important anymore. Just want to make sure we can have quorum. I think we have 15 people right now signed up. So we definitely will have quorum there. I think we're going to have a meeting and it will be an official meeting. And as I said last time, I will set up a doc for us for people to add topics as we get closer to the event. I think it's a little premature to do that right now. So with that, let's jump into some PR work. So I added four to the list, which should be relatively straightforward. See if we can get these out of the way. I believe Rachel, this one, first one might be yours. Do you want to talk to it? I went to collect all of the things that are not the spec yet. I think we can add more here as we go. Very controversial, I'm sure. Any questions about this one? Any objections to moving these two documents? All right. Excellent. Thank you, Sarah. Easy enough. Rachel, Rachel. I'm sorry, Rachel. Sorry. Sorry. Okay. Next one is mine. This one, since we approved, I can't wish pure it was last week, but basically we revamped the scope and stuff. There was a suggestion to go ahead and remove the status section since it seemed to be duplicate or old. So I did that PR. So basically all I did is remove the status section. Since we now have the scope stuff. Is there any questions on that? Well, I just want to say for context for people who are new, that now the read me contains like the next steps. And then the high level goals, design goals over in the specs. So it's, this is really the second part of that. Yep. Exactly. Thank you, Sarah. Any questions on that? Any objections to approving it? All right. Cool. Thank you. Louis, I think this one's yours. You want to talk to it? I added tracing. I've been tracing. Let me hide the comments here for a sec. Yeah. So this essentially is adding a section into the, the use case document on event tracing. Essentially just to indicate that we need some mechanism being able to. Have a cover the case where we have a sequence of events that are result from an initial event and have some mechanism of being able to trace those events through multiple intermediate devices. Okay. Any questions on that? All right. Now there was one. I've seen a comment asking you to put a blank line in there. If that's none, obviously material change. So we can obviously do that before I actually merge it. If you don't get a chance to do that, I'll do that for you later today. I think I have admin access to make that change. Okay. Any objection then to accepting this? All right. Easy enough. Thank you. Austin, minor adjustments to the roadmap. Would you like to talk to this one? Sure. This is a pretty minor PR. Sarah did a great job of refining our roadmap to be oriented around versions instead of dates. And when she made that change, there was a couple agenda items that weren't under specific versions. They were in a section called additional items. And I felt it was important to put some of those items, those agenda items or action items in specific versions because some of them are pertaining to the marketing of this effort. And I think for example, you know, making sure that we have our marketing materials in place as we reach 0.1 is important. So anyway, I simply move those additional items into versions where I thought they were most relevant. Okay. Any questions on this? I think it's been out there for a while. I think last night you made some very minor editorial tweaks. Nothing substantial. So it's been out there for a while for people to review. Any questions or comments on this? All right. Any objections to accepting it? Excellent. Cool. All right. In that case, we're done through what I consider to be the easy PRs. Next. So, Sarah, you made a suggestion here to talk about the scope of the investigation for the roadmap. Before I, before I get to talk to your suggestion here, I do want to just point out that. I think it was actually last week's call. We agreed to this text in the spec already, which to me pretty well defines the spec. The scope of the spec itself. So go ahead and make your point though. I think when we agreed upon the high level design goals, we felt that there wasn't really enough specificity to, for example, answer the what is source question. And what I've seen happen in the discussion of attributes is that there are multiple attributes that combine together to achieve one of the goals. So if we don't refine those goals a bit more than, and deal with things one attribute at a time, you know, like we haven't really scoped the spec. And so I feel like the work that Clemens did on the usage scenario section would address that concern. And I think actually the, the description of the producer goes a long way towards answering a bunch of the confusions about what is source. I'd like to just propose that we finish that before deciding on any of the attributes. So we can have discussions about them and move the discussions forward where people feel that they are aligned. However, I would like to not address any PR for any attribute until that usage scenario is PR is committed. So I personally don't feel like that the usage scenario discussion is even doing anything to the scope of the specification. The scope of the specification is about us having common metadata and data attributes that help us to facilitate interoperability. And that's the scope of it. And I don't think we, we, we expand the scope and I'm actually not willing to go and take a step back to, you know, the beginning and talk about the scope of the spec again. But where I would rather go and start making progress because ultimately there's a bunch of people around here who are interested in writing code. And we're, I think we're, we're very close to writing code. And I think there's a growing consensus in the group that we are fairly close. So I would like to get to the point of us, you know, going through the user scenarios, which we talked about already this week for two hours and look at them again. I think there was plenty of opportunity to go and give feedback on this and then get to defining to go back to the real work. And then just talk about the properties. I just want to say that I think we were very close to the right code based on the spec in November before it was ever brought to the CNCF. And I very much want to write code based on a specification. And so I just want to address that point, but I think Rachel got a suggestion. Yeah, this is Rachel. I think that this, so the, the idea that we would be taking a step back to, if we become aligned on what it means to be interoperable seems like a mistake to me. Like the point of being interoperable is that we agree on like, this is the point that we agree. And so we have to, we have to start agreeing on things before we start writing code. So then let me ask the question back. What, what are we not agreeing on? I feel like so in talking to, so the, one of the reasons that we started talking, that we asked people to start making presentations about what they saw as like how they understood events to work is because in the conversation, people were using the same words in subtly different ways, which revealed to me to others that we were not, that we didn't have the same picture in mind, right? I think that, I think that the usage scenarios do a great job of making sure that we are aligned. It spells out exactly what we're trying to achieve, but like rushing, like rushing to that before we were, before everyone like agrees on this feels like a mistake. So I would say two things. One, we spent two hours on the usage scenarios and they ended up being largely agreed to. Like I went through all the, the, the feedback items, including the last ones that were found today. So. Yeah, I'm saying it's a good thing. So that's great. That's great. Beyond that, I don't think we should go and reopen any, any further discussions and get to work. So I don't understand. I don't understand what the hold up is. If we say that the usage scenarios discussion is the one that, that brought us there. What is that further objection that you're raising here at Sarah. So Clemson, I think there is a no consensus if we're essentially defining an envelope to an event and the event details are still in the event or we're trying to create an abstraction with a lot of the metadata. So I'd like to make a suggestion here. Cause I think I've heard several different things. One is someone was suggesting that we, we don't really work too hard or work too fast on the attributes until we agree on things like the usage scenarios. And I will point out that uses scenarios is the very next thing we're going to be talking about. So we are going to be trying to get agreement on that. The other point I want to make though is going forward, basically everything is done through PRs, whether you want to change the process where you want to choose a governance, you want to change the spec, everything is done through PRs. And this phone call every week, given the limited time we have, we can't spend time on this call and necessarily doing a whole bunch of abstract discussions or talking about alignment and stuff. Most of those discussions just for the nature of time have to be done offline. So if there are people who feel that we are not aligned on a particular topic, I would strongly recommend that we set up additional phone calls outside of this Thursday one to have those discussions and have the results of those discussions be PRs back to the working group for changes in some documents someplace. Because as I run this call, I am going to give priority to pull requests because that is ultimately what drives us our work forward. So Doug, we just accepted a small modification to the roadmap. The roadmap was agreed upon seven weeks ago. It has two bullet points. One is the design goals, which we agreed upon last week. The other is the scope of the specification. We're talking about that bullet point, which was addressed in a PR some time ago. And so it's, I believe that we don't have alignment on the scope of the specification. And that's fine. I would then recommend that you offer to host a phone call outside of this one to come up with a pull request to further clarify the scope as you see fit. And I thought that that's what we were doing with the usage scenarios. In my understanding, that section of the spec met this bullet point of the scope of the specification. Okay. Wait, wait, wait, wait. Then let's jump into 117 right now and start discussing it and see if we can get agreement. Is that okay? Well, I'd like to hear, does everybody else do other people feel that there will be additional things besides those usage scenarios necessary for that roadmap bullet point? Yeah, I think, you know, I think, you know, in terms of the metadata attribute, I think we're not quite in sync or done yet. I think there are still some scenarios that might need, you know, more metadata attributes there. And that, yes, and we can discuss those and people can offer PRs to add or remove attributes as we go along. So that's the nature of the work. Yes. Yeah. So maybe we will take, if we discuss the usage scenarios first, then we can ask that question. We can ask that after we have the usage scenarios discussion, you know, like before we move on to attributes that we all just agree that, yes, we have to find the scope, whatever that is. Oh, let's, let's have the use discussion. Let's have the usage scenario discussion and see where we land them. Great. Okay. On the usage scenarios discussion. On this particular PR. I want to time boxes to 10 minutes because I already spend, we already spent at least two hours in our two and a half hours on this, this week in a group. And on this section, I would like to hear the folks who have not been present in that, in those, in those talks to speak up and see what their, their opinion on this is. So what I'm doing here is effectively I'm, I'm in this PR. I'm grouping usage scenarios in four groups. First is I'm talking about. So first of all, I'm, I'm defining in the, in the first paragraph saying, this is what, what this is about. And it's users scenarios developer perspectives. The second is I'm making clear that I'm keeping the roles of event producer and event consumer distinct. That is to mean we're talking about a one way flow, but one application can always take on multiple roles concurrently, which including beef being both a pursuit producer and consumer of events, which means if the application wants to go and take this, what would find me here and model a bi-directional flow on top of it. And that's fine. It's just not the focus of, of what we're doing. So first applications, produce events for consumption. And you can go and read this yourself. I'm just going to highlight what needs, needs highlighting. What's important is, important is that events are typically produced related to a context that they come from somewhere. Or they are produced based on a producer chosen classification. I'll have some examples in the, in the following PR discussion. So I can, with pictures, but for a, for example, a temperature sensor room here, maybe context qualified by the mount position, which means where is it mounted in a room by room, by room, by a floor, by the building. That's something that's fairly concrete. And that's what I call context or it's purely abstract, like a sports result. And that's classified by league and teams. I'm also making clear that the producer, and that also applies to the consumer later, could run anywhere. It's a server or device. And then I'm also making clear here because we have some IOT folks that the produced effect, that the origin of the events, effectively the original producer matters and not necessarily the one who then ultimately renders the message as a cloud events message. So if we decide that our, you know, transport binding has a particular shape and that events need to be rendered in a particular way, that doesn't automatically mean that that's the producer of the device could quite well be that you have a device that sits in the middle of the road, where it only has, you know, payloads of 12 bytes available and that there's a gateway that then acts on its behalf, but that gateway doesn't play any deeper role in that relationship except that it just renders devices. And so I gave an example for that for weather station, for instance, and the weather station is the producer and then there's an intermediary which is affected the wireless base station. And that goes and does the rendering, but it really plays a middleware role, but it doesn't play a middleware role where it's something that we need to consider in a deeper way. Then applications, consume events. It's the next section for all kinds of purposes. I make an enumeration here, mostly just to catch most of the cases that people may be thinking about. And obviously also have the, some make it as broad as possible. It's not meant to be an exhaustive list. And again, the consumer might be anywhere. So we're not being specific about the consumers being several less applications. It could also be clients. And I'm, and here I'm starting to enumerate a few things that the consuming applications interested in and that drives requirements towards the producer. So for instance, they want to be able to distinguish events that the exact same event is not processed twice. They want to be able to figure out, but looking at an event where that event, what context that event is related to, or how that event has been classified by the producer. They want to identify the temporal order of the events relative to the originating context. If the device that, if there's a device that originates the events and it doesn't have a real time clock, then at least we need to give it away to go and say, give some sequencing to the, to the messages. Not all temporal order is based on UTC wall clock, but UTC wall clock is obviously an order and criterion that also works. And then we want to understand the context related detail information carried in the event, which means there's data that we want to understand. And to understand the data, we need to know what shape it is. And then we will probably want to be able to correlate event instances from multiple event producers and send them to the same consumer context. So there's got to be some way of how we can go and identify stuff that belongs together. And then there is further, furthermore we're covering with the, with the next points, we cover the cases where the event doesn't, it doesn't carry complete information because it's not possible to do so for legal reasons or for security reasons. So you have an HR application that raises, raises an event about a new employee record having been created. And that's something that an application may be able to go and catch, but to actually get at the PII of that employee, they will have to go back to the PR, to that HR application and then pull out all the details. So an event may not be completely self-contained, but may contain inside of its payload pointers back to the original source where then all the details that are really necessary for processing that event are hosted. And then they may also contain information to the second bullet here, interact with the event subject at the originating context. So you get alarm, for instance, or you get alerted about a new blog file having been created. And then you want to be able, and you know that that's a JPEG file, and you want to go and create new thumbnails based on that JPEG. You obviously have to go back to the subject of that event, the blog that has been created, and then load it and create your thumbnails. So that's something that also consumers might be interested in. Further down. What we also call out here in the, in the, just go a little bit, yeah. So that the consumer interest motivates, that's a thought piece effectively. And the consumer ultimately motivates what the producer needs to put into the event because the consumers are interested in information to producer withholds information based on some, some considerations as we just said with the HR application. But otherwise it's effectively always the consumers that drive what needs to be an event or not, and how that also needs to be structured. Then we get to the section on, so question so far. Yeah, quite a question. Would there be a way for consumers to be able to, or at least producers to be able to indicate that a group of events are related or associated together? That's, so there's a requirement here that the consumer makes and we're captured that, that you can correlate event instances from multiple event producers to send them to the same consumer context. That's also, that implies that the same event producer obviously also needs to be able to go and provide a correlation criteria. Okay, thank you. Okay, so middleware. So we have effectively now the both ends, the ones that are producing events, the ones that are consuming events. Now we're talking about the ones that are sitting in the middle between them. So I'm using middleware as the catch all phrase for API gateways, ESBs, message brokers, event, event routers, event ingestors, effectively anything, even for the, an HTTP proxy or for an HTTP load balancer or even the HTTP dispatch logic assets in the web server. Everything, all of those pieces are middleware. Everything that is not the code that produces the event and the code that processes the event is effectively middleware. So middleware routes events for producers and consumers or onwards to other middleware. So middleware might cause chains. And we'll also see that later. Applications producing events might delegate certain tasks arising from their consumers requirement to middleware. So it's ultimately the producer and the people who configure the producer. So it's not only the producer's code, but it's the producer deployment, including the configuration for that deployment. That's all of those things together taken. There's a decision being made as you take that code and configure it where those events flow and then also what middleware you take and configure with it and then which tasks you delegate out. So in some case, you may have a software, there's a producer that just calls a webhook. And in some case, you may have a consumer that just takes the webhook and then you put them together in the middleware. It's effectively just the HTTP stacks and both ends. But you may take the exact same pair of producers and consumers and they slot an event bus in the middle and they won't know. But the event bus in the middle will take work away from them. For instance, doing distribution of events, creating copies and also creating resilience, et cetera. So one question regarding what you said before, you talked about correlation. Is the correlation and all that responsibility of cloud events? Because I don't think the cloud events, beyond seeing a unique ID or a class should not own cross-correlation between events. I think cloud events can provide a good hint for that. I don't necessarily think that we need to think about correlation in the sense that you would think about it in like NGP. Because I really want to try and keep what we're doing to the minimum and not try to... Me too. So correlation is something that we can very, very easily do using a clever interpretation of the discriminators that we need to go and define anyway. So I'll actually go and present a solution to that. So this is something that's a problem statement and I believe in that problem statement. Kathy brought up a good point about it. So I believe in that problem statement. But I think there's no expansion of the scope that we have already to address it. Yeah, right. But that means that you need to add more metadata. No, it doesn't. I don't think it does. I don't think we have to. It's just a question of how you use your middleware. So I'll address that later. So you have the... You delegate to the middleware, typically. The management of many concurrent interested consumers to one of multiple classes originating context of events, meaning you have a producer, the producer sends messages, and now there's 20,000 people interested in it. That's a distribution test that's typically done by middleware. You don't make the producer do a for loop and send the same event 20,000 times. Typically also, there's a way for if you publish lots of events and you're interested in a class of events, you're not interested in all of the events from that class, but you're interested in a subset of them. So there's processing of filter conditions, something that's very common in PubSub software. It's also being done there. Sometimes the middleware will go into transcoding. You show up and you submit an event in a message pack, and then you want to go... Sorry, in JSON, and you want to have it a little bit more compact to put it in the message pack. Or simpler, you put a text file in or some text event in, and you want to have it zipped for a transfer that's also transcoding. Transcoding message doesn't change the shape. It merely changes the way how the data is coded on the way. Then there's transformation. Also very common in enterprise integration scenarios where the goal is to keep the semantic integrity intact of the event so that it's still the same event, but there's a remapping happening. So for instance, if I take a native event that's being emitted through Azure Event Grid today, and if I map it into a cloud events event, that's a transformation, and that will not change the semantics of the event per se. So, Clemens, just a time check. We are actually already at the 10 minutes, Mark, so you might want to pull it up a little, talk a little bit at a higher level. Right, I'll do that. So ultimately, there's, again, if there are scenarios, then there's, the middleware then drives a further set of requirements. Again, ultimately on the producer who needs to produce that event. We also went, effectively these things are all following out of the, the scenarios up here. And we talked through that in detail. And let me get to the framework section. And then we have the fourth one, which is really about frameworks. So frameworks are not necessarily in the, they're neither producing the events, nor do they consume the events, nor do they route the events, but they're actually helping the application developer to make things easier. And frameworks, what frameworks do, is they often do dispatching. So when you think about most popular, popular application frameworks, they take some kind of request and now make it dispatched to some user code. So if the user code is a function, then there needs to be enough information in that event for that dispatching to happen. And typically you take an event stream, a fairly narrow event stream, and that event stream may have a few different operations that you're observing or kinds of events, I would say that you're observing. And what you're doing with that framework, is you're dispatching that onto a method. And then another thing that frameworks obviously do, and that's what they're interested in, and that's why we have a lot of your framework people on the call, is to make sure that platforms are semantically aligned, so that things look the same. So you can provide a platform abstraction that then ultimately makes things like the IBM cloud and Google cloud and AWS and Azure kind of look the same for applications. So that is all that. So this is all about the user stories. Again, we've spent like two and a half hours on this already, and so... Wait, before you tell it, wait, I have questions. And I asked some questions in the PR, but listening to you recount it, I'm not sure why are we talking about frameworks? Are frameworks just like a subset of the consumer? Is there something I'm missing there? We're talking about frameworks because frameworks have specific requirements. So frameworks are stuff that sits kind of in the... that someone builds who's not the consumer of the ultimate event. Each individual instance of a framework will be a consumer, right? Yeah, so my point is I'm talking about user stories and so I'm talking about people here. So there's someone who consumes the event who builds an app. And then there's Austin who writes frameworks who sits between the thing that I built and the thing that a user builds. And Austin is a framework builder. Okay. But then the framework builder is it... doing things in the service of the consumer, I think is the Rachel's point. That was the thing that... Yeah, but it's a user story, so therefore there's two distinct users. There's someone who builds a consumer and there's someone who builds something that needs to handle those events. Austin needs... Austin's tooling or Azure Functions needs to go and take an inbound event and needs to call a function in some way. The normal person on the street doesn't do that work, but they simply write the functions. So there's a person here, there's a person here who writes that framework and since that's neither middleware nor the consumer, they get a specific section. Okay. Just to the point, there are multiple potential actors in source and there are multiple potential actors in consumer. And I don't know if it was you or somebody else who argued earlier in that aggregating all of the producer concerns together, whether they're the platform provider or the application writer was appropriate. Do you agree that Austin has a job? I'm just saying that if we aggregate that Austin has a job, that it's not writing all our business apps. So I'd like to hear from other folks. I'm not sure I'm clear. You're saying, you know, I also don't think we need to have a lot of sources because the source needs to be of the package. We're not talking about sources. We're not talking about sources. We're talking about this one. It's currently present here. We're talking about that PR. He doesn't ask his question. No. I want to make progress on this thing. And we're already past the time box. Okay. Objections to this PR. So hold on a second. So I think there may be a little misunderstanding here. So correct me if I'm wrong here, Clemens, but your PR is really just sort of laying the groundwork and explaining the various actors that may be involved in the bigger picture here. It's not necessarily defining our set of attributes or anything like that. It's just sort of laying the groundwork for someone to understand all the things that we thought about as we develop the specification. That's right. Okay. Just a question. I'm not from conflict, but there is this conflict schema registry. And where does it fit? Which perspective does it is satisfied? Is it in the framework section or consumers? I'm not sure. The streets is tooling. So that's framework. Okay. It makes the interaction with the event platform infrastructure simpler. I don't. Okay. I mean, I think that we should take notes when, if rather than just having verbal. Um, you know, whatever clarifications are necessary in this meeting should also go into the text. I would, I would propose that we take the PR as it is because we spend two and a half hours on it. And, and then, and then people and as. I'm not going to keep holding the pen on this. Right. So, so, okay. So moving forward in terms of process here, we have a PR in front of us. Now, keep in mind a couple of things. First of all, nothing in this poor request is normative. Okay. It's all just explanatory text to help lay the groundwork for someone reading the spec, understand what was going into our thinking as we're making decisions. Okay. Nothing to hear is normative. The other aspect is at this point, in time, especially since it is such a large PR, we are not looking for. So everybody to look at this and say, yes, it is perfect. People can make further changes later on with additional PRs. What we're looking for right now is whether this is a step forward in the right direction and whether it would make the spec better to add it as opposed to make it worse. Because if we wait until it's perfect, we're never going to merge it. So remember, we're not looking for perfection. We're just looking for, is it a step forward in the right direction? And is there anything here that's really objectionable to going in? Because if we try to go over the bar or raise the bar at all, I think we're never going to get, we're never going to complete. So with that in mind, do people have comments they'd like to bring up? So Doug, I have sort of mixed feelings. I think it's good to have a nice background on the other. And I'm sort of a little afraid that we're getting into too many details about the event itself. As if that's our focus. We're not looking for perfection. We're just looking for, is it a step forward in the right direction? And is there anything here that's really objectionable to going in? That's our focus. That's the group focus. I think the group focus is about transferring events between systems, not about the actual nature of the event. That's my view. So I think on one end it's good to have an overview, but if we're diving too deep into the explaining what event is, it's sort of a hinting that we want to, you know, be an event aware. Are you objecting to the text? That's what he said. I have mixed feelings. I'm okay with it as long as we understand that we're not trying to build the event, you know, so dive into the events themselves. I think the text is what it is. And I don't expect it to change or expand. Yeah, I think, I think he tried to say that pretty abstract as, as much as he could anyway. Any other questions, comments? Yeah, I'm going to, I'm going to chime in on this real quick. I've read through everything and I participated in, in some of those calls and I appreciate the leadership by Sarah and by Clemens to provide clarity around all this and this common understanding. Doing that amongst big industry stakeholders is, it's never, it's never going to be easy. And I think we've, we've come a long way. I think that this looks pretty good and provides a lot of necessary clarity, not for the perfect end result, but for moving forward and just getting to the first version of the specification. Definitely hearing a lot of anxiousness to, to try and move forward and focus on how we can, on focus on getting that initial version out and keeping it minimal and finding alignment on these, these core attributes that seem to be, seem to be difficult to align on. And I think there's enough in here to help us to establish a lot of alignment and move on to discussing those core attributes. Okay. Thank you, Austin. Any other comments? Have all of the, have all the comments that are in the PR have been addressed or responded to? So those were, this is, this is kind of my point. I've had a note in the docs. The Clemens responded to things with comments, which means that this PR has accepted all of that information and clarification will be lost. And so I think that there are some really key points that some might argue are wordsmithing, but since they generated a bunch of confusion in the comments, I would argue are not wordsmithing. Maybe wordsmithing can resolve them. However, there is, exists a lot of confusion. And I might point out that like early on, a number of times come back to this presentation that Clemens made early on about events being fact and messaging, having intent and messaging, knowing the destination. And in, you know, one of the upcoming PRs, somebody says, why aren't we calling this cloud messages rather than cloud events, which I think gets to the core problem that we don't yet have enough to explain. And that comes up almost weekly. And so I'm happy to hold pen for a day or two if Clemens are, you don't want to do that wordsmithing, but I believe that it is necessary. So PR is not lost because if we merge it, then it's still in the record. And which means you can also, you can refer to points, which means if you're making, if you're making an amendment, which means you make another PR, you can obviously go and link to the prior PRs. But it doesn't mean that people who go to look at this dog won't see it. Yeah. So the key thing is I believe that this PR as written, as we've accepted right this minute would move us backwards, not forwards. Okay. So then how about we, how about we go and abandon that entire thing? Okay. I don't want to add to it. It's not an alternate situation. So guys, guys, hold on a sec. Let's get, let's get very precise here. So Sarah, which comments in the PR do you think are blocking comments? So we can try to look at them. So I would like that every time Clemens has responded with a clarification that that clarification be in the text rather than because I don't have to agree with your, I don't have to agree with your objections and cause text changes because of it. That's not how that works. Okay. So I read your, I can, I can disagree with you. This is my text. Right. I write it. I hold the pen. I propose this PR is done. I will make no further changes. We will go and vote on it. And then you, and then you can go and, and make a mess, but there, I don't see any, any reasoning for there to be, to block this at this point. Do you not want to? I have addressed the objections. And so there's, and, and you can, you can open a PR in 10 minutes to go and address it. We have no locked version of the spec. We're in the process, but we don't need to, we, we, if we, if we just keep PRs open, open, open, open on changes spec, we don't make for any progress. If you believe that this, that this PR holds the spec back or throws it back as is, then we should not take it and abandon it and not have a user section. Wait, wait. So I have a question, Clemens. I believe that everything, every comment that I made was not an objection, but actually a clarification. If you think anything I said was an objection, I'd like to hear it. I have, I have, I have addressed, I have addressed all points. I have not formulated them necessarily in the way that you did. So, so, so, okay. Clemens, hold on a second. We're going to run out of time here. So again, Sarah, let's go back. Okay. I'm not, I agree with you that there are questions that maybe the original asker of the question would have liked to see some text changes and sometimes Clemens made those changes. Sometimes he didn't. That's fine. However, my very specific question is, is there any comment in here that you see that you feel like needs to be made before the PR is actually merged and cannot be made in a subsequent PR? So we had two hours of conversations about, and we talked in detail about one and two, and I know people felt like there was too much wordsmithing on those calls. And those changes that were agreed upon on those calls have not been integrated into this PR. So I don't, I don't know. That is not the truth. I waited on Monday. I waited on Monday. Didn't do anything. So that I don't throw things off. Then the call closed on Tuesday and I went through and did all the changes and you can go and look at the log. That is just not, it's just not the truth. I went through and addressed all those things and it actually addressed all those, all those things in the call. And you see a day ago, a day ago, a day, I mean, I put, I put my phone down and I was like, I don't know what the problem is. I don't know if it's true. It's true. It's true. It's true. So that's, that is just not true. So again, I don't, I don't know what the hold up is here. So let's, let's see if we could focus on those on the specific concerns by Sarah. Yeah. Sarah, which, which comments do you feel are blocking that could not be easily addressed with a follow up deal. Should we go through and like talk through each of them? So, presenting the four points in this PR. We've had very little discussion of it. I haven't had the opportunity to go through and like I can spend that time right now. You have two hours, you have two hours in calls. You had you had you had four days, right? Since we go through those things, I don't I don't know what the hold up here is what I want to do is I want to get to working on the documents and I'm working on this usage section and and we're gonna I'm serious right I don't think this is no normative text nobody's gonna build software based on this this is purely existing because of your assistance Sarah that we need to have these user scenarios to drive some consensus even though I believe that there's industry consensus actually about most of the contents that were that we're trying to try to use okay so sorry so that is what so that is what the section is for I wrote it right to correct to provide clarification I think for most people on this call this the content here is not you know it's not really necessary right and I'm happy if that section is actually not in the spec so it's okay Clemens wait wait Sarah can you can you point us to which specific comment you feel like it's a blocking comment and address before we can like vote on the PR and that Dan Dan do you want to talk or do you come off mute on the stage no sorry I'm accidentally off you okay can you meet yourself again because it's a background noise thank you okay go ahead Sarah I'd be interested in hearing why we're not doing cloud messages rather than cloud events and how this addresses that so Sarah no I apologize I have to have this sort of object to the question we're trying to resolve this PR and you said that there were comments in here that you felt were blocking comments can you can you point out which blocking comments there are so we can look at them so my comments were apparently addressed yesterday and I have not had a chance to read they're not just my comments other people may comments which I thought revealed some confusion and so I can go through that now but I need a few minutes I've got a I've got a suggestion maybe maybe we give Sarah some time and her team to you know find those specific comments and we could discuss them in another separate call this week and you know hopefully hopefully resolve them but also in the interest of moving forward perhaps we should consider doing a vote on this next week I agree with that I think you know we can we should give you know Sarah some time you know to go through this because she already said you know she does not have time to go through it after you know so I'm not gonna be here next week just be clear and which means I can't I will not be able to make any changes if people get time that's fine but I'm I'm I'm not gonna make any changes because I'm simply not here and I'm completely out of reach starting starting Saturday okay so the interest of in the interest of progress right the way forward with this text as it is is to take it and then modify it and then modifications because if there is no substantial objections to the entirety of the text which that doesn't seem to be then there doesn't seem to be any hold up to go and take the entire text and then start to work smithing all the pieces of it in my absence right so I don't understand I don't understand what the hold up is we can take this in and as said it's non-normative and I personally don't even care about the section but since since we need to have some use of section apparently I would propose that we take this now and then people start filing their PRs on that because I will not be here next week to address any change any change requests on this I will not be able to hold the pen which means either we take this now right or we're gonna take this in whatever in two weeks but then we won't have to be able to have that continue that discussion okay so hold on it's like before around the time I'm gonna do a couple things are based upon what I heard first of all Clemens since you're not here next week it sounds like you're okay with someone else taking the pen and other people are allowed to make commits to this PR you may have to be an admin I'm not sure so may have to be me or Mark or somebody else right so we we can make edits going forward without you being here are you comfortable with people taking the pen in your absence yes if we if we merge the way how the process works is because this is my repo is you take the PR and then you know okay okay let me let me let me switch the order which I discussed then so based upon what I'm hearing I don't think it'd be appropriate to merge the PR today because people have asked for more time to review because there were some changes made too soon to this meeting so I'm not comfortable forcing the merge right now because I have not made any changes since yesterday right no I have not I have I have me I have made a comment today because there was a comment today but I have not changed I have not made any changes yesterday okay in that case that from a time perspective you're right thing for the governance role that is that is plenty of time so if we do not in essence vote today on it though if in your absence would you be comfortable with someone making changes to your PR in your absence I'm not sure it's possible you can have a collaborator on your repo or they can work your repo I can I can do that I've done it with other people's PRs helping get the signing issue so it's not an issue I just want to make sure you're comfortable with someone taking the pen if necessary Doug I think the flip side of that is we can always fork from his repo and submit a pull request against this specific branch right and Clements can ultimately choose to merge or reject the pull request which makes changes proposed changes to his poll summary is I don't care okay okay do whatever is necessary to make progress okay so I find the fact that we spend this hour on this again so that we're now we're now what three and a half hours this week in on a discussion that is not the normative part of this this specification that doesn't bring this group forward at all it's alignment we're about we're trying to become aligned that we're not aligned with the alignment is is where the rubber hits the road and that is on on concrete items that we can go and think about in terms of code right now okay hold on a second Dan I don't think we're gonna get yeah I don't think we're gonna get alignment Clements so let's just move on yeah so okay so I give everything that I've heard here so far okay I think Dan let me know okay so given everything I've heard I personally am not comfortable forcing a vote at this exact moment in time I may be wrong but forgive me but I don't think I don't feel comfortable doing that I'd rather play more conservatively than then brush it through so with that in mind it sounds like we can we can make edits to this to this text one way or another either directly through SPR or fork it whatever that's not a problem Sarah you said you need more time and potentially gonna want to discuss some edits can you set up an additional phone call for tomorrow to continue to continue the discussion for anybody that wants to have the discussion for tomorrow so so yeah it's a I don't have the time that the early morning time that some people on other it is time so friendly okay would do me a favor sit find some time if it's not if it's not tomorrow please don't make it any later than Monday but send out a time pick a time and people will join if you want to collaborate on wordsmithing or chain making changes to this text please join that call because next Thursday we will vote on some version of this text okay that's not fair to people yeah that's right yeah okay okay this stuff's always fun okay before we move on which is only time to really do the roll call is there anything else people want to bring up as a topic because be honest I don't think we have time for anything else okay just to go back to the roll call then William are you there yes Michael Payne yes I'm here Ryan are you there Ryan okay what about Barron Barron are you there yeah I hear you now faintly but I heard you Joe Sherman yes I'm here about Alex yep I'm here David Baldwin okay and Ryan are you there okay if there anybody on the call who I did not add to the attendance okay with that in mind oh yeah this is Ryan this is my first time I I had problem unmute myself yes I'm here not a problem thank you very much if this is your first time do me a favor go to the agenda doc and add your last name and your company you're from so we can mark that in the attendance tracker agenda doc where is that is that gender doc yeah yeah see the chat I just pasted it in there okay thanks okay as in don't have any talks to bring up I do do want to address one comment in here and agenda that Sarah brought up which is volunteers to present Sarah suggested that we have volunteers present small set of attributes that work together I would strongly recommend that if you would like to have us work on a group of attributes at one time because they are correlated or they're related I would strongly suggest that you submit a poor request with your desired changes this goes for anybody I'm not talking to Sarah particular just in general the best way to get a discussion going is around concrete text proposed for the specification I'm going to give PR's preferential treatment over discussion talk okay so if you want to push for something to happen whether it's for a single attribute or group of attributes submit a poor request and that's the best way to get the discussion going because that is what I'm going to get priority to concrete changes get priority over abstract ones okay so with that we have three minutes left are there any other topics people would like to bring up I have a quick question for Dan we have is Dan Barker he's on the line I thought I saw Dan earlier he's our cloud events website is not up I was hoping that he could provision the website that he worked on to get a pages and once that's done we could we could get the Linux Foundation to point the domains to that to that new website but just need to understand the status of that first yeah you may need to send one note to pick him through slack I don't see him online any more unfortunately okay I believe so let me just double check I thought I got him yeah I think you did yeah yeah I didn't call his name out because he spoke that's why I didn't have to do that yes all right all right any other topics all right with that oh Austin are you gonna say something we'll get through this we'll make this happen and I look forward to working with people you know in the individual calls whatever it takes I think what we're doing is of great importance you know events been ambiguous subject for so long getting all these great minds together to to align on something is it was always going to be hard but I think we were making a lot of progress and I again I think what we're doing right now is important to serverless in general but it's bigger than serverless I think this this is gonna have a big rising tide effect yeah I'm still super excited we'll pull through here yep after what if this was easy anybody would do it and we won't get the big bucks right so every now and then you have to have something to keep you you know occupied and keep these things exciting so okay I agree with you we'll get through it if there are big bucks you send them my way I apologize for the implication all right with that I think we're done thank you guys very much we'll talk next week and Sarah please send out an invite for for the next meeting it will be it's already it's above it's an action I am it's gonna be 8 a.m. tomorrow and we'll send out an invite okay excellent thank you very much thanks everyone thank you bye bye