 So little ones are not very exciting, so we can move on. Just keep in mind, if you do have some, some AISs. And do you please get to them when you get a chance? Nothing happened with the face to face planning. Apologize that. I also did it for the partition key ultimately. That was that discussion. I think that's exactly the place where we should go and do that work, to figure this out, work into the Kafka PR. Okay, done. I made a note in the Kafka PR. All right, time for our calls. All right, not hearing anything. Let's jump into the SDK stuff. Yes, hold on a minute. There you go, go for it. Okay, now. Can everyone see this? Yep. Great. Okay, we've had a few separate calls. Too interested in working on the... What we did during that call is we, you know, we clarified priorities for the Cloud Events SDK version 0.1. Here's what we're looking at doing for that. We want to support at least three languages. We want the SDK to allow users to easily instantiate Cloud Events in code per the Cloud Events specification. And we also want to define, you know, basic APIs, getters and setters for these Cloud Events instances. And the goal is just to give developers a great experience for just getting and setting information on their Cloud Events event instance. And also just maybe perhaps getting into some mocking of Cloud Events for testing. We haven't discussed that too much yet. Next step was determine how to handle versioning across the SDKs, the Cloud Events specification, the transport specifications, as well as extensions. This is something that I'm going to dig into in just a second here because there are a lot of moving parts. And the SDK is kind of one of those places where all those moving parts come together and all these moving parts have different versions. And we need some advice from the group as to how about handling all this stuff. But before I jump into that, the last big priority for version 0.1 is support for extensions. So we feel that extensions should not only be custom properties in the event envelope, as they've been discussed within the context of this call. But extensions are also middleware and hook functionality that can be optionally loaded into the SDK. And that middleware hook functionality is the functionality that will add that custom extension metadata to the event envelope. So for example, if there's a distributed tracing extension, there could be this optional library, which you could load into the SDK. And that library will help you set the correct distributed tracing information in the Cloud Events metadata, as well as give you perhaps some additional handlers or methods to pull out interesting information from the Cloud Events as they're instantiated in code. So this is how we're thinking about extensions. We think this is important because this is, well, I think Cloud Events is going to live or die based on whether or not it gets community support and adoption. And we think that extensions are going to be the place where the community really plugs in. So that's the open source community has the ability to make their own, basically libraries and metadata to extend Cloud Events. We think vendors need this as well. And we also think that organizations and teams who adopt Cloud Events are going to need the opportunity to make their own extensions, perhaps with their specific applications or business domain generally. So anyway, these are the big priorities that we're focusing on within the first version of the SDK. Maybe I'll pause there in case anyone has any questions. Okay, great. And again, I'm reading off this Cloud Events SDK design proposal. I think this is in the Google Doc that Doug uses to organize this call. And if it isn't, maybe Doug, we could put it in there so that it's easy to access. Yep, it is. Sorry, can I ask a question? Yep. About the extensions you write there. Can you scroll down just a bit? Adding support for different vendor solutions. Do you intend, you write middleware, but you also write hook. Do you intend the Cloud Events SDK to be the front end or to be integrated into vendor solutions? That's a good question and don't have an answer for that yet. I think that we'll have to see what the market wants to do. But there's two ways this could happen. The vendors could offer Cloud Events extensions that fits right into the Cloud Events SDK and perhaps that might be the best approach if the Cloud Events effort in general gets a lot of traction and end users seem like they want to prefer using the open standard option rather than a vendor-specific option. So that could be a good solution for that. However, at the same time, we want to make sure that the Cloud Events SDK is something that you could require into maybe your vendor-specific SDK as well so that you just leverage the Cloud Events SDK behind the scenes. A lot of different use cases. We're covering a lot of different surface area and I'm not sure how this is going to shake out yet, but those are things that... Yeah. I just wanted to bring it up to maybe think about that in the design. For example, if both use cases are like first-class citizens, maybe the API should not be a single huge API or things like that. Just think about it. Sure. Yeah, absolutely. It will learn this. I think the SDK is going to be perhaps the first instance where Cloud Events really becomes accessible to end users. And we'll learn a lot as to how people want to use the Cloud Events specification overall, as well as what they think the role of the SDK is. But anyway, good things to consider. Thanks for raising those. Yeah. I just want to echo that and say, I think it's great to say we'll see how users use this, but we could be more opinionated about what we think will work well. Yeah. Totally agree. Doing these things both at the same time is in our best interest. Quick question. When you say you're going to support three languages, what are the currently targeted three languages that you're looking at? Well, these languages are going to be determined based on the people who want to volunteer their time and energy to help create these great SDKs. So while we'd like to say, hey, these languages would be great, I think it's really going to come to who's actually going to contribute the time and what languages they want to focus on. I will say that we have volunteers already focused in specific languages. And that is Red Hat has been focused on a Java implementation. VMware has been focused on a Go implementation. Our company, Serverless Inc, is focused on a JavaScript implementation and there was another gentleman who was starting a Python implementation, but we haven't touched base with him for a little while. So we have some volunteers for these languages right now. Microsoft will volunteer for C Sharp implementation just to find who to volunteer. Thanks, Clemens. Yeah, you mentioned that before. Now it's written down and let us know when you find the poor soul who will. In doubt it's me because I just said it. I was going to suggest that, but you never know. So these are our priorities. We have a version 0.2 kind of specced out here. And the way we've been discussing it in the context of these calls is we're laying out, we laid out our kind of the various scopes of work. We'd like the SDK to accomplish over time. And we prioritized all these within this document. We took those priorities and we broke them down in the actual Cloud Events SDK versions. But it's really going to be up to the people working on this as to whether they want to just do some of this or whether they want to go ahead and go a bit further. We're trying to use these SDK calls as well as this document to help harmonize our efforts and make sure that we're going about implementation in a uniform way as possible, even across the various languages and runtimes. But again, we're trying to start here and if people want to move faster and start investigating some of these challenges later down the road, I think they should feel comfortable doing that. And also, in addition, there are some basic design goals. That we discussed on the last call around perhaps how to handle some of the versioning concerns. So we're going to keep updating this as we move along. But I think the next most important thing for us is really just to discuss some of the versioning issues that we're coming up against within the SDK and get some feedback from the larger working group. So first off, the SDK again is a place where a lot of moving parts come together. First off, we're going to be dealing with multiple versions of the Cloud Events specification. It seems highly likely that people who are building applications based on Cloud Events are going to have to handle Cloud Events that have conformed to different versions of the specification. So if someone has an application that they built on Cloud Events and it's been running for a long period of time, it seems like they may have old versions of Cloud Events in that system as well as possibly new versions of Cloud Events in that system. So we want to make sure that the SDK can has a good answer to handling various versions of the Cloud Events specification. So that's one concern we have and something we have to think through. Then there's the additional consideration for the transport specifications. And that is, we have the separate specs for each transport in the SDK calls. We've largely just been focused on HTTP for now. But there's a whole other set of challenges here as to making sure that the Cloud Events SDK can, let's see the scenarios to consider, can generate and deliver events directly to an HTTP endpoint where we don't know what version of the protocol the endpoint supports. Or sorry, where we do know what version of the protocol the endpoint supports as well as where we don't know what version of the protocol the endpoint supports. We want to be able to publish and format events that can be sent out to endpoints, perhaps running different versions of the protocol. We also want to be able to upgrade an event, perhaps to match a version of the protocol, maybe downgrade an event to match a version of the transport specification. Just a few different scenarios we think could come up when actually architecting a system around Cloud Events and the specs that we've defined so far. So how we actually handle various versions of the Cloud Events specification and various versions of the transport specifications within the context of the SDK is something we'd like to get feedback from all of you on. And then before we actually hear from everyone, I just want to cover the last few moving parts because they might be related. And that is extension versions as well. So extensions are going to need to understand what version of the specification is involved, perhaps what version of the transport specification we're looking at, and they're probably going to need to be versioned themselves. So the distributed tracing extension, for example, may have its own versioning mechanism. And then, of course, lastly, the Cloud Events SDK itself needs a version. So anyway, a few questions as to how to deal with these few priority things. And that is the first question is, will the transport specifications continue to be versioned separately from the core Cloud Events specification? So I actually opened up a PR to talk about this with the proposal basically saying that everything gets versioned together, transport and spec. OK. Well, that sounds like something we need that the working group has to decide on. Yep. What I would suggest is to version them all together and that's because that's what everybody looks at. If we want to keep track of the individual document traces, we can go and make documents versions, basically counters, to kind of keep track of if you are currently within 0.8 and you're kind of advancing that draft, that you still have a way to keep track. So you're in V8 and you're now in working graph 13 that you know where you are. But overall, this should all be versions together. Agree. Yeah. It sounds much nicer. I haven't thought through all the implications of that, but it certainly sounds nice. Because otherwise, one thing we thought in the scenario where the SDK is perhaps being used in a serverless function and it's just received this event that contains, maybe perhaps just a generic HTTP request and of course the Cloud Events metadata is within the headers, are we going to have to also include perhaps a header that indicates the Cloud Events, HTTP transport specification version because we want that SDK to be able to just look at those headers and kind of assemble a Cloud Event automatically for the user. So the user doesn't really have to craft the Cloud Event from that HTTP request. So if these things are versioned together, then I guess we could just look at the Cloud Events version metadata and understand how to assemble the Cloud Event from the HTTP headers just based on that. That sounds easier. That makes sense for inbound also, but that doesn't make sense necessarily for delivering an events to the endpoint. Because if you're on the front end of that, you're creating the event to begin with, you need to be able to know what version the given endpoint actually supports. Yeah, that's a great point. Okay, so this would help for inbound requests. So in the context of an outbound request, if the SDK is going to have some published method that actually sends it out via some transport, and again we're just kind of focused on HTTP for now, and they're going to send it out to, I guess, HTTP endpoints where they likely, I guess you just should not assume to know what versions of Cloud Events those HTTP endpoints support. Perhaps the best way to deal with this is just to send out, shuttle off the Cloud Events, shuttle off the Cloud Events with a specific version, and then hopefully the services that are exposing those HTTP endpoints are also using the Cloud Events SDK, and as long as that Cloud Events SDK can support multiple versions. We could theoretically be okay. See, that's where I don't think we can make that assumption, because we're not necessarily in control of the endpoints either, right? So assume like, let's say we go from one to 1.1, and I upgrade my SDK, but the endpoint has not upgraded yet, then we can't assume that 1.1 format will work within the 1.0 context. So really, it almost seems to me like there needs to be kind of like a pre-flight check to be able to determine what version the endpoint actually supports, and then gives the SDK a chance to downgrade the event format in the event where it realizes this endpoint does not speak this version of the spec. That doesn't work in asynchronous communication, so there should be a way to overwrite the version where you just have to know what the consuming applications should then support. Yeah, one second there as well. So Austin, did you mean for this discussion to get into a deep dive technical talk, or did you want to offload that to the SDK calls or proposals to Google Docs or whatever? I'm just wondering whether you wanted to have that deep dive right here about the technical details. Well, to be honest, I was kind of perhaps hoping for a quick win, a quick solution. Usually the wrong hope to have. So given that this is more complicated, I think we should open up an issue to dig into it. So this is Tim related to that. I was going to have an opinion on that, but instead of doing that, I'll have a meta opinion saying, so where is a good place to talk about it? Do you plan to advance this mostly just in telecoms? I'm sorry, I missed the last one, I'm a bad boy. Or is there going to be email, slacks, whatever? Yeah, the way I've been coordinating this effort right now is largely to do it through this document and to list all kind of our outstanding questions there. However, I think this should be done. I think this should be done through the GitHub repo somewhere so that it's tracked. People can always find the discussion. So perhaps I could open up the issue just in the cloud events repo and we could discuss it there. Yep. Shall we make an SDK repo to track those issues? That's the next issue or topic. Yeah, that was going to be the next topic. Related, but anyway, just want to clarify, we need some answers to these questions because these are going to be blocking issues for the SDKs and how we handle these scenarios is definitely something we have to think through as a group. So anyway, I'll open up the issue. As to where I'm going to open up the issue, this kind of leads into the next question that is project structure. I think we had two suggestions for how to do this. It seems like all the volunteers who are working on this are totally fine with hosting the SDKs that they're contributing to within the Cloud Events org on GitHub. And I think the question now is whether we just want to do a mono repo structure and that is put all the Cloud Events SDKs into a single repo or we should create separate repos for each language. Does anyone have any strong opinions on these? Separate repos. I'm in the separate repos camp. As well. Me as well. No. Separate is better. Okay. Maybe perhaps one challenge with that is simply to discuss in general design of SDK and to answer questions like this, if we're spread out across a lot of different repos, perhaps we should just keep the discussion within the core Cloud Events specification repo and keep language-specific implementation details within the specific repos. That sound reasonable? Yeah. If the number of issues or topics related to the SDK gets kind of overwhelming for the spec repo, we may need to open up a separate repo just for SDK issues that are cross-cutting. But yeah, for right now, I think it's okay. Okay. Okay. Fantastic. So Doug, if we can make these right away. The volunteers can start pushing their work. So SDK Go, SDK JavaScript, what else do you guys want? We have a Java, Go, JavaScript, Python, and apparently a C-sharp implementation. Okay, got it. Okay, we'll do. And last question I want to raise to the group is, is there anyone who's interested in volunteering to move these along who's not currently on this list? Don't all volunteer at once. I'd like to help on the Go ones. You can stick my name in there. Okay. All right. Well, we'll see if we pick up... Sorry, I was muted. Austin, this is Jesse Butler. I could help on the Python front. Not too much of a language stickler. And if you've lost somebody there, no I would. Thank you. Yeah, happy to. Thank you. Thanks for volunteering. Okay, great. This helps me kind of make sure I reach out to all the people who are volunteering to keep them informed as to what we're doing. I think we'll probably have another SDK call soon here because we need to clarify how we're handling some of these versioning issues to unblock the implementations. So, okay, look out for the issue regarding how to handle some of these versioning issues, as well as the GitHub repos. And I will coordinate another SDK call probably shortly here. And that's it for general SDK updates. Does anyone have any questions or comments? Just a quick comment on the handling the different versions. I think probably we can do like before sending the message, we can do like negotiation between the event source and the event consumer on their versions and then find the common version. Yeah, that sounds similar to what Brian suggested earlier. We're doing like a pre-flight request, perhaps. Yeah. But I think there were some issues or some concerns around that design. So I think we should move this conversation to that GitHub issue. I have a question. So it seemed like the Go SDK was running into trouble with the headers like losing their capitalization. And there's an existing issue in the spec for that. Should we just highlight that, that we need to address that issue? Yeah, I totally forgot about that one. So thanks for bringing that up, Rachel. And that was Nick who raised that. Is Nick on the call? Yes, I'm here. Hey, Nick, would you like to discuss, would you like to communicate that issue to everyone here? And I'm not sure if you have an issue open already for this, but if there's a place where people can follow up, I think that would be helpful too. So yes, I believe there is an issue open. It's an old one from before June, I think. Yeah, it's from April, I think. I believe it's issue 177, but I can be wrong. Yeah, so it's 177, I will post it in the chat quickly. But basically the issue comes down to the fact that in the HTTP spec, headers are defined as case insensitive. And in particular for the Go implementation, Go does what the headers is. It canonicalizes them as they call it. Basically that means anything after, the first letter of the header and anything after a dash is capitalized, everything else is lower case. Which means if we have in particular extension properties that we put into the header for the binary transport spec, in Go in particular, and I assume in other cases where a proxy might mangle the headers or something, the case sensitivity of the header is lost, and we can't guarantee that we've used the right case as the property name in the JSON, for example. So if I'm in this SDK, I am accepting a HTTP version of the thing and forwarding on to a JSON endpoint. In particular for extensions, I can't guarantee that they'll have the same casing when I pass them on, right? With the well-known ones, I can go ahead and make my own determination and put the correct case in there manually. But with anything that's an extension, and this becomes a bigger problem for the versioning portion of it, if an older version of the SDK needs to deal with an extension that's been promoted, it can't automatically do the proper casing of those headers. So basically, we have to either make a decision that the property should be case-insensitive or perhaps that gives some other way in the property name for the header specifically that indicates which of the letter or which of the casing of each of the individual characters. So perhaps the simple way in go would be anything that you want to capitalize needs to have a dash in front of it. All right, so I think this is best maybe discussed with N177. Yeah, in NQP, for instance, you have the opposite problem of all property names, so headers, to be case-sensitive, which means there you need to rely on the case being right. We should have that discussion in the issue, but I think if we end up saying everything must be lower case, that might be the same place to land in. So basically, make a case-insensitive, but then also try to keep it all lower case. Okay, well, let's talk about the issue, because we did do other things on the agenda for today. So thank you, guys. Anything, any last questions or comments related to the SDK work? All right, thank you. Kathy, I've noticed you added an PR. Hold on a minute. To discuss for the workflow stuff, let me open this up here for you. All right, Kathy, do you want to talk about this one? Yeah, so this one just fixed a link issue in the written file and also add contributors who has contributed to this workflow spec. I saw a comment requesting that, asking who are the authors. And also to be compliant with the cloud events. So just add a similar format to the cloud events. Yeah, if I miss anyone, please let me know. Okay, I think there is an outstanding comment that you need to address, either say you don't want to do it or merge in that change. I made that suggestion. But other than that. I think it's just adding a link to the right spot. Because we're not actually pointing to a GitHub repo, it's actually pointing to a directory. Oh, okay. It's a minor thing. But in terms of process going forward, I'm assuming that we're following the same process here that we do with all the others, which is, at least for changes like this, that are strictly editorial in nature for the most part. We just need one or two LGTMs and then we can merge it in. So I think what Kathy's looking for here is some people to put some eyes on here and to LGTM it once this comment is addressed. Is that right, Kathy? Yeah. All right. In that case, is there anything else related to the workflow work, Kathy, that you'd like to discuss? Not really, yeah. I think that's about it. So I think we're going forward. If there are any issues, we can have more discussion, have more meeting discussion. Okay, great. Is there any questions or comments for Kathy? I have one for you, Doug. So your comment here that is adding, you want her to add the word directory to the link or after the link. What's the point of this, I guess? The point is I was, she said it's being done in the GitHub repo and I thought that was a little misleading because it implied that their work is being done someplace else when really it's being done within this repo just in a directory. Okay. So do you want her to just say it's in the directory and sub-same in the repo? Yeah, basically. Yeah, basically in the workflow directory that I'm looking for as opposed to in the repo. Okay. Minor typographical thing, whoops. So it's okay. So you are just giving to change the wording? Yeah. Yeah, just saying being done in the, yeah, just say in the workflow directory here instead of GitHub repo and then make it a link. So it actually points to the directory. I think I have a link here, right? There is a link. I already added a link. But not in the sentence, just add the link. When you change it from GitHub repo to workflow directory, turn it into a link. Oh, okay. Okay, I know. That was it. Okay. This is just a little bit of a click. Okay. Okay. Cool. Thank you, Cathy. All right. I don't think we have any issues necessarily to discuss from terms of looking to close them. So we can jump into Clemens old action item and UPR. Do you like to discuss this one, Clemens? We had discussions about object versus any because object clashes with the concept of JavaScript. And I meant it in the way how Java and C sharp do it as kind of the any type. We then landed on using the name any after discussions. And what this does is this change catches hopefully all places where we are referring to this particular thing as the object type and we're nature to be any type. And that's all it does. Any questions or comments on that? That also included double values. Excuse me. Does that also include null values? So I just renamed it. So that's all that's a different discussion. I think I just, I just renamed the type whether we, whether null values are their own type or whether they are values of string or binary. That's something that I haven't particularly that we haven't defined yet here. Okay. I'm just curious. Yeah. We currently are implicit does not include any like null as a type. And there's only whether something is defined or not. Yeah. I don't know of any case where there's an explicit difference between present and null or not present. And honestly, I would, I would think that would be a very bad idea. Yeah. In fact, I think all of our cases where we say if it's present, it has to be like a non-empty string or something like that to specifically avoid that kind of stuff. So let me call on one particular person, Thomas. I know you were deeply involved in the conversations last time we had about this. I assume you're okay with this. I think you were okay with changing that. I think this looks good to me. Okay. Anybody else have any comments or questions on this one? All right. Is there any objection to adopting it? All right. Not hearing any. Thank you. Okay. This one, while the last set of changes on this one technically went in, I think, either last night or this morning, depending on where you are, the actual last set of changes are actually picking up just text right here, which was put in six days ago. So technically, the changes are more syntactical in nature. I believe as I'm- And I want to apologize. She has an editor that rightly, as all editors should, removes trailing white space. So that's some of the changes here. Yes. It actually made me very happy to see that. So thank you. But I believe this is the both. Everything else is just white space. And this is the book that changed right here. Is that right, Rachel? Right. All right. So any questions or comments? Oh, Rachel, actually, do you want to talk to this? Okay. So this is a really quick change. I think we've talked about before this change. So before the standard for being a de facto standard, sorry, the bar for being a de facto standard, that's less confusing, was that you should come out of a multi-company consortia. And we had some examples. This changes it to be that you could come out of a multi-company consortia, where you could be released by a single company. The point is that you have a strong ecosystem around you. That's the change. All right. Any questions about that? None? All right. Any objection then to adopting it? Too easy. Thank you, guys. And thank you, Rachel. All right. This one, not only resolved that bit of text, but it's also resolved that bit of text. Okay. So we have the Polestar Transfer Binding. I did ask the author of this PR if they could help us, or let us know whether they thought they actually met that, the new minimum bar that we've defined. And basically, they said, no, it does not. So they're okay closing it. However, before I closed it, I wanted to make sure that there wasn't anybody in the working group, sorry, the project, who thought there were some reasons to keep it open for some reason. So is there anybody in the call who objects to closing this one? No, I think we need an advocate for it. If they're not going to advocate for it, we can't keep it open. Yep. I agree. All right. Anybody else? Okay. So I will close that later. Thank you. All right. Now this one, as I mentioned in my email, this did go in, I think, just yesterday. So it's a little bit new. However, I hope people got a chance to look at it. It is relatively straightforward for the most part. For the most part, it's really syntactical. I did remove the notion of us being a working group because we're not a working group, we're just a project, actually a sandbox project. The only bit of new text that I added, this is modifying our governance docs, just try to be aligned with what we're actually doing because I think we had some holes in terms of being clear about what we're doing, is I added some little bit of text here that said, you know, we're going to encourage offline discussions in particular, we're asking for older reviews. And then I did talk about the different types of membership here. And mainly, I want to make it clear that pretty much anybody who contributes in any fashion, whether it's just joining phone calls, writing PRs or issues, they are members and no formal registration is needed. Voting members are really no different than normal members in terms of rights other than they get to vote. And I did point a reference down to the voting section to talk about how you get voting rights. This is Ty Bo. Influence, respect to influence over the group actions. Okay, I'll fix that. Thank you. And then I'll talk about admins. Basically, they have no special rights whatsoever other than they can do stuff in their GitHub repos. They moderate the meeting and stuff like that. But they only do it on behalf of the working groups. The working group basically has to agree to all those changes anyway, but then they get to actually do the actual action itself. The only other change is tabs spaces because tabs are evil in case you didn't know that. I did add an owner's file just to define who the current set of admins are. And it's basically the same sort of code shares from the service working group. So me, Mark, and Ken, other than that, it's just working group getting rid of the work working group for the most part. If people would like more time on this, feel free to speak up. I don't want to rush people, but it did seem like a fairly minor set of changes if people are okay with it. Any questions or comments on this? So in the owner's doc, you can totally do this as a second PR, but it would be nice to have some documentation for what happens when one of these three people wants to leave, like how those people came to be and how they will be replaced. Yeah, I'd like to serve PR mainly because I think that's going to require a little bit more thought if that's okay. Anything else? I have a question. Should we open an issue with that? Yeah, I'm going to keep on. I'm going to put down the notes. I have a question. So for the, I think the voting is, the voting right is through the attendance, right, tracking the attendance. I think we discussed before that if someone is on business trip, he or she can have a representative, right? Yeah, the voting rules did not change because of this PR. The voting rules are still the same. Each company has a primary and an alternate. Does that answer your question, Kathy? Yeah, thank you. Yeah. Okay. Any other questions on this? Okay. I guess my only question is that Ken Owens isn't, I understand why Ken Owens would be an owner because he's in the TOC, but has he ever been to one of our meetings? Yeah, I think he, I know he's been to the serverless ones in the past and I think for the cloud events, it was maybe one and the reason he's listed is mainly because he's the, what's the right word? Sponsor or champion? Yeah, he's a sponsor for your project, yeah. I think that's why he sort of got in there by default. We can have that discussion about whether it makes sense to keep him. But like I said, it doesn't really give him any more rights other than he can perform administrative activities on behalf of the group if he needs to. So it's not like he has special voting rights or anything like that. That's why I felt comfortable with keeping him in there. So Doctor, and I'm going through this, I see it's having any of their assigned representatives. So could this be changed? Like, you know, for example, sometimes, you know, like I said, someone cannot attend the meeting because of business trip or other reasons. Could he or she direct have another one, represent? Yeah, so that's an interesting topic. So basically what you're talking about is someone basically, what's the word I'm looking for? Clemens, you can help me here. Someone take on your... Alternates. That doesn't alternate. I think cases like the standards and meetings. Yeah, proxy, that's the word I'm looking for. You know, some of your proxy for you. So I think that's an interesting topic. I think, Kathy, if you want to head down that path, I'm okay with exploring it, obviously. But I think that's a separate issue because what you're basically talking about is modifying this section, which I purposely did not try to modify. So if you want, if you want to head down that path, can you open up an issue to open up that discussion? Yeah. Yes. At the time when we discussed that, the idea was that three meetings aggregate by both the primary and the alternative. Not each one of them has to have three concisive meetings. Correct. Primary or the alternate, yes. Yeah, I think the wording is confusing. Maybe English is not my native language, but for me to read it, it sounds like it needs to be either of them. Each one of them has three. Yeah, any of the assigned representatives attend three out of four. So the key word there is any. Yeah, but it's not the aggregates. Like I'm coming to two and he comes to two, then it's four. Okay, so do me a favor. Can you open up an issue or a PR with some proposed wording? Obviously, that's definitely the intent. So if you can think of some better wording, I think that'd be good to make that change. Yeah, I can open one. That's my question too. Yeah, that's fine. Yeah, all right. Hi, any other questions or comments on this? Is there any objection to basically doing a vote on this right now? Does anybody feel like they need more time? Okay, not hearing any. Is there any objection then to adopting it with? Let's see. Fixing the misspelling of influence. And I'm going to open up an issue to talk about how to remove or add admins. Any objections to adopting it? All right, cool. Thank you very much. This is interesting. So I did open up this issue, and I said I was going to talk about it, but I don't think we're ready to take a vote on it because of what Eric mentioned. So what I tried to do was, as Thomas put it, was do some homework for him. Well, I tried to take a first pass at defining the minimum bar for adding a new extension. The basic rule here that I try to put forward is it has to be an indication from at least two people or two companies that they want, that they actually want this and will use it. So at least two independent projects will implement it, basically, or have interest in using it. Now, Eric, you raised some concerns. I think you're on the call now. Would you like to talk about your concerns on the call or just let Bill read it in the issue? They're welcome to read most of it in the issue. I think the one that, and this may relate, I'm sorry, the commute was terrible, but this may relate to the earlier PR that was discussed, is whether the conditions that we're laying out in these documents can force our hand as a group. So can two people create two projects and those two projects independently endorse an extension and that extension, because of this document, has to be put into the extension's document. Now, it's coming from a paranoid space. It seems like an unlikely sort of a thing. And also, I was curious just about the way that we've been wording it has been kind of removing us from that workflow. And it seemed like the real value that we're trying to provide there is guidance to someone that's looking at the specification and wondering if they'll be successful in submitting their alteration, whether that alteration has any chance of being accepted. Yeah, so I think those are one at a time, I guess. So first of all, I think your first question there about, can some basically play games? And the same group of people produce two independent projects and therefore meet the bar and force us to take their stuff. I'm not sure how to word that, other than to have the word independent in there. Because I don't want to get too legalistic about this, but can you think of or anybody think of ways to avoid that kind of game playing? One idea I was just playing with in my head, I'm trying to figure out how to make it not too much of an in-crowd, but basically saying if you have two endorsing voting groups, it doesn't matter how many people are disinterested in the extension, it's just like if you basically have people who have been interested in cloud events that, I can't, for example, create a new project and have represent that and have Rachel support me because we're both in the Google voting block. That's interesting. So I have at least two people within our group say, yeah, we want this in here. From different voting organizations. That's interesting. What do people think about that? My worry is that I don't want someone, I don't want to make it so that only our extensions are allowed. My counter to the paranoia is what's the harm. Yeah, fantastic point. I think the harm would be a reduction in value, potentially, of the document. So what do people think about Thomas' idea of at least two independent working group members saying yes? I like it. This is Roberto. I like Thomas' proposal. Okay. Now just a quick question. Is it, I'm assuming it's not just any member of the group, but it's voting member of the group. Is that correct, Thomas? Yeah, the type of rope I was trying to walk, and I'm not sure I fully love all of it, was A, it was two endorsements. And so it was voting members, but also specifically not something that is voting. It doesn't have to be a majority rule of voters. It's just any two, specifically sponsors. Right. But my point was you couldn't just have someone basically join one phone call, and suddenly they get a vote and can help influence it because that still opens a door for major game playing. They'd have to at least join four. Yeah, well, that, yeah, that's true. Okay. So what I think I'm hearing is changing this wording so that it has to be at least, as you said, endorsed by at least two voting members of the project. And, but that does not imply a formal vote. Just at least two voting members say yes. And are they exclusive, are they not the implementers as well? Is that the implication? I was going to say no. I think, I think, so if Google wants to propose something, I think Google should get a vote because they are one of the two and they're part of the, and they're, they are part of the voting members, I assume. But do you guys want to make it non? I was just asking for clarification. Yeah, what, what do people think? It's selfishly, I don't, I would like the bar not to be raised higher for me as a Google employee than for someone independent. I actually shared that view because there have been situations where I was the only IBM arena group and I happened to be the one submitting all the poor requests and I couldn't LGTM it. So what it meant is I had to get someone else to submit all my PRs for me and that just feels like game playing. I'd rather not get into that situation. Yeah, I think that's fine, you know. Whoever implemented can also vote. Yeah, okay. Any objections to hang that direction? So at least two voting members approve it joining, being added and submitter can be one of them. Yeah, and there could be even kind of a middle ground that like, yes, Google can vote for something I propose, but I can't myself. Although that might be the exact thing you're saying you're trying to avoid, Doug. Yeah, I'd rather not get into that. If that happens too often, we can always go back and amend the rules. I think having at least two companies say yes, even if it's the same person who proposed it is fine. Yeah, why don't we also just try to serialize these things that we think might be bugs in our process in the poll request that way if someone wants to refer to it and say, hey, you said we could change it if this happens, then they have a documentation to point to. Yep, so we would be clear. You're basically asking me to make a comment in this PR that says, this is just a point of time statement that we could change these rules later. Yeah, and that like, here are things that we think might go wrong and we'd be willing to change it if in practice they actually go wrong. Okay, hold on a minute. Oh, it'd be nice if you guys actually see what I'm typing. Also, rules that require too many people to be present in the overall process start to become real blockers once the working group or sorry, project gets a little quieter because we're kind of done with one and then people are moving to implementation rather than writing more spec. Because in the end, then there's only five or six people left and then if there's process that requires seven people to be present, it's a little difficult. Yes, and keep in mind, these are just extensions. It is meant to be a fairly low bar, so. All right, any objections then to heading that direction? If not, I will update the pull request and we can look at it for next time. All right, cool. I'm not hearing any. I think we only have less than four minutes left. I don't think we have time to jump into another issue or PR. So let me ask if there are any other topics people would like to bring up before I do final roll call. Okay, I'm not hearing any. Chris, Borchers, are you there still? Yep, I'm here. Okay. All right, I think I heard you. Brian, I heard you. Luciano, are you there? Luciano, you still on the call? Yes, I'm here. Oh, there you go, gotcha. Yeah, I'm here.