 I was worried about you because when you are at this place in the document, you usually say things. I know, I'm sorry. I was distracted trying to install Zoom on another computer so I could actually see what the heck I'm actually sharing, but I'm sorry. I'll stop being distracted. Manuel, are you there? Yes, I am. All right. Slinky, are you there? And Jessica? All right. What about Javier? Yes, I'm here. Hi. Hello. Tommy. Hey. Hello. Mattias. Hi. I'm here. Hello. Hello. Hello. I hear you. Thomas, are you there? I'm here. Hello, everybody. Hello. Timer. I'm going to put your name again. Timer, are you there? Here. All right. What about Remy? Yep. And Eric? Yep. And Slinky. All right. Christoph. Hi. Hello. Hello. Who was that? I'm sorry. I got distracted. It's me. It's Slinky. Oh, Slinky. Sorry. I'm sorry. I was looking. I'm trying to do too many things at the same time here. Oh, cool. It does show up massive on another screen. Okay. So I'll leave Zoom. My other window. There we go. Hello, Ginger. Good morning afternoon, Doug. It always cracks me up when someone goes through every possible answer to that thing. They say hello. They run through morning, afternoon, evening. It's like, okay. We're trying to be polite and politically correct lately. So I don't even know what to say anymore. No, no, that's fine. I understand if you, if you, if you hit down the path of choosing one, then yeah, you're kind of stuck and you have to say them all, but I don't know what to do. Or if you have a question. And someone just doesn't say hello or good, you know, just, just leave it at that and not even give a time zone. Kind of a thing. Just, just amusing. Everything's so confusing lately. All right. The Navy there. Yes, Sam. Hi Doug. Hello. David Beck. Are you there? Yes. I'm here. Is this your first time on the call? I can't remember. get to know about cloud events just an hour ago and I was just interested now. OK, if you would like to be associated with the company for attendance, let me know that name either in the Zoom chat or in the document itself, go ahead and edit it. If you want to be associated with the company, that's totally up to you. OK, OK. Sergei, are you there? Yep, I'm here. All right, Brian, are you there? Yep, I'm here. Let's misspell your name. Christian, are you there? Morning, Doug. Good morning. Oh, we had two Christians just to mess with me. Hold on. Christian, no, I'm T-Z-O-L-O-V. Are you there? Yeah, I'm just looking for the mute button. Hi there. Yeah, it's my first call here. But yeah, I'm working on the, yeah, OK. I just pasted a link. Yeah, I just pasted a link to this Google doc. If you want to add your company name next to your name, if you want to be associated with the company, just go ahead and add it all. Yeah, it is VMware, so. Oh, that's easy. OK, I can spell VMware. OK, maybe. All right, Klaus, are you there? Yes, I'm here. All right, Ryan, are you there? Yes, hello. Hello. Ricardo, are you there? Hello. I'm sorry, not Richard, Ricardo. OK, this may be your first time on the call, right, Ricardo? Actually, no, but it's been a long time since I joined. Who is it? Which country are you with? Red Hat. Red Hat, OK. I'll put IBM. OK. Please don't. Did I get everybody? Lance. I'm here. All right. I think that's everybody. Did I miss anybody for attendance? OK, we got everybody. I'll circle back around later. All right, let's jump right into it. All right, community time. Is there anything that anybody from the community would like to bring up that is not on the agenda? All right, moving forward to SDK. We do have a call scheduled right after this one. I do have a agenda item on there. It's more of a bureaucratic process kind of thing. So if you're interested, please join. It'll be right after this call. Workflow, Timmer, do you want to update us on anything going on the workflow stuff? Yeah, from the infrastructure, we're setting up still a repository and working on that on work on the specification. We have Ricardo, who just you talked to, and he is going to contribute our Kubernetes custom research definitions and some Go types for it. So if anybody is interested in that area, let me or us know and definitely can help on that. And we're also in the process of adding a Java SDK or like a SPI type of thing. So we're kind of like the things going on. And just trying to get the community behind us or increase the number of people that expose ourselves to more and more people to get more help. And that's kind of like the current steps, things. Cool. Any news on the, what's it called, the sandbox proposal? No, the SIG people have a meeting. Sorry, the delivery SIG has a meeting next week. So I was told kind of like that would be the date that meeting would be where they make a decision. And I'm not really sure how to communicate that decision with everybody, but I guess we'll find out. I don't get involved in the process yet. I'm sorry, so I don't know. OK, cool. Any questions about workflow? All right, moving forward then. Before we get jump into the PRs, is there any topic that you guys thought I forgot to add to the agenda? All right, in that case, let's go ahead and jump in. Klaus, I believe you are first on this one. Yes. So this is about an issue actually a colleague of mine opened a few days ago. He first saw that on the HTTP binding. So there was, it seemed to be a slightly slight contradiction because in the, I think 1.3, it's said that the structured mode should be supported. But then below, I think, in the event format, was then that JSON format must be supported. So if you have a should, on one hand, and a must later on, it seemed to be a bit contradictory. So I just added that implementations that support structured mode must support JSON format. And later on, I discovered that also the other protocol bindings have a very similar wording. So the ones for which it applies that actually have those two different modes. So AMQP Kafka and MQTT, I think that was. So I added those, this changed that too. It is, of course, a bit different for MQTT, for example, as it only makes sense for MQTT5. But I think the way I added it, it's still clear then. And also for Kafka, I think, in the older versions, it was not possible to do a binary mode. So then it's clear that it must be supported. So just to be clear, the must here, we believe it was intended to say that if you're supporting structured mode, then you must support the JSON non-batching. It wasn't to say you must support structured. And that's the clarification the class is trying to make here. Yes. So in content modes, in 1.3 in the section, you see that every compliant implementation should support the structured mode and binary mode. So that's why we did this. That's a good barf fix. Yep. I don't think it changes the intent. So it should be safe. OK. Now, technically, up until yesterday, there was just the HTTP change. But then yesterday, the class class said he noticed the other ones. But he made basically the exact same change, textual change, and all the other ones. The only thing that didn't follow the pattern, this was just a typo, was, as you said, it was MQTT, right? And Kafka, I mean, they don't support structured and binary in all versions. So that's why it's a bit different, but I still think that the proposal also applies there. Right. So even though from the two-day limit thing, technically, he made additional changes. But I think the changes are consistent all the way through. So if people do need more time or want more time, we can feel free to speak up and ask for it. But it seemed like it was a minor change for the time period thing that we talked about. So any questions on this? Any objections to approving? Does anybody want more time to review it? OK. In particular, Clemens, for the MQTT stuff, you're OK with those changes, I assume? I do trust Klaus, yes. That's always good, yes. We all trust Klaus. He knows what he's doing, what he's doing. Yes. OK. All right. Last chance. Any objections to approving? All right. Thank you, everybody. All right. Discovery revamped. So this one was the one I mentioned last week where I went through and did a whole boatload of changes to the Discovery spec. I think making it easier to follow, easier to implement. I'm not going to list all the changes. I think probably, I'm trying to think, what might be some big ones that I made? I think probably the biggest one is if you query by types, the result is actually, let's see if we can easily show that. Where is it? So if you query by type, then you will get a type value as the top level thing. It's just an array. But then underneath there, you get the service definition. Because I believe with the old version of the spec, kind of implied you were forced to do two different queries. First to do a type query to get the list of types and potentially list of services, I think. But then to actually get the metadata about each service, you then had to do a subsequent query. And I thought, that's not very optimal for a user. And it's actually kind of annoying. So I thought, well, let's just make it so that the return value from the service side is the same regardless of whether you're searching by type or by services. It's just in the type case, it has a type on the outside, and then you drop into the service. That way you get the full metadata every single time. If in the future we decide it's just too much data, then I think we can look at adding flags that do things like give me a reduced set kind of thing. But I do think it's important for somebody who knows that they're hitting a consumable chunk of data to come back to get it all in one shot if they really want to. I think that's going to be important and not force everybody into a two query model. I think that's probably one of the bigger changes. The rest of it, for the most part, is I think more cleanup than anything else. Any questions? Is there any piece that people would like me to focus in on? Nothing? Any objection then to approving? Sorry, Doug, can you go back to that example that you had up first? Oh, wait. Do you mean the top of the spec or the type stuff? That there. OK. OK, thanks. Yeah, I didn't have any comments. I just thought I saw some text error, but. OK, no. And obviously, we're going to make lots of changes going forward anyway. This is just the next round. OK. Any objection to approving? Whoops. OK. One of the things I'd like to do at some point is talk about actually putting together code behind these things. So I'm not going to ask for it today, but maybe for next week people can be thinking about whether they would volunteer to put together an implementation of the spec to see if it's actually implementable. And then we could start maybe doing some interop testing or something along those lines just to prove out the spec actually works. I figured that will probably expose lots more bugs keep reading it over and over. So anyway, be thinking about that for next time. Don't want to put anybody on the spot yet. I actually don't think it should be too hard to implement. It should be fairly straightforward. So Clemens, this one is yours. Would you like to bring us at the speed on what happened on this one? I did so many edits. I don't even know. So there have been 108 comments on this. And I think I've addressed all of them. In one way or the other, I think some of the discussions kind of dissolved themselves, resolved themselves. And then there were some comments to with minor wording things, or there are two spaces too many. And so I did those. But I think I caught everything. So I think my proposal would be at this point because this becomes a little unwieldy to manage. If there are no grand objections to the overall tenor of the documents, I would be pleased if we could just go and put that in and then start bug-fixing what needs to be bug-fixed on top of this. But the size of the discussion is now making it a little hard for me to go and address these individual items. I don't know whether I really don't know whether I missed anything. I think I didn't miss anything, but I'm not sure. Well, we have follow-up PRs if necessary. But are there any questions for Clemens or comments? Any objection then to approving this as the first draft? You guys are way too quiet today. All right, keep moving forward. Just agreeable. Yeah, that's it. Agreeable, yes. That's much better than the opposite, I guess. All right, this one was opened relatively recently. But it is just a change to our community slash demos file. And it's just pointing to a demo that this person has around cloud events. It's non-conversal, in my opinion. So I don't think, Clemens, I have to pay too much attention to the two-day rule thing. Any objection to adding a pointer to this other demo? And if, obviously, as a reminder, if you guys have other demos for cloud events that you want to reference in here, feel free to open a PR. Any concerns with adding this? OK, I had to prove them. Thank you. All right. OK, the rest of them, I'm not sure they're actually ready to merge. Does anybody want to go first? Otherwise, I'll just go in order. OK. Klaus, did you want to talk to this one? OK, so first of all, it was dependent on your change to the discovery model. So I will have to change and adjust it a bit. The source template will then be under type, I think. So that would be a change I will have to make. We discussed, I think, two weeks ago if we should constrain it to adjust the level 1 templates they are suggesting. So I could add something, some comment, that it is recommended to use the normative recommended to use just the level 1 templates. Or we could do a hard constraint. I don't know. That is one thing. The other thing is that I think you asked somewhere in this PR if it would make sense to further describe the parameters mentioned in the templates. And I thought about a use case that might make sense. So having such a template could be a nice help for providing more subscription UIs, for example, or tools tailored to a specific event source. So you could then by having a UI displaying input boxes for those parameters that could be then derived from a template like this and below the surface, then a subscription based on these UIs could be generated. And if you want to provide tooling like this, of course, a description of the types of the parameters or a length constraint, things like this would be helpful. But on the other hand, it could complicate things a lot if you do not just edit your I template, but really type descriptions for the parameters and the style JSON schema does. So I'm not sure. Maybe we first discuss just this, and then later on we can discuss if we add more description around it. Let's take this one at a time. So does anybody have any questions about the overall concept of what Klaus is proposing here for a source template, either the entire idea or some aspect of it? OK, not hearing anything. I think the next question you mentioned was, I can't remember the exact word you used. There was different levels or degrees of the syntax. I think they called it levels, yes. Levels, that's the word, levels. Right, so there was at least two different levels. Does anybody have an opinion on restricting it to just level one? Because I think if I remember correctly, level two or other levels allow you to do really fancy substitutions and loops and really cool stuff, like complicated stuff. Anybody have an opinion on that? Is there any need for that right now? Anything for level one? I can so far mostly imagine use cases for level one. But on the other hand, I don't think if it breaks anything, if we allow also the more sophisticated levels. I fully agree with supporting only and only the level one. Because I had our time supporting this back. So really, let's just support level one. OK. Anybody else want to chime in? OK, I'm leaning towards just doing level one as well. Just because of the other stuff, it looked really cool. But it just seems like it's going to be really complicated to ask people to support that. Yes. Yeah, but also it's not really useful. Again, the other levels are cool, but they are not really useful. Yeah. So maybe we should start with just level one and then we can always revisit that decision later if someone comes up with a good use case for why they need more. That's not fair to people. Yeah. Always easier to relax rules later on. Definitely true, yes. OK, so there's two. So I assume you'll make a change to that. OK. And then the third one was the much more advanced feature of actually describing the actual variables. Yeah, so that's something you suggested in one of the comments, I think. Yeah, and I definitely would not want that as part of this PR. We could consider that as an add-on PR. I would want to keep this one small and simple. So we could talk about that one later, in my opinion. Unless someone else wants to say, no, we need it now. OK. Any other points around this PR that people would like to bring up so that Klaus can go back and make his edits? And to be clear, since I didn't get specifically asked, just remind people, the biggest change is he's going to make source template appear under type. So every type could technically have its own source template. All right. Any questions, concerns? Last chance? All right. Cool. You have a direction, Klaus. Excellent, thank you. Slinky, I believe these next two are yours. Do you want to talk about either one of those? Nope. OK, I won't force you then. In that case, Jim was not able to make the call today. He warned me about that. And I promised him I would just remind people to take a look at his Protobuf PR. He is still working through the discussions and comments and stuff there. So if you have anything to add to that conversation, please go ahead and comment in the PR. I believe he's still hoping to come up with a final draft of the PR for next week. So don't wait till the last minute if you have comments or concerns. OK. That's it for the agenda. Are there any other topics people would like to bring up? Wow, I can't believe we went through four PRs in 20 minutes. OK, in that case, let me just do a final roll call and then we'll let everybody go and enjoy the rest of their day. And we can start the SDK call a little early. We used to fight more. Is it again? We used to fight more. Yeah, I'm waiting for that to happen. I got to find a good topic. OK, let's see who did I miss. Rakesh, are you there? Yes, I'm there. Is this your first time on the call? Yes, this is the first time. OK, if you want to be associated with a company, can you just put the company name in the Zoom chat and I'll put it in there? If you don't have to be, if you don't want to. OK, Chen, are you there? Oh, I don't see Chen on the list anymore. OK, so Chen dropped. Hamid, are you there? Yep, I'm here. OK, and this is not your first time, correct? No. I don't think so. All right, did I miss anybody for the attendee list? All right, in that case, non-STK people, you're free to go and enjoy the rest of your day. And we'll start the SDK call in about a minute or so. Thank you, everybody. Thank you. Bye. Yep, bye. Thank you, bye-bye. So wow, oh, thank you, Lance, for adding that topic. So just for you guys to think about what we're waiting for the minute tech, the item I wanted to talk about was, right now we have basically one gigantic maintainers group inside the project. And that was fine when we only had a handful of people. They bounced around between SDKs. It wasn't worth having individual teams per SDK. But now that we're getting a little bit bigger, we should probably start looking to add a little more formality and process to things. So what I was going to do or suggest is that we actually create separate teams per project. And I don't know for sure if I got this list right. So please look at the list to make sure the names are correct in terms of who goes where. In particular, Slinky, I wasn't sure which groups you wanted to be in. So if you want to be added to one, just let me know. I have a question for you, Doug. How did you calculate this list? So I went through the list of people that are in the maintainers group, and then I tried my best to look at who did commits on each project. And if you had more than two commits, I thought, OK, they're busy enough they should be a maintainer. But to be honest, I'll edit this however you want. This was just my initial guess. So first, for Go, Alan is not working anymore on that. I mean, he completely changed the job. So I think we don't need it. And Java, I don't know who is Dustin Ingram, honestly. He's a relatively new person, but I think he's actually going to focus more on Python. I think the only reason I put him here was just because I didn't get it. Yeah, yes, yeah, yes. Yeah, yeah. And yeah, Matthias is not working anymore on each LSDK, too. OK. Do you want me to keep Dustin? Well, Dustin is going to contribute because I never saw any contributions for him, I think. Yeah, maybe. I put him there because I thought I did, but maybe I'm wrong. I can remove him. And if he will complain, I can add him back. That's not a big deal. I don't see any contributions for him. OK, maybe I'm just wrong then. OK. OK. In the Rust, so the Rust story is funny because when we started, I started with Lazeretti and the other guy is named Linus, Linus Basig. And we decided to gather all the design decisions. We did some meetings for that. But I ended up writing all the code. So I mean, I asked them to join, participate, write code. But they never contributed with code. They just did a review. So I don't know, how should we end on that? I don't feel comfortable being the only one, honestly. But it's up to you. I'm going to listen to you. Well, actually, let's back up before we continue editing the list. Do people agree with creating separate teams, first of all? Any objections to that? OK. OK, good. OK. So now let's go back to the list. Honestly, it's up to you whether I keep them there or not. We can always re-add people later if they object. It's up to you guys who you want on what list. Well, I would say let's keep them together with Linus. No, Linus didn't even made any comment now. Because maybe I can manage to get them involved again. So you want to put Linus back up here? Yeah. I wish to involve them back again. OK. OK. Anybody else want to edit the list? Sergey, you're asking about Fabio. I know he's busy on other things. I personally would like to keep him just because he did so much work in the past. And I know he's off doing other things. And so I wouldn't want to drop him yet. But I think he'd be a candidate for dropping in the future. I think we should not remove the historical contributors so easily. Yeah. Because it's not fair for them. Even if they are not contributing anymore, it's not fair. OK. Any other changes people want to make? Lance for JavaScript, you're OK? Yeah, that looks good. In fact, I think we already have a subgroup or a GitHub team for that. Yeah, you do. I'm not quite sure how or when we created that. But yeah, I did notice that last night. Yeah. OK. Clemens, I assume C-Sharp looks good since you just recently added John. Yes, John has come and has a lot of ideas. And I'm not going to stop him. Yeah, we've talked through a number of changes that we both agree are necessary, in which I have not found the time to. But John is full of energy. And that's great. And so, yeah, we're going to do that together. OK. OK, any other changes people want to make? OK. And to be clear, these folks will be dropped. Any anybody has seen any problems or concern with those? All right. The other thing as I was going through this last night was we should probably then talk about how we add new maintainers. My first guess was to say at least 50% or more than 50% of the existing maintainers should vote to either add or remove somebody just to have it consistent across all the repos. But it's up to you guys in terms of what kind of process you'd like. Actually, let me back up. Do you want to define a shared process across all repos? Slinky, you're up. Yeah, so I think we should have it, definitely. OK. But I propose to add also a contribution bar. Contribution minimum bar, at least XPRs. I don't know the number now for sure, but I think it's important to say, let's add. I don't have the number. But I think we should put a bar in terms of how much PRs. And if it happens again, situations like unmountained SDK where somebody wanted to contribute, but there wasn't an opportunity to do that, because maybe somebody, because the SDK was unmountained, then we need to have another rule for that situation. I don't know, but my first guess is that we need at least XPRs. OK. Sir Jay, your hands up. Yeah, I just wanted to share some thoughts, because like 50% of existing maintainers can be tricky when you only have one maintainer, which means like it's either 0%, 100% agreement, which is very easy to make, I believe, but a bit hard to accept. And for at least XPRs, it may also not be the best metric, because it also depends on the current maintainer and the willingness to contribute, because sometimes there is a huge wheel or a big wheel to contribute. But unless some agreement is reached with the maintainer, it may not be something that people would want to do. And just submitting random PRs to get the maintainer status would also be weird, although it would improve the project. Yeah, the people playing games, doing typotype PRs just to get that number up would not be good. We've all seen that before. So you mentioned concerns with those two things. Do you have any recommendations on what kind of criteria you would like to see added? Perhaps identifying the companies, maybe, because usually we talk about the companies. I mean, there are individual contributors as well, which is great, but sometimes there are companies that wants to use some of the SDKs, and they may also have a desire to contribute. So focusing on the end users as big groups of users and their representatives may also be an option. I mean, obviously, I'm considering some of the cases we had in the past, but at least when we are talking about an SDK, official SDK, for cloud events, which is a community-driven project from the foundation, I would expect it to be more foundation-driven, where foundation is a group of companies rather than individuals and maintainers. I have a comment there. But Clemens, did you want to say something since you came off mute? Yeah, I think there's a company element to this, where looking around the general space without this being a problem here, I think one of the limits I would want to put on this is or would be great to have on this is a reasonable bar that should be in the governance rules that a single company can't have more than x% of the maintainers, whereby x% certainly must be under 50%. And I think a third would be, if it's more than a third, I would question the health of the project. Anybody else want to comment? Well, I mean, I can say right now that the JavaScript SDK has 2 thirds of the maintainers coming from Red Hat. But I would say that that doesn't necessarily, it's not a detriment to the health of the project. In fact, the project is actually getting a lot more attention than it had. Yeah. So I think this is why I don't think on the individual SDK, it's like if we say for the SDKs, we're basically going to make that a pool thing that works better. But it's so my concern is that when you put governance rules like this in place and you allow effectively a quorum of folks to decide who gets into the project or not, then once a company has amassed enough committers to have a majority to control who gets in or gets not in, then the project has a fairly easy way to deteriorate into a marketing effort of a particular company where they could still put up the sign on the outside to say we are open source and we're running in the foundation. But in fact, all the decisions are being made at corporate headquarters. And that's something that I observe in several places in the eventing and messaging space and analytics space. And if we can prevent that early, that would be great. OK. Sergei, your hands up. I just want to say that on one hand, I think it's exciting to see a company's commitment to the cloud events, be it Red Heart, Google, or any other company. But I think Clements made a good point about if I may, I'd like to call it a diversity of thinking. Because when the majority of SDKs are maintained by the same company, you may have a problem of being very biased towards this company's needs. And I think Red Heart is doing a great job right now and is listening to other companies. But it's a bit disturbing to see that more than half of SDKs are being maintained by Red Heart at the moment, or at least being actively developed by Red Heart. So it's interesting. Let me pick on you, Clements, for a second. So the max per company thing, it wasn't clear to me whether you're talking about a max per company on a per SDK level or overall across all SDKs. Because overall, we can't. Yeah, OK. Overall, I think what I want to avoid is if we're having a governance rule that says you are in or you are out and we're doing this as a maintainer, like who do we give commit rights? And we should have a governance mechanism that prevents a single company from being able to effectively control that. Yeah, but you're talking at the global level, not just one SDK. Yeah, I'm thinking of, yes, the global level. Because we all, I mean, we need to go at all pool resources. And there is probably, there will be companies which are really, really interested in doing something in whatever Haskell. And that might be a bit of a niche opinion. And so that's certainly something where just one person or two people from the same team might be doing this. So instituting that rule there doesn't really make any sense. But if we admit folks kind of at a steering committee level with everybody who's a committer having a vote, then we should figure out a mechanism for how we can go and prevent that a single company can go and take that over. Yeah, that's what I was about to ask you about. Because it sounds like you're headed down the path of adding a layer. Because we kind of have a layer right now, but it's a very, very informal layer, which is who shows up to this call, right? Well, you started with the voting thing. So I'm just reacting to that. Yeah, I know. I'm sorry. No, no, no, it's all good. I'm thinking I don't think we're going to be able to decide this today because this is a big freaking decision we need to everybody's input on. But I'm trying to figure out, so there are two things right in my head. One is at a governance across the SDK level, seeking just for myself, I would personally prefer to avoid anything too formal yet, because I haven't found a need to introduce anything yet. I think a formal structure within an SDK of having well-defined maintainers, which we already do have, sort of, and now would be a little more formalized with this list above, I think that's definitely needed because you need to be able to resolve disputes at an SDK level. So I think that's definitely needed. It's just when we start talking about company representation within a particular SDK, the max per company, that one scares the bejeebers out of me, because I don't necessarily think, for example, the C-Sharp one has anything wrong with it right now, even though you guys are both Microsoft, right? Sergei, the thing you were talking about of getting representation from companies who want to participate and from end users, while I agree, I want their input, I'm not sure that anybody should necessarily get to maintainership status without putting in the work, right? Just because company X says, hey, we want to join forces, and we got 10 people who want to join, that's great, but they have to do the PRs and do the work before each individual person would become a maintainer. At least that's my thought process there. And I see a cube piling up, so let me pause on that. That was just my current thought process on this. Sergei, your hands up first. So first of all, absolutely agree that without commitment, making someone a maintainer would be simply a mistake, even if he's loud or anything, so I agree here. Maybe PRs is not the best metric, maybe commitment can also be counted by issues reported and discussed and other PRs reviewed and other open source activities that are not measured by PRs. It's just one thing I wanted to avoid, just measuring the PRs and lines of code, basically. Got it. OK, Slinky? Oh, OK. No, I just want to say that I completely agree with you, Doug, that if you want to put some metrics about companies, that's the point, but if we don't see commitment, I personally will never love to accept somebody as a maintainer if he hasn't did some work. And review is a thing. I agree with the fact that we should also count review, but at some point, somebody must write code. I mean, I'm not the kind of people that likes somebody to being a maintainer without at least writing code. So I think it's important. OK. Sergey, your hands up again. Yeah, just maybe a quick one. So on the other hand, if you want to count the code, we should also make sure that PRs should be processed in order submitted, because we have seen it in the Java SDK when PR was submitted, but then rejected by the maintainer and recreated the way he sees it. And it kind of stops external contributors from submitting code, because the maintainer disagrees. So maybe more work on the review could help here. OK, that's a slightly different topic, right? That gets into sort of PR processing process. And let's hold off on that one for a different time. That's a different topic. Yeah, not saying it's not worthy of discussion. I'd just like to focus more on gathering ideas for the rules to become maintainers. OK, any other sort of things you guys want to add to the list of considerations? Is there some sort of a defined process from the Cloud Native Community Foundation that we can inherit? I mean, the bureaucracy wouldn't be something good to have, but at least maybe. I mean, I'm pretty sure there are some other projects that we're thinking about the same thing. So maybe you can get some inspiration from them as we are inside the foundation, not just a project. I'd have to double check. Offhand, I don't think there's anything at the CNCF level itself. There may be other projects within the CNCF that have good ideas that we could steal from. But I'm not sure I've seen anything at the CNCF level. But I'll double check and see. Maybe I'm just forgetting. OK, so I think, yeah, go ahead. If it can help in another community, I participate in the Canadian community. What we do to accept, so we have two levels. The first is, what's the name? Reviewer, something like that. I think it's a reviewer and the maintainer or something like that, yeah. Reviewer and approver. So of course, it's a bigger project. So it's more different. But what you need to do to become an approver is that you need a number or review of PRs, not outward by you. And then you need a number of PRs done. Yeah, that's correct. He's cut there? No. Anyway, if I were to clarify, that's how it works. So she's like, I can't type today. I'm not saying it's the best process, but that could be an idea. Yeah, OK. OK, would anybody like to volunteer to actually take all these good ideas that people have said and actually write up a more formal process or proposal, I should say, for a process? No one wants to do a process that I'm shocked. OK, I could try, but or maybe with some like with a little bit of your help and maybe pointers to people who I can ask, maybe there are some other examples in the foundation or something. So I'll do the research and I'll try to come up with a proposal would be wonderful. Thank you. What's the process for defining the process? Would that be a PR or something like that that we could all contribute to or comment on? Actually, I was kind of wondering whether we need a sort of a global repo that spans all SDKs. And we point to that for things related to governance or whether we just say, well, we finally agreed on what the text would look like. We then just do a PR inside each repo. Can you suggest the spec repo? I mean, now use the spec repo for the SDK requirements. That is true. Which, by the way, needs to be updated as a document. The requirements do kind of like there is also there was also some stuff not very long ago about some guidance on how to land PRs and things like that. All of that stuff might be useful in a single repository because it's not clear where to go look for that stuff. Yeah. Well, we already added some of them to the repositories. Yeah, some repos do have their own, yes. I guess the question is, when it comes to process like that, do we want a single? Because for example, Lance, picking on your repo for a sec, you guys to find a process or at least a set of recommendations for even things like tagging of issues in the name or something like that. Is it a feature versus a bug request, or a chore, or that kind of stuff? I can't really detect terms you guys use. Is that something that people would want to try to standardize across all SDKs? Or are people going to say, and that may be fine for Lance's repo, but Clemens, you don't want that kind of process. What do you guys think? Do you want commonality or not? Well, I'll say in particular for the JavaScript repository, that process that basically is have your commits prefixed with basically a subsection of what the repository is, like you said, bug fix or feature or whatever. That feeds into a tool that does things like generates change logs, creates the release tag, and stuff like that, so that none of that has to be done by hand. That's definitely a node-specific kind of tool. There may be other tools like that with other languages, but I'm not aware of them. OK, Clemens, were you going to say something about it so I come off mute? No. Well, I'm going to pick on you anyway. Do you want commonality between, say, the C-Sharp and the other repos, or do you not really care? I have no strong opinion. OK. Well, Lance, in terms of trying to have commonality or trying to have commonality of process across them, would you like to, I was going to say, submit a pull request, but let me back up. Do people want a single SDK repo to hold cross SDK things, or do you want to just create a folder inside the main spec repo? To do what? To do the governance? Just to put any documentation that might span the SDKs. Like, for example, as you said, the SDK requirement stock is in the spec repo today. Should it continue to live in that repo, or should we create a special repo just for SDK common things? For me, we should give the spec repo. I think we are really using the spec repo for things like governance. So I just sent a link to the file. It describes more generic governance of the project, but we can also be more specific. And maybe it can be added to this document, actually, how we select new maintainers, for example. Yeah, because that governance stock definitely is about the cloud event spec work itself and the other specs. It's not methodistic to cover the SDKs. OK, so to say what, I'm not hearing all bunch of people speak up saying we need a brand new repo just for common governance or all the types of documentation for the SDKs. So why don't we look at using the spec repo now? So Lance, do you want to formally propose common process? And if so, I would recommend a PR against the main repo then, but it's up to you whether you want to actually formally propose, what did you say? A common process across all SDKs in terms of how to manage PRs, issues, and stuff like that. Kind of like what you did for the JavaScript one. Sure, I can do that. And add that and submit a PR to the spec repo for that? Yeah, I still think we should probably create an SDK directory there to put all these things into, because otherwise the top level is already too big in my opinion. So I think we should have an SDK directory to put all this stuff into. And I could work on doing that. But yeah, PR to the main repo, be good. OK, sure. Cool, OK. So to say you work on that, Lance, PR for propose common process, SDK, start in spec repo, OK. Anything else relative to governance? So I will do this. I will create the separate teams. So we're able to create a PR as a proposed process for how to add maintainers. Lance, do that. I'll do that. OK, anything else about governance or anything from that space until we jump over to Lance's topic here? OK, moving on, Lance. No. I have that AI and I have not done squat with it, and I apologize. Does someone else want to take a stab at it? I think I can do it. You want to take a stab at that? That'd be wonderful. I just haven't had a chance at it. I apologize. Lance, is that sufficient or what are you doing? I'm sorry, go ahead, Slinky. What should I do in particular? Like do some document explaining? I think we're looking for is just a, in this particular case now, it would be a PR to the spec repo, explaining when or what kind of review process would happen on an SDK to determine whether it's still active, whether it should be archived. And that's about it, I think. I'm not sure what we meant by quality of service in SLA, except for just determining when it's dead. Yeah, I think I was one of the people saying that with SLA, I meant the fact that somebody, even if it's a maintainer there, we should do security patches and so on. Yeah. I think that's the reason why we wrote that. Anyway, yeah. Okay, obviously I think if we actually create a separate governance doc that talks about things like how to add maintainers and stuff, I think that proposal fits very nicely in that same governance doc, so we can look at merging it later. But for right now, create a separate PR with a separate doc and we can worry about the shape later. What comes to my mind is that we should ask somehow like a group of people across SDK maintainers, which is, for example, able to do, we should do security patches when something is not a maintainer and so on. I mean, some kind of, some kind of TLC? How do I say that? I'm not good with names, but you get what I mean. That gets into adding a layer, right? Yeah, but well, that's what we said before, right? Well, we said maybe, we hadn't decided yet. I mean, honestly, again, just my opinion. This is not me as chair of anything or co-chair of anything. This is just my opinion. Personally, I would prefer to make it so that if there is a cross SDK decision that needs to be made and we actually have to come down to a formal vote as opposed to just people just don't come to consensus. But if you actually require a formal vote, I would prefer if it was the maintainers of each SDK are the ones who get the vote. And that's it. I wouldn't want to say introduce another layer. Can you repeat, please? Set again? Can you repeat what you said, please? If we require a formal vote on something that crossed SDKs, I would want the people who are allowed to vote to be the SDK maintainers themselves. So, for example, this list up here would be the people. This, in essence, become the TOC, right? Every maintainer from every SDK becomes a member of the TOC, even though I wouldn't want to call it TOC. OK. That's my initial thought just to keep it simple. The only downside to that is, of course, is if one company has a boatload of maintainers and one particular SDK, they can overrule other people. But I'm not sure how you can ever avoid that without getting into really complicated rules like a number of maximum of people per company. And I'd just like to avoid that. Well, if you want to solve that, you need to do something like that to see. Yeah, I know. You need to add a level. Yeah, I don't want to. Unless people think we actually have a need for it, I'd rather really avoid it. Because we haven't needed one up till now. Well, but the discussion that Sergei did, I think, went in this direction somehow. I mean, another thing that comes to my mind is, for example, let's assume we have one of the SDKs, which we don't want to archive, because there is no need, because it works. It's updated. But the maintainer is not alive. What should we do? I'm not prone to archive an elaborate that just works only because the maintainer is not alive. So I expect that somebody from the larger group, even if it has a little knowledge of the language, could take a little bit time just to do security patches, stuff like that. Do you get what I mean? Yeah. It's at some point, I mean, this is open source. So at some point, somebody is up here. And I expect that somebody, there is a process to say, OK, the person X should be the one that does security patches, even if it has a little knowledge of the language. Yeah, and I think some of the stuff that you're talking about there, I would hope would appear in this document that you're going to write up a proposal for. Because I agree with you. Just because no one is active on an SDK doesn't necessarily mean we should archive it, because people are using it. And we don't want it to go away. And at that point, if something needs to change in that SDK, I think that's why we have these regular phone calls. Someone can identify the issue. Something needs to happen, and we just need to get a volunteer to make it happen, even if they're not a maintainer of that particular SDK. I don't think we need to, I mean, you could talk about that in your proposal if you want, but I don't think we necessarily have to spend too much time on it. I think that will kind of fix itself. I'm hoping anyway. Does that make any sense? Well, I hope so. OK. Well, let me try to write down the proposal. Yeah. We don't need to solve everything right now. Yeah, I mean, my guess is that we are going at some point to having this another layer. That's just what I wanted to say. OK, yeah, maybe we will. Yeah, that's fine. OK. Any other topics you guys want to bring up? I haven't really given a lot of thought to this yet, but the fact that we keep saying SDK over and over again and all the repos are named SDK, there was a proposal in the JavaScript repo to change the name to not have that acronym in there SDK, because SDK actually implies something bigger and broader and stuff like that. Is there governance or guidance or anything on if names change and what they should be changed, whether or not, I don't know what I'm trying to get at. I'm curious about this. I know of no rules either from the CNCF or within this group that we've discussed at that level. I think if we wanted to make that kind of name change, it's just something we as a group would decide on our own, whether it's a good or a bad. And what we change it to would be up to us to decide. I think that'd be a pretty massive discussion, though, because people probably reference our repos already. Yeah, I totally agree. And modules and stuff like that. Right. Yeah. I mean, I think Grand is the one to brought it up, right? So I think it's an interesting discussion. It's up to you guys and what you want to do with that and put that discussion, though. Well, for us, what I did is that I took the only name available. Yep. OK. Any other topics? All right. In that case, we are done. Thank you, everybody, for the discussion. And we will talk again next week. Thank you for your continued leadership. Yeah, yeah, yeah. All right. Thanks, everybody. Thank you for your rest of your day. OK, bye.