 All right three after the hour. That's going to get started. Okay, it's where we'll call later I don't bump on my think nothing. Oops. Sorry one window I don't think anything's changed with the AI's and stuff. You can skip that Community time is anything from the community people like to bring up. That's not on the agenda. All right. I'm sick All right, moving forward SDK nothing new to report there, but just a reminder we will have an SDK call or immediately following this one for those of you interested in that work Let's see incubator. So we do now have excuse me We do now have three end users to from to their mention from adobe and a friend of mine appointed me to this Accenture Project, that's an open source project that's actually using cloud events So we were thinking that we could use them as a as the third end user. However Yeah, I'm using it would be really nice if we can actually get a little more than just three I think in the background I pink go people and they're working on it So what I'd like to do is go with the assumption that we will get at least a couple more before we actually present the TOC but what I'd like to do is to See if you guys feel comfortable with us actually asking to get on a future TOC call I can't imagine it's gonna happen for a couple weeks anyway because they're usually backlogged But I wanted to start that process now Has anybody reviewed the PowerPoint slides or have any concerns with it? Okay, are there any concerns with me asking to be put on the agenda I Did review the slides a few weeks ago. They haven't changed recently, right? They have not changed that is correct Yes, yeah, when I looked at them, they look reasonable. Yeah, okay, cool Okay, so I'm not hearing any objection. What I'll do is Okay, I will go ahead and gas to get up on the agenda Obviously if you guys review the slides and you want to make changes, you know, you're more than welcome to make suggestions I'm open to anything there As I said, if you have more end users you want to list please do there's also a page in there. Where is it? it talks about People that have actually adopted the spec itself now most these guys are not end users But if you want your company listed here, please let me know and we can add it just to Show that people are actually adopting it from an implementation perspective not from an end user perspective just To help it along Okay, so I'll ask you to put on the agenda Please review it when you have not done so yet. We'll get some last minute changes in there When would this meeting likely to be take place if we're talking like weeks months, whatever Honestly, it depends on their backlog and I don't know what the backlog is like I would guess it would not happen for at least two weeks just a guess But I I don't imagine it'd be months out But that's just the guess the minute I find out an estimate or something. I'll let you guys know Fair thanks. Yep All right, moving forward kubcon. So The due date for submitting the proposal for our sessions is tomorrow. So I need input from you guys We have a choice we can either do an intro and deep dive for both of our groups Or we can do a 90 minute session for either one of them My current thinking is that Uh doing a 90 minute session for the serverless one Mainly because we don't have that much material and I actually contemplated dropping down to just a 135 minute session But what I'd like to do is turn it into a birds of a feather session like we did in Barcelona Where we basically start engaging with the audience to find out what their status is relative to serverless adoption In particular if they're not using it. Why aren't they using it? You know, what are the roadblocks? Is it just fear and uncertainty doubt or is it something else in terms of lacking functionality lacking tool and that kind of stuff I think we had a fairly good session. We did this in Barcelona. Even though we had a relatively small audience I I do think it it might be valuable but if There are people who think that it didn't go well in Barcelona and you want to drop down to 35 minutes And just talk about status of the working group and potential future things. I'm open to that as well Um, likewise for the cloud event stuff I feel like every time we've done a cloud events intro and deep dive Um, while the sessions themselves work out fine I kind of feel like there's a bit of an overlap and a duplication of of material that gets presented And I feel like it might be better if we just go for one 90 minute session instead of two 35 minute sessions And just do the whole thing in one shot, right do a summary of spec status plans Do the demo Airport demo and then any of the topic you guys want to bring up in there Just do it all in one rather than trying to split it across two and run the risk of Duplicating things between the two sessions Anyway, that's my current thought process here For those of you who have been involved in the past or want to be involved in the future What do you guys think about this? Come on Don't make me pick on people because I will I think I think splitting them is I agree that's probably not the best thing So combining them would make sense Okay, Scott, thank you. Hands up The one benefit to having it have two sessions is that there's a higher probability that you don't overlap with some other session You might want to watch and people tend to Steer away from the very long sessions Possible true. Yeah Klaus Yeah, so first of all, I like the serverless session in Barcelona. Um Yeah, it was really valuable And um, yeah, I also observed that those cloud events intro and deep dive overlapping kind of So, um, maybe also by now it's not that unknown anymore that an intro really is needed. I don't know That is true. Well So let me ask you guys this, um Do we have enough for a 90 minute session for cod events? In other words, do we want to just do one 35 minute session cover everything in that? Because to be honest as I was writing this list right here I was wondering what other topics we'd have Because if we don't have anything urgent These two together I think you'd be done in 35 minutes What do people think? Yeah, I think so. I think last time we also put like the workflow stuff Which we don't really have anything concrete. So I think these can be done in 35 minutes. Yeah Scott, what do you think since you you've been part of a couple of these I think Yeah, what if what if there was a cloud events intro deep dive single session 35 minutes And another 35 minute session of cloud events in action And what would you show in that one? What does it look like in production? Like how are people using these things or how do we intend them to use them? Kind of like go through use cases and stuff. Yeah, kind of like a Oh case study Do you actually have enough material to fill 35 minutes? Well, we have three people that are using it in production, right? So we can go see what they're doing True and we can also have them talk lots of it You got a question there on the chat Scott are you volunteering to demo the go SDK line? I did that in Barcelona and it was super fun. Yeah Okay, so I guess Scott what you're proposing is one 35 minute session that just gives an overview of the project itself and status and stuff and then Cloud events in production, which is not necessarily a deep dive I mean it kind of is but it's more business related I guess or uses related What if you'll think about that? I think that's definitely better than like just doing the intro in a deep dive Okay So to the original question I was asking though Scott Would you prefer to actually have two completely separate sessions or just one 90 minute long session that does both? My preference would be two sessions just because people Like there's a lot of stuff going on. There's a lot of tracks and there's a lot of overlap Okay, anybody else having an opinion on that? I'm okay. We go with that if anyone else has any comment Okay. Hi, this is Vladimir. Um, just a quick comment on this My experience with similar events If we have two sessions, it is important that the two presenters are going in sync Otherwise, there is a risk of duplicating various intramaterials Yes, I agreed and usually the Usually the people who do the two sessions Collaborate a lot before the events. That's usually an issue. Yeah, right. Great. That's what we've done So I'm not too worried about that. Good. Good. Thanks Hey, Doug. This is Colin. We went through this exercise for gnats We're actually going to combine it because we do have a lot of material But we're going to do it in a way where we've got a short intro And then we kind of describe a use case and how we approach something and then the second half is um Going down into the real details into code into configuration that sort of stuff so people can leave halfway through if they want So you're yeah, okay. So you're so you went with just one long session then Yes, that's what we're planning on. We we're waiting to the last minute, but yeah I could see that working too Yeah One of the things I do like about one 90 minute long session is it gives us the freedom to To move things around the last minute, right? If you sign up for two separate sessions, then you're you're forcing yourself into a very clean split from the From the ounce from the from the get-go right and you can't for example the night before Completely rearrange the topics without completely screwing up the schedule But with 90 minutes all we have to do is submit an abstract now and we can be changing stuff up to the day before So it gives a little more freedom that that's one of the reasons I kind of like one 90 long one 90 minute session And there's no reason we have to use all 90 minutes either 90 minutes is a long time so What do you guys think Scott you seem like you might be okay with one 90 minute. Yeah. Yeah, totally Okay, look let's try that. I suspect if for some reason as we work it through if it turns out 90 minutes doesn't work. We could probably convince the organizers to let us split into two and Even just take that 90 minutes and split into two and put a 20 minute block in between them for people to walk around so Okay, let's do that. So this will be Part one and part two and we'll figure out the exact details later I may ping some of you guys offline later today To get approval for the abstract because I want to make sure I summarized What we're going to be talking about appropriately so we'll keep an eye out for that All right Okay, so here's the current proposal You guys okay with that? Okay, not hearing any objection I'll try to figure out something and submit that By tomorrow. Thank you guys All right before we jump into prs any other topics people think are important to bring up All right moving forward All right, so this one we talked about last week, let's try not to rattle again on the name so um Two sets of changes here if I remember correctly first change schema url to data schema everywhere and The other change is We made it a Uri instead of ui reference So that's moving the word reference there added uri to our type system And instead of saying a link I just change it to be identifies the schema So I think those are all the changes here I think and I think that's consistent what we talked about on last week's call Any questions on that? Thank you Christoph the lgtm any questions concerns Any objection to approving? All right, cool Cool. Thank you guys If I can type All right next Okay, this one changed quite a bit since last time because I we removed all the rambling texts that I had in there And let's see what else I do in here. Okay. Those are just typos All right. Here's the bulk of the change so Is your question already? okay, so This is just adding some guidance that says while it can be really really short. It's recommended that it be an absolute uri Okay And we made it so that it has to be a non empty uri reference and I did that for both source As well as what was the other one schema url, which is now data schema. So I need to merge those two No, I remember doing the previous one. So I think this is the bulk of the change It must be a non empty uri reference and some guidance that says you really should do something longer Unless you're in some sort of private environment kind of thing I think that's what we talked about last time Uh tim your hands up. Yeah, so so the the distinction between Absolute and relative uri references is crystal clear and then that's fine I think the discussion about length is is does not add value. Um, you know, if if I'm using a Relative uri reference, you know images slash cat is a perfectly good fine relative uri reference um I just don't think length is helpful Well, okay, you say length mean talk about the word short here Yeah, okay, so Is there another I I don't want to anything with a different phrase that says Meaningful or unique or something like that. I just couldn't think of a better phrase. We want to suggest a different phrase to put in there I I don't think I mean, I don't think it's relevant at all If it's a all we care about is it a valid relative uri reference or is it a absolute once it's once it's once you once you've Allowed relative uri references then Foo is a perfectly good one So you're proposing to even drop this recommended statement No, I I like the recommended statement that absolute Should be used Okay, so you just want to do this if you're not gonna eat yet, right? Got it. Okay um Okay, I don't mind that um I I'm okay with basically taking this bit and sticking it into the constraints section. What do other people think? Yeah, Tim's recommendation makes sense just by saying that an absolute uri should be used. It's probably enough okay I mean relative uri is totally meaningless unless you know the base anyhow, right and so The assumption is people would never look at the naked relative uri They would look at a form composed with the base which should be meaningful in and of itself Okay, fair enough. I don't mind removing the the rambling text. That's fine Okay, any of us want to speak up in favor or against tim's Edit Okay, so the current proposal is to take the pr And remove this paragraph but keep this highlighted text and move it down to the constraint section any Concerns with that any objections Sorry, you're gonna retain. Oh, I see. I see. No, never mind Here move the highlight move the highlight text down to constraints room and then remove the whole paragraph Any objections? Well, that's that's what the worst constraint section is. So yeah Yeah, yeah, we we're not completely crystal clear. Sometimes we put constraints up here and sometimes do it down there It's a little we're a little fuzzy on that but we can worry about that later if we want to Okay, is there any injection to me making this editor? I I consider to be strictly editorials Any objection to making this editorial change after the call And assume that the pr is still approved I'll I'll wait till we get one or two lg tms to make sure I didn't do any kind of syntax typo But you guys okay with me merging this offline I'm fine with it. Okay. Cool. Any objection to do any on that path? okay Last chance then why type this up any objection to that proposal being approved Okay, cool. Thank you guys Okay, cool. I'll make that change. Thank you guys All right, this one should hopefully be easy There was no pointer in our read me to the SDK doc that we have Um, so I just basically added that The only other thing I did is I added the word requirements there The title of the doc was just cloud events SDK and it seemed like It was missing something or some of the word after that describing what it was So I put the word requirements there If you guys have another word Like recommendations or guidance or something. I'm okay with switching it I just felt like not having another word in there felt a little bit awkward to me Um, but that's basically all this one is just add a pointer to it Any questions on that Any Objection then to adopting it or approving it Okay, and obviously if you guys have another choice of words in there, we can do it with pr later It's obviously not a big deal. Thank you guys All right Next biggie Hopefully Tim is your hand still upwards that old Oops. Okay. No problem All right So hopefully most people have been following the the chats that are going on through the prs and stuff um so for those of you who haven't um Based upon the conversations that we're going back and forth between uh Christoph and clemens Um, mainly around the pr that the Christoph submitted as a wording change to to to clemens um I'd made a suggestion somewhere in one of those comments of Possibilities for reducing what we say down to a bare minimum Clemens suggested I turned into a pr. So that's what I basically did um, and so this pr basically does a couple things first is It removes the notion of data as an attribute Which and I I know that technically when we do this structured format It appears as a sibling in the for example in the jason as another attribute But from the abstract perspective if we stop referring it to it as an attribute Then we don't have to jump through hoops to say our data types apply to everything but data, right? Because we want to say they apply to all attributes, but not data It gets really kind of funky So I remove the notion of data as an attribute and just said just I just call it data whenever appropriate I think I got all the places where we have phrases like data attribute and stuff like that May have missed one or two. So if you guys spot them in the future, let me know But that was the that's the first big change I made is stop referring to data as an attribute um The other change let me just go down here. I think this is the spec Okay, the other big change is and the spec itself what I did is I moved the type system To be under the contracts attribute section It's felt a little awkward to me as I was going through these changes to have these two separate sections kind of Point to each other and relate to one another. It seemed to flow nicer to just say we define attributes And here's what it can be defined as in terms of a data type and it just seemed like it flowed a little better I don't think I necessarily changed any of the semantics in here. The only thing I did do is added Boolean Mainly because I thought that would that should be a valid type that people want to perhaps define For an extension. It seemed like a very natural thing if people to say yes or no on or off kind of thing um I also added this stuff in here that said all attributes must be a scalar type I don't think that actually changes the semantics now that we've killed off map I just added this to make it explicitly clear um That they must be a scalar and they must not be of complex type meaning maps and structures since we explicitly disallow that the reason I added this was because um We now don't have map in there anymore, but we don't explicitly say you can't use map And so that left open the possibility of someone actually defining an extension that might have used map And I thought based on previous discussions. We were headed on the path of banning that so I wanted to make it explicitly clear But then the bulk of the change. Oh another one In the optional section option on attribute section I said optional or conditional because as christoph was pointing out While some of these while technically all of these are optional They actually may be required based upon what you're adding into the cloud event So for example the content data encoding. I'm sorry data content encoding may actually be required depending on your civilization So I had worked conditional there since I think that might be a little more accurate But the real bulk of the change is up here And I'll let you guys read this Basically, all I'm trying to say in here is if when you serialize data And then you and you're in the structure format if it's a normal serialization of data Does not align with the serialization of your envelope itself You may need to base 64 encode it and in particular use the Where is it? Yeah, well, I guess this is on the This is on the data content encoding So basically say you may you're probably going to have to use this attribute if you can't do the normal serialization And we'll talk about using base 64 do the encoding at that point Um, and here's the stuff down here We're talking about if you can't do it and it's normal and it's normal encoding or it's encoding based upon the Data content encoding string or value. I should say Or data content type. I should say sorry And I think Here's the last big section now in data We remove its type. So it's not even any anymore. It's just Almost undefined. I actually originally had the word undefined in there, but then I removed it per clemen's suggestion Just not even getting any confusion about it. So basically it just says it's the payload Defined by the data content type schema URL points to it Talks again about the native syntax if you need it. You're supposed to use the data content encoding If you if the native syntax per data content encoding or its native type doesn't align with your envelope And therefore you must use the data content encoding after Anyway, uh, yes scott base 64 All right Like I said, hopefully most you guys have been following the conversation during the week, but any questions on that? Really nothing Any comments? Yes one So so this is we had this is so this is the fourth proposal that we had around this and this seems like the best one to me because that is The best of all the compromises because the problem is is difficult the only thing We end up with where I see risk and I mentioned that in my comment was With You know forwarding through intermediaries Um, when you have data that contains dates Um, and you come in with um, you know this a self-contained Event that is all in avro and that contains a date And you run that into a intermediary in the intermediary now sense that onwards using jason because of jason's Um ambiguity in in terms of how dates are encoded because sometimes they're rfc 11 23 and sometimes they're they're rfc 3339 which means one is iso and the other one is not You might end up in a place that you receive it you receive the date as jason and then it's You end up with the wrong expectation effectively And that's the only that's the only data type that I'm really worried about because Jason has the weakest type system and no business And so I was suggesting to make a rule in the jason event format to say If you are encoding a date Then that should always be rc 3339 Um, and that's the that's the only concern I have about this one So is that something comments you think we could work on in a follow-up here? Yeah, I just want to point that point or just want to point that out like that's that's a rule I would love to add to the jason event format even though it should stay out of the data thing I think taking a stance while jason doesn't is good Okay, I ask you a question, but I don't get a chance to see it yet Does this concern of yours apply just to jason or does it apply to any structured format? It applies specifically to jason because jason is the only type where the only encoding we're dealing with that doesn't Have the notion of What a date is got it. Okay. Thank you Okay. Yeah, we can work on that one as a follow on to this. I think it's a that's a minor change Any other questions or comments? I have a comment You're using likely need to be base 64 encoded So likely need to be it's probably not language. We want to use in the spec itself We want to use like should or must or be more assertive Yeah, I I think I probably use that because I Correct me if I'm wrong here Clemens, but I think in the proposals before we didn't mandate you had to use base 64 Did we or was it just one of the recommended ones? I'd keep in mind. This is also just In a for example section I mean, do you guys want to make it stronger and say base 64 is the only one we use? Um for string encoding. We actually say that don't we? for string encoding Data content encoding I don't think we say you we say we say basically this is where must be supported, but we don't say must be used Yeah, that's right. It basically this is this is um Hang on But while you're thinking about that Clemens Roberto, I assume this is the line you're worried about, right? I don't think that line is necessarily a problem per se because This is just saying that if you have binary data, you may need to base 64 encode it Because it's technically possible that your binary data could be the word hello Which does not technically need to be base 64 encoded I see where you're going, right? I could live with that Okay, that that's that's my rationale for why I think it's technically okay If if you think that sentence is going to cause a problem I'd almost rather just remove the entire sentence since it's just a for example anyway But I thought it might be useful But I don't have a huge preference on that one No, I think the example is useful. I would prefer to keep it Okay So Clemens Back to your other back to what you were talking about. Um My network connection is terrible. Um, but yeah, this is just an example. This is this is a I mean, this is a general purpose field that we define for our string But obviously this could also hold other encoding information just like it does an hdp Okay, all right any other questions or comments concerns here I ask Any objection to approving holy cow Okay, so question for you guys And thank you guys very much, especially Clemens Christoph and James. Hopefully you're listening to the recording. Thank you guys very much for all your work on this I believe That allows us to close This pr from James, right? Make sure we look at the right one Right Christoph and Clemens we can close this one now, right? Yeah, I just want to say that we should send James a big. Thank you because I think What we ended up was pretty much what he proposed in the first place Yep, I agree. I would I would do that Thank you. That's a good reminder Okay, now question for you guys There are two issues opened up by James I believe that we cannot close both of them, but I wanted to get your guys take on it just before I did that Can we close this one as a result of all the various PRs that we've done recently between killing off map and the one we just approved Clemens since you've commented on this one. Do you think we could kill off this this issue? Uh-oh Clemens you're still there Okay, anybody else have any opinion? I'm gonna pick on you Christoph Did you've been deeply involved in this one? You think we can close these two I'd say ask James, but I I think it should be fine Okay, cool. Okay. I'll go with the assumption. We can we'd always reopen if I'm wrong Okay Cool. All right Next thank you guys very much. Let's go to tim's pr now. I don't think this one's ready to go for two reasons one I missed the Tuesday deadline. However, I think there might be some outstanding questions on this one So tim you want to talk to this one and explain? What's going on here? Yeah, the core idea was this thing used to say printable unicode characters and there ain't no such thing Having said that the sentiment was that having garbage unicode characters That have no interoperability value and no semantics is a bad thing And I did a hasty first stab of that just ruling out the control characters But if people buy into the notion that we would like to be fussy about the repertoire of unicode characters that's allowed in In the right term non data attributes Then we should develop a thoughtful list which we can get by stealing from various other standards You know No new line characters. No non character characters. No control characters. Probably no naked surrogates There's a well-known list of unicode garbage that is reasonably straightforward to to exclude Okay, what do people think? Uh, I think it's great. The only thing now that we have removed the string type from data. I think we can also Uh drop support for line street and character return because that will cause problems in htp headers. Otherwise, I think it's perfect Yeah, this way just Yeah Okay, so I think I'm hearing is Keep the direction the PR is going just go further and get the get the full list of uh, Either valid or invalid characters, whichever way you want to write it up Yeah, so I'll take an action and come back with a revised version with proposed list of of garbage that we would want to exclude Um harvested from other standards and so on All right, any objection with the hangout direction for anybody? All right, cool. Thank you, tim Pull it All right, cool. Thank you, tim and just a reminder the deadline would be by next tuesday if we want to get approved next week Um, all right in that case technically that's it for the open v1 prs Now let's go into wishlist items This one is from evan Scott Do you want to talk to this one or did you want me to try to take a stab at it? Scott you have a copy of This is related to the conformance testing. Yeah, uh, basically. Yeah, I think so. I'm sorry. I haven't seen this yet Okay, never mind. I'll I'll comment it on it. So basically what What evan did here is he basically produced a whole bunch of different sample inputs for really really weird Uh cloud events in particular let me jump to some okay stuff. I think nor the data one And Yeah, so he did some weird stuff here Like for the id he has some funny characters in there. Here's a better example, right? He did some a whole bunch of really weird stuff now Correct me if I'm wrong, but but tim your pr if it gets adopted would probably radically change what evan has in here, right? In terms of valid cloud events going forward looking You know the weird uh Asian characters and so on are fine. There's nothing wrong with them The emoji are fine. Um, all right. Okay, so I'm not sure Oh, oh two two. I have no idea what oh two two is. I suspect Okay, I thought I thought maybe you're gonna just discard emojis and stuff Would it be better for us to hold off on resolving this one until your pr gets in there to know what the valid characters are? Two two is just a question. It's just a quotation mark. So, uh Um, I my instinct is this is probably just fine, but we yeah, let's let's yes, I agree Okay, so anyway, so this pr is basically giving a whole bunch of funky cloud events So people I guess at scott's they could do some sort of performance testing and stuff But make sure people are aware that they may get some weird characters in there and need to be prepared for it um Since I'm not sure I mean people have actually looked at this I'll and we need to wait for Tim's pr. Anyway, let me just say that Let me just ask people to please review it for next week. It's been out there for for quite a while And I don't think it's had really radical changes um But I'd like to get a resolve next week if we can once um Once tim's pr is approved So anyway, any questions about this? Okay, so please when you guys get a chance take a look at that one All right next So this is a change I believe I made this one because clemens in particular said we didn't have a Leave of absence clause in our government stock So basically what I tried to do is add some statement here that said if you are going on a leave of absence And that doesn't mean you have meeting conflicts, right? If you are actually not working like you're going on sabbatical or vacation or something like that for an extended period of time um You can ask for a leave of absence and that basically puts your Your attendance tracking on hold till you get back But you can't do it You know just willy nilly you got to send a note to the middle less in advance And just it basically gives people it out and they don't have to lose voting status based on vacations and sabbaticals and stuff like that So you guys can read the text here Any questions on this any concerns? Clemens you think the word A this is sufficient for your concerns? Clemens your network's still having issues Yes, there we go. No use different that one. Yeah, this is okay. It's okay. Okay There you go christoph All right. Okay, uh any objection to this change then No objection All right, cool. Thank you guys man. We're just flying today. I love it I apologize for germany having submitted so much vacation Yeah, you europeans tend to do that a lot All right, um Let's see Technically we're done with all the pr's and stuff. So let's jump to a discussion item that mark suggested last week that we have which is A quick discussion or not click but a discussion around our governance model in particular around the way we do voting rights As you guys all know We do voting rights based upon attendance on this phone call Not based upon pr's and stuff like that or can't pr captain stuff Which is slightly different than some open source projects or most open source projects, I should say Um, I will state though that from my experience anyway, I think clemens you may experience this as well from for normal standards bodies that work on specs a lot of times Things like this are based upon attendance because they don't typically track pr's and stuff like that But I don't know if it's universal. It's just in my experience. It's been based upon attendance Which is one of the reasons we headed this way to begin with was because we were doing a spec not code and their realization that A lot of our work is done in a very collaborative nature for example the That pr that we just resolved today where we have four different versions of the pr We landed on one particular one But only one person is technically going to get credit from a pr cap and that's not fair Um, since it was a collaborative effort from at least three or four different people so that's why Our count isn't necessarily the best guide for us since we do a lot of collaborative offline discussions and back and forth and stuff Especially wordsmithing so anyway Do people feel like we need to change our governance model or you know have any questions concerns Desired for changes now's the time to raise it so this this topic has come up in the past by some some other people and it's um Related more towards We are not conducive for every time zone to be able to participate and being able to ensure that they have a voice and a vote in some of the discussions that we have which Those discussions could be considered through email as well true I I have a comment, but is anybody else want to comment on that first? Okay, yeah, my reaction to that is It is definitely true from a technically voting right perspective Somebody like james who I believe is in australia He's probably never going to get voting rights however The way we tend to operate is more along the lines of almost everybody has a veto option Right, so james had had some serious concerns about that part of this one, you know that data part of the spec He opened a pr we went back and forth Clemens been over backwards to try to work with him From a time zone perspective so In my opinion almost anybody tends to have a veto power in terms of blocking the pr from going in Obviously at some point we do end up taking votes and at that point it's a shame that James didn't get a vote necessarily if this thing actually did come down to a formal vote but relative to PR is getting rushed through and and and the voting members get to steamroll anybody We tend to operate under the premise that if you have a concern and you raise it up through the mailing list or the issue or the pr We tend not to just ignore that and we wait until we get some kind of resolution And it's very rare that we actually go forward with a vote And the fact that almost every single one of our votes have been a landslide in one way or the other tells me that It's not that bad off, right? We never get to the case where it's like a five four vote kind of a thing But that's just my take on it. So I agree that it is a potential concern I don't think it's actually been a concern for us in practice But I'd be curious to know if anybody else had a different opinion on that Yeah, plus in controversial cases like that We always or we often also do an offline vote in the pr itself So that gives people opportunity to vote in those cases like online instead of making the vote during the meeting itself True the only downside to that is or the only flip side to that is Somebody like James who could never attend the phone call will never have voting rights But he could still voice his opinion. That is definitely true Right. Yeah Yeah, it's a matter of binding versus non binding right Yeah, I struggle to make the time. That's why I'm not always here It's 5 p.m. For me, which is a difficult time of the day, but I'll make it when I can But I think what we have works so I'm okay with that Anybody else want to comments? We do waste a lot of time with the headcount I know there's been a sore point for you and like I said, I'm okay if people want to To to stay there here in the chat thing and avoid the headcount thing. I don't mind getting rid of that I just to be honest the reason I do the headcount thing Is because and this is my paranoia based upon real life experience is people play games And I've had cases in the past with other groups not this one Actually, that's not true. This group has done it once or twice. I just haven't called it out But in previous groups, I've been in people will do things like add their name to the agenda But then never show up if all you're doing is letting people self register or they'll They'll get on the phone call and they're unable to appear in the zoom But they they walk away permanently, right? So they just log in and walk away and That's not to me on the phone call now granted, you know, once you guys say I'm here you could technically vanish and I'll never know But at least that tells me you were at least awake enough to actually say yes, Doug. I'm here That's that's the only reason I do it I'm it's just to try to avoid game playing because I have seen it done quite badly in the past And like I said, I've seen it. I think twice so far in this group. I just haven't called it out That's why Doug randomly calls on you Then there's that aspect yes ginger's living in fear Yeah, I know I know I'm sorry, but I agree with you Scott It is annoying But luckily it you know, I I do try to get it all done within the first three minutes And usually that gives people, you know chance to switch from other phone calls Anyway, because I'm not sure we start the call within the first three minutes anyway So I I know at the start point for you Scott, but I if you have another suggestion on how to make sure people aren't gaming the system I'm open to it If it ain't broken that fix it, I think it's fine the way it is Well, let me ask that question Does anybody think we need to make a change? I think I'm fine without a change. I wanted to just bring this up as Make sure that we were all clear about the governance model and ensuring that it was still working for us Yeah, it's a fair question Is there someone else who's going to say something in there as Mark was trying to talk? No, it was me. I was going to suggest that we vote on it Thank you, Neil Get a nice dig in there. Okay In that case anything else related to this discussion if you want to bring up at all Just a good question about the thing we just approved a few minutes ago for the voting rights The the the text says via email. Is it okay via slack as well? Or does it actually have to be via email? So the reason I did that was because I wanted it to be a little more public If you guys are comfortable with someone mentioning it through the public slack channel I just don't want someone to ping me Alone, I'd rather more than one person see it if you guys want me to add through the public slack channel I'm okay with that as well Would you guys prefer that? I would Okay, anybody else have an opinion one way or the other I would also add that, you know, someone could mention it in this in this meeting as well saying I'll be out on these dates and we can just add it to the No, that's too vague. It could easily Okay I'm okay either way Anybody else in opinion one way or the other? Okay, I'll I'll add the slack channel. We can always add more modes of communication later if we want to but I'll Just make it more formal. Is there any objection to adding slack channel as an approved mechanism to notify your leave of absence status? Okay, cool I will make that change and I will wait until I get one or two LGTMs to make sure I didn't mess up the text Has to make that change all right In that case, believe it or not. We are actually at the end of the agenda Are there is there any other business people would like to bring up at all? I have a question, but it might be more suitable for the stk call that's after this Okay, that's fine. It's only in eight minutes so we can wait Yep Okay, in that case Scott's favorite subject Jeff are you there? Jeff Holland? Yep, I'm here. Okay. Is there anybody else I missed relative to the roll call? Here's the complete list Hey, this is Vlad Hey, Vlad. I'm sorry. I apologize I joined a bit late. Sorry. Yep. Not from anybody else It's Heinz as well. Oh, hey, you're back. I tried to talk to you really, but then you vanished nasty vacations No, no, I meant you're on the call earlier and then you vanished right as I was trying to get you to speak Oh, yeah, it uh, I was dialing in and uh, all of a sudden everything literally froze on my uh, browsers So I tried to do that. Yeah, okay Um, all right before I answer your question Christoph anybody else I miss roll call Okay relative to Christoph's question about did we get all v1o issues? Um I actually don't think we did yet to be honest I need to double check because some of these issues we can now close Um I think let's see starting at the bottom Okay, we need to decide on this one from thomas from ages ago To to see whether we've actually done basically testing and usage testing to make sure that we actually Use this in a world of experience Uh, this one is evans pr I think we can close this one Think thomas. I'm sorry. I think tims will deal with this one that one we did All right, consider moving the web looks back that one's an open question I think Clemens you had a comment on that. I need to look at your comments and respond Uh, if any worst case scenario if we actually do that it's removing a document. So it that'd be an easy thing if we do um But worst case isn't but Best case scenario is we change nothing. So it's either going to be a very bullying kind of a thing in my opinion So, yeah, I think we're almost done with issues I'm uh, I'm looking for whether we there's a good place for that document to move Yeah, we haven't we haven't finished that discussion yet. So there's uh But that's also going to be interesting then because it's like there's a play I think there's a place within within the linux foundation where that might be able to move or within cncf Where I might be able to move there's a there's a spec spec team And then there's also an effort within w3c. But then, you know, the document has been created here so there's all kinds of Interesting complications on moving that out to w3c. I don't even know how that works So we're we're there's some some Microsoft standards people Talk about all that might work out. So because I certainly don't want to bend the spec per se All right, I think I think the mechanisms that we have there are useful um specifically the abuse protection and and just a The fact that you deliver an event with using a post that's something that the our htp Uh binding doesn't specify it basically just binds the the The event to an htp message, but it doesn't even say that you deliver with post It doesn't talk about the error codes that you expect on all those things are in the web workspace So if we're dropping that then we're dropping a bunch of interoperability features That we have currently in this repo All right. Well, okay. Yeah, we but we can continue that discussion offline, but I think that might be the only one that's actually outstanding christoph um But yeah, I think I think the last couple weeks we did some really good progress here on closing things out and um It may be You know, we may get to the point where assuming we merged tim's pr next week where next week We may actually consider going to 0.9 and making that release candidate and put us in that You know testing mode that thomas was looking for and his issue down here on 202 And you know make sure everybody reads the spec You know the fine-tooth comb looks at their implementations of this stuff do some testing and then We may be on the verge of 1.0 Wouldn't that be cool? Nice. Yeah, so we maybe we may be really close Wouldn't that be cool if we went 1.0 before kubecon? That'd be awesome Anyway, don't want to get our hopes up All right, any other topics then All right, cool in that case. We are done. Thank you guys and just reminder in four minutes We have the stk called if you guys are interested in that or for those of you who are interested, I should say All right, cool. Thank you guys. We'll talk again next week. Thanks. Thanks, Doug. Yep Thanks. Bye. Bye I'll be right back. I need to check on something You