 Good morning, good evening, good afternoon wherever you're hailing from welcome to another edition of the cloud native Thursday show here on OpenShift TV. I am Chris Short, executive producer of OpenShift TV and frequent host and I'm joined by two of my favorite Red Hatters, Amy Marich and Josh Burkus. Amy, would you like to go first in the round of introductions? Sure, my name is Amy Marich I'm on the same team with Chris and I serve as a principal technical marketing manager, focusing on OpenStack. In the open source world I'm known as Spots because I have Dalmatians, and I serve on the Open Infrastructure Foundation Board of Directors, as well as the chaos governing board. Josh, up to you. Hi, this is Josh Burkus. I am Red Hat's Kubernetes community manager. I'm involved with both the contributor experience SIG within Kubernetes and strategy within SIG within the cloud native computing foundation. And in both places have been pleased to see Kendall several times, bringing the wisdom of everything they've learned in OpenStack with her. And really looking forward to this. So, we have, Amy do you want to do the introduction? Sure. Kendall is one of my cohorts in crime in the OpenStack community. We serve on the first contacts SIG together. Kendall works for the Open Infrastructure Foundation as a developer advocate so I'm kind of giving away her intro slide, but Kendall take it away. So hopefully you can see my lovely presentation slides. Awesome. So, getting jumping right in, basically kind of covered some of this. I've been working in OpenStack since 2015. I originally worked on the Cinder project for IBM. And shortly after that I started at the formerly OpenStack Foundation now Open Infrastructure Foundation as an upstream developer advocate. And since then I have gotten involved in way more aspects of the OpenStack community so I'm like currently serving as the technical committee vice chair. I'm involved in the release management team. A lot of my focus is on upstream development making it easier for new contributors to get in the door. So, I've done a lot of development on our upstream institute program and our contributor guide. I have also started working in the open, or the Kubernetes community that's been more recent only since 2019. I try to share as much of my knowledge as possible with the SIG contributor experience and I try to keep tabs on provider OpenStack in the SIG cloud provider and kind of bridge our communities together. So, when I'm not doing all of this open source stuff. I used to like to travel but obviously that's not a thing right now. So someday soon hopefully. But I also really love photography, Harry Potter and who doesn't love Dr. Who and if you don't you should really get into it because it's amazing. Never got into it. Oh, so good. Never. Never. I have never seen a single episode. Never watched an episode. Okay, we'll fix that. I will give you a list of episodes to watch that will get you hooked. Okay, thank you. Yeah, so OpenStack. It's a super awesome community. I have been involved for a long time now. And so I've kind of put together this list of like tools, resources, programs, communities, all the different things that we have to help bring people in and kind of get them up to speed and whatnot. So we have a lot of resources and tools, obviously. So when you're new to a community, you probably want to go look at like, how do I get involved what what accounts do I need. What tools do they use that sort of thing and all of that is covered in our contributor guide. We have it kind of broken up into different areas of interest based on like, are you going to go and programmed you want to do code and docs or maybe you're like a non code contributor person or more of a user of OpenStack and want to get involved. So we have it kind of broken into those sections. Most people probably are going to come to the code and docs section. So we have a very lengthy list of things that are good for you to know. But obviously there's a like should be a quick start version so we have like a list of the very bare minimum requirements that you need to get set up to to get going but I highly recommend working through this whole thing. So if you're interested in really really getting involved in being a member of the community and maybe moving into roles like PTL or like a technical committee member someday. So, yeah, so you can go directly to the contributor guide it's in our documentation, or we have a contributor role that's kind of like a landing spot from the like main OpenStack site. I love tabs. They're really great. Yeah, and the portal was created with like a choose your own adventure. Yep. So basically you you kind of see that overview where it's like Oh, well, how do I want to contribute. And then there's a huge list of resources that I'll go into more in my slides and a little bit here too but So, so which path through this gets me eaten by a group. Several of them. I like it. I'll like go into like the groups of people on a later slide but several of them will bring you to groups of people that will help you if you need the that there's also the the info manual which is a little bit more of the nitty gritty details of like setting up a project if you're interested in contributing that way. But most people aren't really going to need that. It's just more in depth stuff. After you work through contributor guides, our larger community contributor guide, there are more project specific ones because each of our sub projects, the individual services like Nova and Cinder and Manila and Keystone, have you they all. Every project has a different like culture. And so there might be small differences in the processes how they do things get things done so they have more project specific details, and all of the general stuff that's widely applicable across all of the open step projects and the contributor guide. You get a little bit deeper into things and are interested in like messing around with like maybe changes that you've made or testing things. The dev stack documentation might be a place you want to go and dig through. And on on a wieldy beast that could probably be a whole different topic for cloud tech Thursday. But yeah, as a community we chat synchronously on IRC. I know Slack is very popular in a lot of different communities and discord and all kinds of different things but we're super old school and we like IRC. We don't use Garrett as our code review system so we don't use GitHub, like a lot of communities. So review.opendev.org is where we go to do code reviews. We also have some other like community sort tools so ether pad and ether calc are basically open source equivalents of Google docs and Google sheets. And ether pad is a like video chatting sort of service that we host as a community. Yeah, it's based off jitsu jitzy. Not the martial art. It's jitzy. Yeah. Interop is also very, very helpful. It basically has all of the meeting details for all of the groups across open stack. When they meet logs from their previous meetings, the agendas for upcoming meetings. Also in here you can go and find the IRC channel logs because every single one of our official channels are logged so if you don't happen to have an IRC bouncer set up you can keep up to date on what people have been talking about you can go back and read those logs they're really handy for referencing things that I don't remember that I said three years ago. All of that is there. And then, obviously, can't do a whole lot without paste, which is super handy. I don't know why I can't post tabs today. Whatever. Not important. Tabs are hard. I try to not use many of them. I like keep my area want to see my 20 plus. Yeah, no, no, I keep what five things pinned and then not normally more than like six tabs at a time because I just, I can't. But yeah, completely understand. Yeah. It's beautiful. It's so much easier to see things. So, moving on from resources and tools we have like our community groups and channels which was kind of what Josh was asking before. So this first contact group is roughly the Kubernetes equivalent of sick contributor experience. We exist to try to help catch all of the newcomer questions we try to pay really close attention to the like open stack mailing lists and make sure that people that introduce themselves and they're like, Hi, I'm new. Where do I start. We respond to them. We also try to monitor various question sites. So like, we had asked open stack.org which is now read only but previously we had been monitoring that for newcomer questions new contributor questions. And I will also start monitoring like stack overflow for new contributor questions related to open stack. And that group of people, we all hang out in open stack dash upstream dash Institute that channel is on free noted IRC. The other thing that we as the first contact sig do is manage a list of project liaisons. So, a lot of us are involved in different open stack services but if one of us isn't directly involved and can't really give a lot of advice to somebody on say, like, I don't really know a whole lot about the QA project. I know somebody that does work on the QA project and I will introduce you to them. He is super awesome but we maintain this list of project liaisons so that if we don't know how to answer your question, we can go and connect you with somebody and that's this project liaison for that respective open stack service. So we we try to make sure that there will be somebody to catch you in any project at any step of the way, and help you find the answer to your question or get you started and, and all of that. So one thing I found in some other projects is that asking younger developers to get on IRC is kind of a major hurdle. So is open stack done is it looking at doing things like using repeaters to bring IRC together with some newer more popular chat mechanism like slack right now is kind of an obstacle but telegram or discord or something else. And people have definitely looked into that I personally haven't done a whole lot I like, I started IBM and they were like okay set up IRC and I was like, okay. And then, and then I did and now I'm like, I love IRC it's great. So, like, I know there are a couple people like on my team specifically that don't use slack and get things piped from slack into IRC but I haven't heard a whole lot about going the other way. Well, there used to be the bridge and the bridge went away. Yeah, that's because slack deliberately made it stop working. Yeah. Yeah. What party poopers man. Yeah, I know it's because I mean for this over blue fedora silver blue channel for example we have a sort of two way bridge for IRC and telegram. Okay, because telegram is really popular among European developer crowd that's a lot of our user base. Okay, yeah. I mean, it's definitely a popular topic using IRC that comes up with somewhat comical regularity. But we like as a as a community we don't have any like official process for being like well you don't want to be on IRC but you need to be able to talk on IRC so this is what you should do. We do kind of promote the use of like web clients for when people don't want to futz with like installing a desktop client and that and sometimes the web clients like IRC cloud for example are a little bit more user friendly and like have a prettier UI and stuff. So, we usually promote those as options and alternatives. Yeah, I am a IRC cloud subscriber. Me too, because that allows me to have it on my phone all the time, which is really excellent for work life balance. That's the good thing is like what people tell me all the time with you know slack for example is the reason why they like slack is because the phone client. I don't have slack on my phone. I do. I do. I have slack and IRC on my phone. I have way too many slacks that I'm in it has to be that way. But I also answer from the horse. So I'm a little weird that way. One thing I didn't want to point out while we're looking at this slide is you'll notice that the first contact SIG is on OpenStack Upstream Institute and the DNI working group is open infrared diversity. So with the change to open infrastructure foundation, those channels that were more foundation related are now on open infrared. So the diversity and working group reports directly to the board of directors. So we are an open infrared channel. Those things that are specifically open stack on open stack anything that is like Kata or airship or Starling X, though not all of those are on IRC, they would have their own channel naming. Yeah. Yeah. That was very eloquently put and well, good, good thing to point out because I definitely was like, I'll just write the channels down, blah, blah, blah. But yeah, so the diversity and inclusion working group is another super friendly group that has a lot of overlap with the first contact SIG. That is around to help and address concerns and answer questions and that sort of thing. So they're all super friendly people. And I am friends with all of them, I would say. Yeah, so events and programs, we have like a lot of different mechanisms obviously so we have like a bunch of documentation written down things if that's your style of getting involved. But sometimes that might be intimidating and you'd rather like go to an event or something. So we have a variety of ways of getting in through events and programs into the community. Upstream Institute is the one that I have spent the most time working on. This is our just basic onboarding program that we run. We used to do it every summit, and it would be two days, the weekend right before the summit started actually so that you would be kind of up to speed before you got thrown into the mix of the giant event. And we now only doing one summit a year have just been doing it once a year and sort of twice like we used to. But we have also over the last couple years started hosting them at more local events like and infrastructure days and open stack days. So if those are happening in your area and you're interested in like attending a contributor onboarding session. If you can talk to the organizers they will contact me and or my partner in crime Ildacovaccia and she and I are the ones that normally travel to those and host it, though, obviously travel disclaimer travel rona right now. But I hope someday to get traveling around again and doing those. And we have that split into two parts now where it was just like all one giant program before we we've kind of abstracted out to the open dev tooling, which is like IRC and like how to use Garrett and like those sorts of things that are applicable across all of the infrastructure projects or most of them at least because we have a few that don't quite use all the same tooling but it is applicable outside of just open stack which is the important part and the distinction to make, because we have a open stack module that covers like our release cadence and release cycles and that sort of thing and governance and our community structure and and all of that so we we figured by splitting it up we would have different sorts of audiences and make it easier for people to commit to because the other part that we noticed was that as a like two day long training or a day and a half long training that is a long time to try to hold people's attention so we're like okay let's make this easier more palatable. And so we have made those changes. The next thing is like after you've gone through the contributor guide and you kind of know, have your stuff set up if you know what service, what open sex service what project you're interested in being involved in. So you can look to see if they're going to be doing project onboarding at the project team gathering that is coming up in April from the 19th through the 23rd. And want to explain what the PTG actually is. Yes, yes. So the project teams gathering the PTG is a more technically focused discussion roadmap planning. We're going to implement this focused event for our technical teams. So that covers like basically the open stack services but we also have like SIGs and the open stack technical committee meeting there as well. And it's basically a place for those teams to meet and have like, well, it used to be face to face discussions it is kind of be a video now. And if they need to like work with another team to like get something done they'll hop over into that video call or that room and go have those discussions. It's a free event, but it's definitely not like a regular conference at all. Yeah, it's a place where we get things done. So if you're thinking you want to get involved, you know, as Kendall mentioned there's project onboarding, but say your company wants to work on a new driver. So this would be a great opportunity for you to come meet with that team discuss, you know, your driver how to get it implemented what you need to do and so on, and also get it on their roadmap. So that's the big difference about the PTG is consider your hands on working sessions versus something like summit which is more presentations and everything else. Yeah, yeah, we don't get a whole lot of like marketing folks coming because it's not important for them really. It's like the people that are actually working upstream or like need to get something implemented or fix some bug or whatever. Those are the people that are in these discussions and maybe some operators who want to get a little more hands on and know what's going on and ask questions. So wanting to get back to it's sort of an earlier part which is because you say things like if you know which project you want to work on. So, how do new contributors figure out which project they want to work on. So a lot of times that will be dictated by your company, like, for example, when I started IBM was like you can work on cinder or keystone and I was like, I don't know what either of those are but I'll go find out. I ended up working on cinder because they needed block storage help. So I went there. So, if you don't know what do you want to work on you just want to get involved, we have other resources for that which I will get to on the next slide through the help wanted list. And like in upstream investment opportunities. So they're like two kind of paths that you might be coming from like you know what you want to work on, and you're like yes I'm going to go to the PTG and I'm going to join Nova. And I'm going to get to know this person and this person and I have this thing that I want implemented, or you're like open stack seems super cool and I want to get involved and I don't know what to go work on. And so you would, you know, message the first contact sig, or send an email to the mailing list and be like hey, I want to get involved. I don't really know what I want to work on but these are my areas of knowledge, things I can help with, whatever, and we have mechanisms for that to which I'll go into. Yeah, and sometimes it could be like from an operator side. I was working on this and I noticed this issue. And I can actually patch it. So then you go on to IRC you talk to them, you go through the different mechanisms for filling out bugs which Kendall you're going to cover that. Okay, yeah. So then that's how you get involved in a project. Like I've got patches in probably five or six projects because a lot of times I go through the documentation and I notice something's wrong with the install guide for them so then I go and fix a client or I do something that particular service. And, you know, so that's how you get involved in a lot of different projects even though that's not your main project, it's still a project you've contributed to. Yeah. Yeah, there's a no rules that say you can only participate in one project at a time I have my fingers and many pies, many, many pies at any given time so yeah, we definitely encourage like if you find something and you know how to fix it, go ahead and do it, and we will help you through that process. So Upstream Institute and the project onboarding at the PTTs are the two more like industry sort paths in where like you are employed or are doing it as a hobby. And the last three are more for students at university still so Art Ritchie is a program that we participate in that's hosted by the Software Freedom Conservancy and we've been involved for, I don't know, many years now. Basically it's an internship program and every summer and winter. And it's funny as I say that I'm like, but it's different in parts of the world. So, every summer and winter for like North America, and like this part of the, or this part of the hemisphere. Yeah, the northern hemisphere. I was like, this one, no, this one. So for northern hemisphere summer and winter. They run, I think it's like four ish month long internships and they're actually paid internships and basically the whole point of the program is to increase diversity and open source projects and also to just like get more students involved in open source in addition to increasing diversity so I have had a number of interns that have been super awesome and I am still friends with and like mentor, even though they're like graduated from university now. So it's a really excellent program. Similar to the Google summer, Google summer of code, another North American summer thing. We have participated in this program once or twice, and it's kind of hard to get selected because so many people want to participate so we usually focus more of our effort on outreach, but it's, it's another excellent program for university students to get involved in and we have partnerships with a couple different universities if you happen to go to one of these like Boston University has put out calls to the open stack community for work for various classes, where they want people to get involved in open source projects and various like senior design courses as well I have a group of three seniors at Boston University right now that are working on the open stack SDK. And then I have a group of like junior and seniors at North Dakota State University who have similar to like a senior design project they call it they're like capstone. They're also working on the open stack SDK, I have fun all of them I have a whole team of minions working on the SDK right now. But yeah so we we've tried to grow those relationships and I look forward to this list being longer in the future. Though I only have one of me so would love more help mentoring as well. So to start, if you don't know what project you are interested in getting involved in. We have this help most wanted list or upstream investment opportunities that we set up at the beginning of every year. And basically we outline 234 areas within open stack that could really use extra hands. So we have descriptions of those. So, one of our focuses over the last release or two has been around policy and policy defaults. And so like that was one thing that we put on this list. We really could use more QA quality assurance developers as could everybody I imagine but yeah so we keep this list up to date we go through it every year and we try to be like these are three areas. If you have a or if a company has somebody that is has the time to work on an open source project and you just don't know where to put them you don't really care what project they're working on. So we put this list and we would love help these areas. Yeah, so these are just these are for like major initiatives right like you know these are bigger things. The add support for, you know, some new public cloud. Yeah, yeah, these investment opportunities are more long term focused, as opposed to like a small little thing, which I will get to it's further down the list on my slide. They're, they're more like, I have 50% of my time to work upstream on a project and basically have free range to do whatever I want. This is a list that would be good for you. So yeah, and community goals were listed on there. So the community with the direction of the technical committee sets community goals every release cycle. And where's the list here down here. So we have like priority things that we want to get done, and we want to get them done by the end of the release. So for our current one that we're working on a wallaby which ends in like a month already. Geez. So the two focuses have been more of that policy stuff that I mentioned earlier, and also moving Oslo route wrap to Oslo proof step, really, really stuff but that basically they're the things that aren't as like shiny as a new feature but things that we really need to get done as a community across all of the open stack services. So we try to draw attention to those so if you have maybe a few extra cycles to spare and want to help with one of those community initiatives but don't want to do something from the community investment opportunities. Then maybe that's the path for you. So this last bullet point I have about the low hanging fruit tag. So that is the very small, easy places to get started. You can go to either launchpad or storyboard because our community is currently spit split across those two task tracking tools. So you can search for that tag. And it will bring up a lengthy list of easy to get started on bugs or tasks. Usually, this test is weird or this documentation is wrong. There's a typo here, that sort of thing so it kind of helps you get your feet wet in and maybe make a connection with somebody that can give you some bigger piece of work. Or maybe after you get a few of those things done you're like okay maybe I'm ready to help with one of the community goals or I'm actually going to go and become focused on the policy stuff in one of the upstream investment opportunities. Or maybe you see a bug that you know you were kind of interested in previously but you didn't have the confidence to do so now you're going to go ahead and take that bug. Yeah. You know another good place to start is documentation if you see something wrong in the documentation. Yeah, watch out. They're always welcome. So, so we're only low hanging fruit that's the same thing as get hubs good first issue yeah. Yes, yes, that is the equivalent. Correct. So, our biggest problems has been maintaining the, you know, sort of currency of good first issue as in the problem with the good first issues are generally easy fixes, which means they tend to actually get fixed relatively rapidly and so keeping items on that list has been sort of an ongoing challenge in Kubernetes. How do you, how do you address that. I do think it's kind of like an ebb and flow sort of situation. Some project teams are focused on like, I'm just going to like file bug for that and whatever, like, I'll fix it later. And then other ones are like I'm not even going to file a bug for that I'm going to fix it right now. Like, it kind of just depends on the, the like culture of the project that I mentioned before. It varies a lot. I think some of the sources that we find those is like an operator will mention something like Amy was talking about with like an issue in an install guide, and they'll be like I don't know how to file the bug or I don't want to fix the thing so I'm just going to file a bug for it and then one of the upstream developers on that project will be like, I don't have time for this so they just market as like low hanging fruit, but we have several years in a row where various companies were hosting like bug smash days and those sorts of things definitely spurred the community to like go and pull out a bunch of the low hanging fruit things and make sure to triage all of their things and like label those things. So I think, like, the need for them kind of makes them like draws more attention to the fact that it might be a shorter list. And, and that kind of answer your question. I mean, you know, it answered my question that you haven't found a lower effort shortcut for maintaining this list, because the struggle we always have right is that I go to a Kubernetes SIG lead and I'm like hey we've noticed that there's no good first issues marked with your SIG, you know, and those are a good way to get new contributors involved. And the problem is, it takes me more effort to maintain the good first issues list, then it would take me to fix the issues in the first place. Yeah, yeah, I think it's a matter of like perspective right because then like, there's a lot of go getter people that are like well why would I just, why would I bother spending the effort to like tag this thing when I could go fix it like you're saying, but then, like, teaching them that there's value in like leaving those things and maybe go work on something that's a little bit more complicated, so that you can get more hands and like showing them the importance of having those to get new contributors is like. I mean I was definitely guilty of that this week because I noticed a problem with install guide so I patched it. Yeah. But to make sure we don't have that same issue with the install guide maybe what I'll do is open a bug and tag it for the wall of the release. And hopefully someone will pick it up but if it's not done within a certain amount of time I'll probably go ahead and pick up that bug. Yeah, because it'll need to be like backported or whatever. Well it's was the fact that we didn't have Victoria even listed and the install guide. So I can't, I can't stay that way for long. But yet again it was a very easy bug that someone else could have picked up but the fact that we hadn't updated that documentation was just, I got to get this done. I'm trying to find someone so I'll take it on myself to go ahead and open up a proactive bug. And if we don't have it done within a week of the release I'll go ahead and do the bug. Yeah. Definitely perspective helps with those sorts of things being like aware but not everybody's like that we all think differently. Well it's it's honestly when I found there's a problem it's more of an effort thing. It's not they don't understand why it's useful to have good first issue stuff. It's just not it doesn't end up anywhere in the top seven priorities. Yeah, yeah. I think that that's where the things like the bug smashes that we used to have kind of like force that priority periodically. And then like when you do that, like, in our case, not all of the low hanging fruit or good first issues would be solved. And so you'd like have a little bit of a backlog for a while and then like that thing would come around again and then it definitely helped to have that, like, on a cyclic sort of pattern. Yeah. And if none of those things appeal to you if you don't want to go look at low hanging fruit or community goals or upstream investment opportunities. You can just go and attend any of the like service team meetings that I had shown the link to eavesdrop site at the very beginning. There are meetings happening all the time and if there's a topic that interests you say you're really interested in acceleration or something you go and join the like cyber team or maybe authentication is really your jam and you can go and join the keystone team and go and see what they're talking about in their meetings look at their agenda and just introduce yourself and be like hey I'm interested in getting involved. Where can I help. That definitely works to were a very friendly open community that would always love her contributors so come join us. One of us, one of us. Yeah, and you point out on this slide as well code reviews that's a great place to get started. Look at code look at the comments on the code. That'll give you a little a little confidence before you pick up one of those low hanging fruits or an actual bug. Yeah. One part of code reviews that I think I wish would have been taught to me at the beginning was like, when you're doing a code review you can like download the person's patch and go play with it and test it. And like that's a really good way of getting familiar with like that section of the code because open stack is such a giant project and even a single project with or sub project within open staff like Nova center or what have you is a pretty big code base and so you want to like take it down to a smaller scale than that and code reviews are a good place to kind of like okay I'm going to get familiar with like this section of code and this section and this section where you kind of learn how to connect them together and before long, they're like, okay, I understand how Cinder works. Yeah, I'll also say honestly in general, just doing that, like, you know, adding the patch and trying out the feature is useful and it's really helpful for the more senior contributors to have somebody say, you know, hey, I actually tried this patch and it works as specified because that means the senior reviewer can focus only on code quality and side effects and other issues. And they, you know, can kind of skip over the part where they say hey does this actually meet what the spec is. Yeah. And like new perspective is so helpful. A lot of times because like somebody that's really familiar with the code is going to go and make a change and then like not comment it because they know how it works and it makes sense to them and they kind of described it in the commit message, but like, and then a new contributor can come in and be like why did you do it this way and not that way. Like it's, it's okay to ask questions, like, it's really good to have as much of that context and backstory and everything there as possible and the new perspective. Fresh set of eyes really helps with that. And one thing I had never even thought of, but it was during one of the mentoring panels we did at summit was that code reviews and how you react to other people's feedback can be important in a job interview like they were looking at people's patches and the reviews on them to see how people, you know, took the feedback and how they applied it so it wasn't just their code that was being looked at, but the interactions with others. Yeah, that was a really interesting aspect that I had never even thought of before. Everything you say on the internet is there forever, basically. Yeah, so code reviews are another great place to start. If you prefer going in that way. There are so many different paths into every single open source community and we do our best to pay attention and support new contributors on every single one of them but sometimes things get lost and we like it's a it's an ongoing improvement cycle and struggle and if you have any feedback on anything, any of the things I've talked about today, please let me know if you think something's great or garbage, let me know. I will do what I can to fix it and make it better because that's my job and I really enjoy it. Yeah, questions, I guess. Any questions from the audience for Kendall. Nothing yet. I am all kinds of contactable as discussed earlier I have little to no work balance or separation. I have IRC on my phone my IRC handle on my phone is Diablo rojo phone actually. I just have the same one. Yeah, use the same one. I use different ones so that people know, hopefully, more aware of the fact that they're bringing me to my phone as opposed to like very smart. Yeah, I mean I don't really care. But, yeah. It's there for acknowledgement or not and I'll probably reply or whatever. Yeah. Yeah, you got a new open info.dev email address. Yeah, they alias the old ones it's all fancy now. Okay, Nelson open info.gov or canelson.openstack.org. They'll come to me. So, I have some discussion topics here. The one thing I was going to ask you is you're pretty aware of also what we're doing within Kubernetes. Yeah, in terms of mentoring and onboarding and that sort of thing. Yeah, and Aside from the beyond behind schedule state of things. I what things have you found that's essential in getting started and onboarding and stuff that that you've learned through open stack is essential. That we're not doing in Kubernetes and don't have an initiative to do. Oh, that's kind of a tough question. Are you doing upstream Institute. I know. Yeah, they haven't had the conferences. You all have started doing the speed mentoring. Yeah, something we started. Everyone seems to be doing that nowadays and I find those extremely helpful when I do mentoring at those. Now the interesting thing is while those are really popular the mentoring programs themselves kind of go stagnant. Yeah, the within community mentoring programs. So we had actually switched from our one to one to more of a cohort which is more what Kubernetes was doing, hoping that that would relieve some of the pressure on the mentors. But again, we just really didn't seem to get picked up with that. So I think mentoring for all the communities is still something that we all need to work on. You know it's great outreachy Google summer of code Google summer of docs those things are paid. So I think they get a little more attention. Yeah, a little more interactivity because you know the interns know they're getting paid for this they need to participate. Being available to mentor people, which is something I think the communities are really good about, but no one takes advantage of. Well, I think simultaneously having a like clear timeline that are given by outreachy and the Google summer of code and those other like university partnerships that open stack house. Because it's like, you start this day and you end this day that's like very clear and like, there's a nice need to bow on it for both the like students and the mentors themselves because like, for example, the North Dakota State University that I'm working with right now. In the community I'm working with Artem and Steven finnequin, and both of them were like well, so long as there's like what what do you need from me exactly because I can commit to a like set amount of time, but outside of that like extra manager approval and all this other stuff so I think that things that are really clearly defined like those programs are why we see more success there than like the ethereal wishy-washy like like yeah, work on your own timeline sort of thing, which is great for like some people but it's really hard to keep that sustainable because it is very like well maybe it's still happening or maybe it's not and like, yeah. The major obstacle we've had with outreachy and summer of code and LFX and the other programs is that of course, they have their own timelines that don't happen to sync up with our release timeline. And of course you want to assign one of those interns a major project right because they've got like a 10 week block to work full time on something. But you know then we run into issues like they're done with their 10 weeks, and then we're getting to actually merging their code a month and a half later, and they're like sorry can't talk to you doing graduate, you know papers. Yeah, matching those timelines is also super hard. Yeah. And I don't really have a good way of dealing with that. Yeah, I think the only way would really be to get someone who's becomes really invested either in that patch or the community. Yeah, therefore sticks around. There's no way I'm here for this internship and I'm gone. Yeah, that's true. But you don't, you don't always get that right sometimes what the intern basically learns is they want to work on a different project. Plus, if they are still in school and they're going back for another term. You know, no matter what the level of interest is in your project that doesn't mean they necessarily have the availability. Yeah, I think one of the ways that like we try to combat that is like, yeah, we have this big thing that we want we want all of placement implemented in the open stack SDK, but do that one resource at a time. And so we try to like break things down into really really small, mergeable pieces of code so that if they do leave in the middle we can be like okay well let's assign somebody else to like finish the rest of this up. Yeah, that's fine. And also the other thing that's really great about like the way we do code reviews and stuff is, it is very very easy for anyone in the community to go and pick up something that someone else was working on, like download their patch make changes and then upload to the same patch chain. Or depending on what it is you can actually patch it within Garrett. Yeah, exactly. And that's a more culture sort of thing that we have where we're like, you know, here you go hot potato your turn you go ahead and fix this or maybe I'm on vacation and someone else is going to fix the thing that I was working on while I'm on vacation and I'm not going to get upset about that because we're all one big happy community, but I know that's not a thing for everybody and some people are like really possessive of like, I'm working on this it's mine. By breaking things down and also changing the community culture of being like, let's all work together. sorts of things help with some of that. Okay, the. It sounds good I have. I have other questions about, you know, experience with Jared. Yeah, 10 years on 12 years on how long has Jared been around the. But, but I think that we're getting a little off topic for for the original presentation. And I'm also getting a flag that they're going to start prep for the next show soon. Yeah, looks like so trouble in paradise. So. So wow thank you very much. I thank you and this will help more people get started with open stack. Yeah, my pleasure. Happy, happy to share knowledge from contactable basically all the time unless I'm sleeping. And yeah, thanks for having me. And two weeks from now, our next show we will be introducing a new brand new cloud native project called scribe, which is automated. Automated replication based reliability for your Kubernetes cluster. So come and learn all about that project two weeks from today. And we will see you then. Amy last thoughts. No, I just want to thank Kendall for joining us at the last minute. We don't really appreciate that our previous speaker that we were asking to talk about info watch was unable to attend. So I pinged her on Monday so I really do appreciate her coming in joining us today. I made my slides like less than 12 hours ago. It's great. Yeah, happy to help. Enjoy of open open stack. Thanks everyone. Thank you. Thank you.