 Welcome, everybody. This lunchtime session is so that Lan and I can help you get your stuff together in order to submit a talk to scale. We are very, very interested in new presenters. It's always been a big part of the conference. And we know that it can be hard to get started. So this is to help you along a little bit. I'm Josh Berkus. I'm on the Scale Program Committee. Specifically, I work on the Cloud Native Track and KCD Los Angeles and help out with the new data on Kubernetes Track. Hi, and I'm Lending. I'm a longtime volunteer with scale in various capacities, including on the AV team where we do the streaming of the talks, which we'll get about into later. And recently, I joined the program committee so that I could advocate for the talks that I want to see at scale. There's a link both in the chat and on top that you can just bring up the slides on your own screen. So we'll just have a short about 15 minutes with some general advice on how to develop a talk concept and write a proposal. And then we're going to go into Q&A, where we're available to answer your individual questions and also help people with advancing their talk concept or proposal or other things. When we get to the Q&A portion, each person who's speaking should let us know whether or not they're OK with being in the recording. It is actually helpful for other speakers who couldn't join us for the session to see us helping other speakers to get an idea of because people were presenting for the first time, didn't have a lot of the same problems. But mostly we're here. We're here to get all of you to submit proposals for the conference because we need new speakers. We want more proposals. There are new areas of technology that are open source, and we need proposals for people to work in those areas. And scale is actually one of the friendlier, easier conferences to submit a proposal to. So you're in a good place. Right. So if you're not familiar with scale, this is short for the Southern California Linux Expo. It's one of the largest volunteer run free and open source community conferences. So it's volunteers who are running it, who meet on our own time. And we shape the conference to what we want to see there. I've been a part of scale for a very long time. This is over 20 years. And I feel like I've been there for a good 15 years. So our audience is people of all skill levels, background, and interests. I feel a lot of the people who attend scale are attending it to see the same people year after year and to catch up with them. And so things that you can expect. We definitely have tech talks. We have workshops. We have things that people, other companies, wide them out to go and attend scale. But we also have community talks. We have how to use things, how to build an open source community. We have beginner Linux training. We have strong interests in cybersecurity. So there's a CTF. We have game night. So it's a community conference. And we are looking to learn from each other. Most of our talks are live streamed and recorded. This is something that volunteers developed over a long period of time. And so we've been doing this since scale 11x. And now we're on 23x. So we're getting a better hang of doing the whole live streaming to YouTube. And you'll actually find a number of our talks from past years on YouTube. The link to that is in the end of the slide deck. Before you write your proposal, you should have in your head an idea of what talk you want to present. You don't have to have the slides or the full outline or anything like that. But you should have a pretty clear idea of what you want to say. And then you're writing your proposal as a summary of what it is you want to share on stage. So we'll go through a very brief version of how to figure out what you want to present and how. One of the first and most important things about giving a talk is that you're giving a talk to someone. You're not just particularly, we're talking about a live conference here, right? So you're not just giving a talk for the video or whatever. You are giving a talk to a specific group of people. And you probably have in your mind, even if you haven't really thought it out, a group of people that you want to talk to. And figuring that out is kind of the first step in figuring out what your talk is going to be. Like, is this a talk for application developers? Is it a talk for system administrators? Is it a talk for open source project owners? Is it a talk for people who want to make their first contribution? And so give some thought to, who is it that you want to be in the audience? Who is it you want to talk to in the audience? Why are these people at scale? And what is it that they need to know or to do that you're going to address? So as I've mentioned before, we have all sorts of folks in the scale audience. You have the folks whose companies fly them out to attend the conference to learn more about technology and what's happening in the fields. You have people who are just starting out in their careers. You have people who are students who heard about this open source thing. You have people who think open source is a good idea. You have scientists who use all sorts of open source technologies in their work. And maybe they want to learn how to use R or Julia or Python better. And you have a lot of cybersecurity experts, people who are network engineers, all sorts of people who see scale as a place where they can learn a bunch of cool things. And one of the things we want to highlight is we welcome beginner talks. That's actually how you make certain areas of your open source or technology more approachable to people who are just starting out, don't know anything about it, but are eager to learn. I actually did a little survey on Mentimeter just looking at the abstracts and titles of the past few years of scale talks. And so you can kind of see the variety here of topics, technologies, and things. So if you thought that you had to give a super technical talk that's not really necessarily a case, what you have to do is think about the audience and scale and what would cause them to pick your talk over a number of other talks that are happening at exactly the same time. Yeah, so every thought of the audience, you have to think about what's my goal in being up on stage and giving a talk, right? Do you have an open source project that you want to promote and introduce people to? Are you trying to share a solution to a common problem? Are you trying to start a discussion around a common problem that doesn't have a solution? Do you want to teach a bunch of people how to use some technology that you're really enthusiastic about? Maybe you're even just sharing a status update on something that a lot of people use. And part of the thing about this goal should be thinking about what is the audience going to get out of that, right? You're thinking about what am I getting out of this and what is the audience getting out of this, right? Because in a good talk, everybody is getting something out of that. With that framework and having sort of thought about stuff, you're ready to sort of narrow in on what your topic or topics for your proposal, because you can make multiple proposals. And if you really, really want to speak at scale, I recommend actually making more than one proposal. You know, what it would be. And like, generally, you want the topic unless you are a professional presenter, like if you're a DevRel or something, right? Unless you're a professional presenter, this topic should be something that means something to you personally or that involves you personally. So it could be a technology you're an expert in, but it could also be something you just learned. Like, the best time to write a beginner talk is right after you personally graduated to the intermediate level and something. Because that's right when you remember all of the things that were hard as a beginner. You know, maybe you overcame a problem and you think that your solution for the problem is going to be interesting for other people to replicate. Maybe there's a controversial topic that's in an area where you have expertise and you want to bring some kind of clarity to that. So how long is a talk? Normally our scale talks are given in one hour time slot and generally you spend about 35, 45 minutes on the presentation with 10 to 15 minutes Q&A. Again, sometimes they'll ask you questions during your talk and it's really based off of how you want to run your talk. But be prepared to go in depth, give examples, engage your audience and solicit the feedback from the audience. Don't just speak at them, hear from them. Like part of the beauty of being at an open source conference is what you learn from each other. So I've done a much longer speaker training, including at scale before. And one of the things that we go through in helping people refine their topics is exercise we call one sense. And the basic idea here is if you can't express your topic at a very high level in a single sentence, it's probably because you're not sure what it is yet. And refining that topic to one sentence helps you a lot in refining the topic for your proposal and your eventual talk. So three very common sort of sentence structures that you have for this topic summary are some topic is cool, easy, fun, hard, terrible, right? Or very common for technical talks, how to do something by using something else, right? Very common sort of summary topic. Or sometimes you're there to advocate for something and you wanna say contribute to or adopt or avoid or stamp out something. So here's a few examples that are actually summaries of talks that I've seen. One is rust is more secure. It's the more secure programming language, right? That is a talk topic right there. And then you can imagine everything that would go into that talk. Or a summary of pretty much all of the speaker trainings and stuff that I've done, how to present better by using good talk preparation. Or another one I've seen in other conference like contribute to Python as a non-coder, right? Opportunities to contribute in areas that are not writing Python or C code. So once you have come up with that sort of general topic, then what you wanna do is say, what is the story I can tell around this topic? Because what people enjoy seeing what will keep them in their seats during your presentation is a story. Not just a, you know, here's some code, but something about that code. Why is it important? How did you start using it? How long you've been using it for? There actually are sort of six canonical stories that people tell during sessions at technology conferences or hybrids of more than one of these. Some examples of, common examples of these end to end is pretty common. And that's actually what we're doing here, right? Where we are going through the process of developing your talk concept from beginning to end. You know, but you can get more creative. Show and tell is one that I like to see and I haven't seen nearly enough where you show off something cool and then you spend the rest of the talk explaining how it worked. And by structuring things as a story, it's more engaging for the program committee who is voting on your talk and it is more engaging for the audience who is watching your talk. But the important thing is that this story should be a story that means something to you. A good example that we had, Gwyn did a talk a couple of years ago, scale 17X, where she had a pull request for Kubernetes that took over a year to merge and she told the story of that PR, not merging for a year. And it was an excellent, really fun talk. So think about what stories you can tell including stories about your experiences. So let's talk about how you submit a proposal because it's actually pretty straightforward in scale. The most important thing about your proposal is the title and the abstract. We're looking at lots of proposals. It's a whole committee looking at various proposals and saying, wanna see this at scale. This seems like really cool and we advocate for it. We vote for it. We try to convince the other people on the committee, hey, we should really select this talk. So in order for us to be able to do that, we need to first of all, look at the title and abstract and understand what the talk is about. And some of it is also, it's a talk in the right category. We tend to select talks within our categories of expertise. And so unless the talk is in our category, we might not even see the talk. And so if you can be very clear, both from your title and abstract what the talk is about, who are you aiming for? Is it a beginner audience, is it an expert audience? Like who are the people who is your chosen audience? Why should they be coming to the talk? That all helps us figure out which track you belong in and put you in front of the committee members who are putting together that track and trying to line up a track that has a really good coverage and maybe like common themes and things like that. Something that you should probably expect, but most people are surprised by is, whatever you enter into the submission for proposals, that's literally what goes on our website. There's nobody that does data entry for you afterwards and puts things, literally everything you enter into the call for presentations ends up on our website and in the printed program. So your speaker bio, your speaker headshot, whatever the abstract is, we even asked you to maybe upload your presentation if you already have it or upload it at some other point. Once you sign up for an account on our website and you submit to the call for presentations, you can revise it at any time. I would say that if you keep revising it after the deadline, then we probably won't have seen the revisions, we will have seen whatever it was at the time that we were evaluating the talks and selecting them, but if we select your talk and you go onwards, I would highly advise to keep revising it so that this is what your audience is gonna see when they decide whether to attend your talk or not. Back to you, Josh. So I have here a little sample, a proposal that gives you an example of what should be in a good proposal. The, about bananas. This is actually something one of my coworkers came up with for another volunteer run open source conference called DevConf. So this is, and the thing is this has sort of all of the parts. Now, one is to point out that it's actually a sort of reasonable length, this is three short paragraphs which is enough to get the point of the talk across without making anybody stop reading it. You can bring in other people, you can talk about people's experiences, like I said, one of the things is to tell your story or your client's story or a co-worker's story, right? Because people wanna hear stories then we hear stories about people. So bring that in and make sure that the abstract and the title both get across the same message, right? So here it is, is it's things that you can do to improve your yield of banana crops. And then this is, hey, we're going to show you our experience with improving the yield of banana crops. There are some other sort of basics, like Land talked about, make sure that it's very clear up front, often in the first sentence, what the talk is generally about, both for the sake of the program committee and for the sake of the audience. Because when people are trying to categorize things in the head, when they're trying to decide what room to go to in the next five minutes, they don't necessarily read any further than the first two lines. The, spell out any acronyms or explain buzzwords. The, and then have an outcome. Say what you expect your audience to get out of the talk because then that lets people self-select and decide whether or not the talk is for them. So when you want to submit your proposal, it is on our website, the links are at the end of the slide deck. You would be on this call for presenters page and we very, we put the information that you need at the very top page. There is a CFP tool login. If you have presented a scale before, you probably still have an account. We set the password. If you haven't presented a scale before, then you would sign up for an account and then keep track of that account. Because as we said, after you submit the proposal, you can still come back and revise it and revise it and hone in on it. So I would highly encourage, if you think you can give a talk, just start. Put it into the system, revise it. If we happen to be looking, we might say that looks like a cool talk, but I probably want to contact them and find out a little bit more and see if we can get the abstract tightened up. Those are things that we have more of a luxury to do before the call for paper ends. The moment that the call for presenters call for papers ends, then we're all very busy trying to select talks for the conference itself. So get your proposals in early so that we have more of a chance to see it and really think about it instead of at the last minute. The other thing is that we have a section that says, send a message to the reviewers. If you really want our input, you really want to call something to our attention, please fill in that field and then we'll keep an eye out for any of the proposals that have a message to the reviewer and see if we need to respond to it in a timely manner. So one of the things you will notice is that there are a whole bunch of different tracks available for submitting your talk into. Do try to pick the right track that seems appropriate for your talk, but don't spend a lot of time stressing about it simply because among other things we do a fair amount of talk swapping between tracks because there is overlap in topic areas between a lot of the tracks. And so if something really belongs in a different track, the program committee will move it to that track. So just pick something that's appropriate, but don't worry that much that you pick the perfect track for it. And this is pretty much the end of the presentation. Here are the links, the link to this PowerPoint, the link to the call for presentations. If you want to look at past talks, we have a YouTube channel. I advise that you look in the playlist section for each scale conference. We try to have like one master playlist for it. Was that your presentation, Josh? That usually too? That's actually a GitHub, that's actually a GitHub project that has links to like a couple hundred different resources on public speaking and writing talk proposals and developing your talk concept and even maintaining your own personal speaker page. So it's a great, it is a resource of resources. Great. You wanna talk about that Slack? Yeah. So we don't actually have a general chat channel for scale speakers, but we have three related tracks, cloud native, KCD Los Angeles and date on Kubernetes. And we do have a Slack channel there on the cloud native computing foundation Slack if you wanna pop in there and ask questions and ask for feedback. Aside from that email is great. If you email CFP at SoCalLinuxExpo.org, we will see that message one way or another. Casey is very on top of that. And then the final slide is an invitation to you guys. What questions do you have? What can we help you with? What was posted was about submitting multiple proposals and different versions of the same topic versus entirely separate topics. And I would say yes to both actually. You can do different topics and you can also do different versions of the same topic as long as they're different. Like for example, if I was doing the introduction to Kubernetes, I could submit that both as a one hour session and as a workshop. I can say, hey, I've got this content. I could do either the short form or the long form and so I'm gonna submit both. The, or if you happen to work in AI and the cloud, you can submit one talk about your technology that's kind of a deep dive on the ML algorithms you use and a second one that's more about, oh, how do we deploy the scalably? And by doing those variations, you actually make it easier for us folks on the program committee because one of the things we're trying to do is create a balanced program. And so we're looking at what audiences are being addressed by the talk and which things are beginner oriented and which things are advanced, et cetera to create a balanced program. And so if you have the time and the expertise by giving us multiple options, you may get easier for us to fit your talking to the schedule. Probably also pointing out as workshops. So you can submit an idea for a workshop through the CFP process. You should call out explicitly in the description that you plan this as a workshop. Workshops are typically two to three hours and we'll have a different room set up. So not a presentation, but tables where people can work, a classroom set up and typically have more prerequisites what people need to come prepared with, stuff like that and we'll probably reach out to you individually if you propose that. But that is something you can propose. Yeah, and both to answer a question that we have in chat here from Christina, as well as that is. I mean, my first bit of advice is if you've never done a public presentation before, don't start with a workshop. The preparation, like not only is it two to three times as long, it probably requires 10 times as much preparation. The, and we do, and to answer the question is we do recommend having multiple people for a workshop because generally the workshop, you're gonna end up wanting at least two, right? In terms of like one person who's doing the slides or demos or whatever, and a second person who is helping the attendees with their individual problems. We've had crews of up to five people for doing an individual workshop because like the intro to Kubernetes workshop, generally had over a hundred students. And so we needed a lot of people out there helping individual students with their individual laptops. I don't know that we've ever set a limit on it before, right? If you have some reason why you need 20 facilitators in your workshop, then email us and we'll consider that in a case-by-case basis. It's not out of the question. You might have a very good reason for it. Thank you, that was helpful. No, I usually, I'm with AWS and we usually have about four or five facilitators, sometimes like six the most at the workshop depending on the workshop, that's why I was asking. Yeah. Multiple people at my company, we work on specific technology set, I work at LinBit, but we're going to, multiple people are going to be submitting talks and we're wondering because a pretty common one would be just how to use the technology set and configure it and combinations related to that. If we submitted the same talk, but multiple people at the company, would that hurt both of our chances or all of our chances of getting the talk selected or how would you recommend doing that if we all, we do all have individual ones that we want to submit as well, but as far as making sure that there's a widespread because it's multiple people that we'll be submitting. I mean, if it's a topic that we want, right, that we decide that we want for program balance and everything else, somebody is going to get selected. And then it's really up to your team to decide if you want to strategize on that by working together to submit the best possible presentation with the person who really wants to do the intro talk or whether you want to submit independently and have the program committee sorted out. The only thing I would say there is kind of a limitation is one of the things we do look at in terms of program balance is people's employers. As in, we don't want to have a case where, for example, you go to one of the days of DevOps LA and the first four hours are all people who work for the same employer, right? We're not going to do that. And so, you know, so effectively like say if the LinnBit team is submitting stuff, there's going to be a limit on how many talks by people from LinnBit that get accepted because we do check that. The, you know, and if you're looking for, you know, if you're looking to tailor this, it would help you to submit in different tracks, right? Because what we're concerned about is that the audience needs to have the experience of hearing from a diverse set of speakers. The, so, yeah, so, you know, just really decide. And the other thing to also decide is whether or not it makes sense to whether it makes sense for like two members of your team to team up rather than submitting, competing things. The, we won't actually do that as a rule. As a rule, we will not reach out to speakers saying, hey, did you want to combine this? It has happened, but it's not usually how we approach things. Casey? Yeah, I was going to add, if they're literally the same presentation, I would discourage you from having more than one person submit the same presentation because like I'm going to notice and it's kind of just irritating. Like it's not, it's not an awesome experience for reviewers and it's going to like split when people are going to be confused. On the other hand, the other thing to not do is like submit a talk that multiple people could give and then like change who's giving it at the last minute, right? Like yes, I understand multiple people can give it and you can put that in there and mention that, but try to know well in advance who's going to give the talk because we do keep track of that and we send you information and it goes in the program and if that's getting shuffled around, like we know last minute things happen, but we like don't just be like, eh, one of us will show up and do it, it's all the same, like, you know, please don't do that. Yeah, I mean, it's actually sort of policy that we're accepting a speaker and a talk, not just a talk. So when somebody has to change speakers, it's not guaranteed that the talk will still exist because sometimes honestly, our evaluation goes, eh, it's not a great proposal, but I've seen this person's other talks and they know how to make it really exciting, but then if that's not the person giving the talk, then we'll pull it. Mark's Center Program Committee for government, public information, what are the actual track names? Open government and we just changed it to the open AI and applied science track. But I do think this is a good time to talk, especially since we just had two questions from Linbid and AWS. One of the other things we keep an eye on for is what we would call a vendor talk, when it's just an ad. Like when basically like we've had talks in the past where everything in the proposal looks great and then what happens is that the talk itself is, and here's five minutes explanation, 10 minutes explanation of the problem and now here's 40 minutes about how our product solves your problem. And it's like, I mean, I get it, but at the same time it's like, is it an open source solution? Can I go and download it? Can I go run it? Do I need to be in your ecosystem to use the solution? And so on and so forth. If it's like, yeah, you gotta be using my product in order to solve this problem, well, it's not really in the scale ethos. So it's just something to keep in mind. Yeah. So like in the case of a lot of like, I know this because I work for a vendor, in the case of like, for this sort of thing is for a lot of us, we're for companies that have projects, right? And also have products and just keep the talk focused on the project. So Simon? Sure. I'm a bit hard of hearing in one ear. Now, how's the QI work? If it's in a huge room and people were asking questions or just shouting out without a mic, that could be a problem. Yeah. Well, in most of the rooms, we do actually have people use a mic because we want further recording. And if you have a hearing disability, please let us know about it and then we will do something about it. Like for example, in your particular case, we have volunteer proctors in each room. And so the easier solution for you is going to be have the proctor repeat the question to you from close up. That's excellent. Thank you. We're actually this year, we're actually specifically planning to potentially have some deaf presenters and are working on accommodations for that if we can make all the arrangements. OK, excellent. Also, I was talking about the laptop earlier. Is there any specifications like, I think it said HDMI port for the projector? Does it have to be a certain resolution or some projectors are a bit finicky? Yes. Oh, Leanne, that's you. I can't tell you off the top of my head, but when we send out the speaker information, we do indicate that information. And that is because it helps us with the live stream and the recording. Yeah, the other thing I'll say on that one is if you have your presentation ready ahead of time, then it's also possible to get a backup laptop to display things if something goes wrong, but only if we have it ahead of time. I do that for my tracks. If I don't have your can't do a backup for you. Right, OK. I'm also thinking about power as well and stuff like that, because I'm from the UK. So we're on. Yeah. Well, then again, laptops are switch mode, so it should be all right, I guess, but. Yeah, usually we do have a collection of video dongles available. There's a couple in their standard needs podium plus, like at the front, we have an extended set of video dongles. We do not have a collection of power adapters available. So you want to make sure that you've got the adapters. Yeah. Yeah, OK. Not every track in the past has dongles. I think we should talk. It would be great if we could do that for every room, but I can't guarantee that we'll actually have that forever room this year. So I don't want to promise that. Please bring dongles if you need them. And one more warning or one more note about vendors. We are a heavily like sponsor supported conference. So if you are from a company and a vendor and you really want to do a vendory sales pitchy talk, you can absolutely sponsor a session or track on the sponsored tracks day and you can have a room to do whatever you want. But that doesn't go through the CFP. You can email me and we can talk sponsorship and we can make that happen for you. And that's CFP at SoCalLinuxExpo.org. Yeah. Alan. Hi. Yeah. So mine's kind of specific to what I want to talk about. I wanted to do something about kind of open telemetry would be the OSS project. But I I'm looking at should I be very generic? So so we made a big migration from a probably a partner. You know, somebody that was a paid version of observability and then we transitioned down to kind of an OSS model. And I guess my question is really kind of should I focus on that transition where we're going from a paid product to a free product? Obviously leaving out the vendor, but or should I focus on kind of a generic talk about doing observability? So I guess it's a very specific question or should I do two kind of focuses? Yeah, I mean, putting on my hat as as one of the the tractors for KCDLA in the best of all possible worlds, I would actually love to see you submit both. One is to submit the migration story, which I would say everything else being equal is the thing we'd be more likely to take because sort of end user stories very popular. We don't get nearly enough of them. The I but it wouldn't hurt you to put in a generic sort of introduction to open telemetry because that's also something that people ask for. The like I said, we do skew towards beginners in terms of the scale audience. So any talk that is beginner oriented tends to be fairly popular. And then sorry, the how does the like DevOps? I mean, obviously, this pitch could also work for DevOps LA, right? Like, yep, how does that work in terms of is that a different project? Like, so I'm not really they all go through, right? They all go through the same form and you pick a track. And is a track, a separate track. Yeah, yes. And and we swap, like, particularly between those two, between DevOps days and KCD LA, we end up swapping a bunch of talks because because again, we're trying for program balance. And there's an awful lot of overlap, right? Because like, say, you know, hey, how do I run a Kubernetes team? Well, that could go into either one and then, you know, and then we'll, you know, go with the DevOps folks and say, oh, well, you know, we don't have any talks on sort of management. Could we get this one from you? Like, were you keen on it or could we have that for KCD LA? And then they'll be like, oh, hey, we need more CICD talks. Did you get any submitted? So, you know, I would say pick the thing that you personally would kind of like to more be in the room for. But but understand that that we. We will swap between tracks. We'll check it with you. You'll get an email message saying, hey, we decided your talk was better for KCD LA. You know, email us back if that's a problem, or as we'll assume you're OK with it. Yeah, I have been thinking about doing a sort of talk being like something broke. How do you fix this? That's a common thing I hit. I do a lot of work with Spark. So my thought for a talk was like your spark cluster is not working properly anymore and it's slow. How do you figure out what's wrong? Is that a talk? I love that talk in the open A.I. track. 100 percent every spark project I've run has always been six months over budget. That exact issue. So I'm here for it. OK, I'm almost like so long as you can string five sentences together and tell a good story you're in. Oh, that was easy. OK. Isn't isn't the general solution you just not running enough sparks? The the the sometimes more often than it should be. I want that talk. Let me just. OK. Yeah, the other because I had two ideas. That was one of them. The other one was the I do a lot of work where I import data from external sources. And so your source data changed. How do you catch that? Or there's an error in your source data? How do you look to those errors out? So that was my other sort of talk. Yeah. And is the machine is machine learning stuff all in your A.I. track mark so far? I mean, if I actually get like I'll be honest with you guys, like in the past, if we get more than like eight to ten A.I. data track submissions, then that's a big year. OK, so it's a good way to submit in that, but but also know that that that particular topic might potentially get picked up by any of like four different tracks because we also have a Postgres kill track with a Maya skill track and we have a data on Kubernetes track, all of which that could be potentially relevant for that was why I was asking. Yeah, I do it. I do a lot of stuff with like Python and Great Expectations is a tool I use a lot for catching data changes. But there's yeah, so. We don't really have a data engineering track. And yeah, that's why I open beta. And so this is what we're what we're running up into here is I like both of those talks. I love Great Expectations, too. The like the other thing that you're running into is now do we have the same person giving two talks? Yeah. And trying to like we like if there are six tracks, if there's six talks in the open data track, for instance, then not having you you give one third of those talks. Yeah. Oh, yeah, of course not. Yeah. But but you have your better. I mean, in general, and this was actually also answered in chat because because Christina asked it was our ideal is that each speaker gives one talk, right? Because that way they can devote all of their energy and attention to making that talk the best. Sometimes, though, people submit such good proposals in an areas where we don't have a lot of proposals that we have people give like a couple of talks. And sometimes people end up giving more than that because we have a certain number of professional career speakers who come to scale. And we counted those people to fill in when speakers cancel unexpectedly, which is how I end up giving five talks one scale, something I hope to never repeat. This is not a recommended practice. The. So we do do a sort of deduplication stage in the sort of final acceptance. I and and sometimes this is between tracks where track leads will be like, how much do you want this talk? Because she also submitted one in my track and I want to accept that. And then and then we work it out. The but but I would say, again, do submit both because one of our goals is program balance and you don't know what else is going to get submitted. First of all, the reason I asked about the if one gets selected and yet that's the other one gets dropped is because I will be submitting with multiple people. And I know, for example, KubeCon, when you submit, you have two submissions. And if you do submit with different people, if one gets accepted, the other gets dropped, essentially. But anyhow, I did want to run. I have two ideas. One is a workshop. The other is a talk and they're for different tracks. So I just wanted to kind of see the if since we're on the ML AI topic, I will one one thing we were thinking is vending ML Ops platforms for data scientists and using like Argo, crossplane, like a bunch of open source like Jupiter, Hop, Ray, Nats Park, sorry. Is that something that and we were targeting the data on Kubernetes track for that? I that actually would be like in my head, that's also up the alley of the AI track as well. That it happens to be on Kubernetes. There's definitely some convergence there. I thought when you started talking about ML Ops from AWS, I thought you were going to go into SageMaker and Bedrock. So like I was going to say, if it's all SageMaker and Bedrock, I would suggest that go in a sponsored conversation because there's definitely things you guys could talk about there, but like everything you just talked about, I think this would probably end up being what Josh was just talking about, which is, well, I want this track and you want that talk in your track and like how do we balance it out? The issue here is we can, that's why I'm asking because I don't know which day is the AI track. The problem is that KubeCon EU is the following week and then we have to travel and it starts on Monday. And there's like when you travel that way, it's a problem. So it's a very good point. And so if you have a particular constraint about when you can talk, please let us know that in the submit. So like in the past, we've had Friday, Saturday, Sunday for talks and open data and open government. And so we may say like, okay, well, what about, would Saturday work for you, right? And if you're like, now I need it to be Thursday, it's like, well, that might be a better workshop talk, right? Cause the workshops that happen on Thursday and then like, you said you wanted to do a workshop talk. So maybe that's- No, no, this is a different workshop. I don't think we'll have enough time to build this in a workshop. We'll have an example, maybe a demo, but not a full blown workshop on this. Right, so then put in your submission that like you got to be traveling on Sunday. Yeah, okay, all right. And yeah, and then because this is like solely on Kubernetes, I mean, all the tooling that I just mentioned, like the, like we're going to be installing Ray on Kubernetes and everything else, like, you know, cross-lanes Kubernetes, that's why we're thinking data on Kubernetes. Anyhow, the second one for the workshop is actually building internal developer platforms on Kubernetes, again, based on completely open source tooling, like similar Argo, cross-plane, Kube cost, yes. Yeah, and I would say that you can just submit in KCDLA. Yeah, that's the one. Yeah, I don't think the data on Kubernetes track has any plans for workshop time, although, you know, we might decide to label it that way. But submitted in KCDLA, which usually has four workshops associated with it. Okay, perfect. And last question is like, once I have the abstract, if I need some help before I submit, where do I reach out? Do it after you submit. After, so I first submit it then. Yeah, yeah, put a message in the reviewer, send us a note, because we will see that abstract and then we can like respond to it. Okay. And also put the slides, if you're on CNCF Slack, that you can absolutely ask about in the KCD Los Angeles gym. To refute the abstracts? To, yeah, or say, I mean, you would say I have an abstract in this, I wanted to get feedback on it. Yeah, because all of the organizers, the KCD track are in that channel. Okay, sounds good. Thank you. Before we get to KC, there was a question from Vincent Sloan who had to drop off. And it was specifically this question, if they want feedback on their abstracts, should they send it via email? You get the feedback and then submit, or should they submit and then kind of work on it? I am inclined to say submit, and then we will work on it because when you do that, those of us on the committee can all see the abstract and then we can have suggestions and then somebody can contact you and work with you, especially if we think it belongs in a particular track. Finish things off, KC. Sure, I was just gonna add one other thing about talk selections and replacements. So we do select speakers for slots within the tracks. We also select reserve speakers. And so if your talk is not selected, we may reach out to you around the same time that we reach out to accepted talks and say, would you like to be a reserve speaker? Some people are like, no, if I don't know if it's not guaranteed, then I'm not gonna write the presentation. But if you're willing to do that, this is also the way that sometimes we end up with the same speaker giving more than one talk. Maybe one of them was accepted and then they were a reserve for their other one and so it turned out that they were able to fill in because people do cancel and have things come up. Obviously, we wanna know as far in advance as possible if something like that happens. But yeah, so even if you are not fully accepted, you may be asked to be a reserve speaker if you are willing to do that. Yeah, and so I'd say is get working on it as soon as you can and don't miss the November 1st deadline.