 Well, Jen is recommending that we may get started. I think that's reasonable. We'll just go ahead and start introducing ourselves. So my name is Ruth Sealy. I'm the senior manager of the community outreach team at Red Hat in our open source program office. My name is Brian Profit. I am a manager on the community outreach team within the open source program office. I'm Brian Varensthausen, also from the open source program office at Red Hat. I'm a community architect and I work on enabling materials in hospital. Hey, I'm Brendan Connaboy. I'm a project manager, people manager, engineer inside our engineering organization with a special focus on rail and everything before and after it. So we all come at community and project management and all of those things from a little bit different angles, but this is a Q&A. So if there are folks with questions, go ahead and drop them in chat. Tell us who you are, what you're interested in hearing about. So Hina says, so everything relevant. That's a terrible pun. I just picked up on that. We have 15 folks watching. So please speak up and ask your questions. While we wait for people to ask them questions, Brian with a B, we have this problem all the time. Why don't you tell us what's new with the open or community? Because some things have changed since maybe people have heard about it last. Assuming I'm Brian with a B, I will gladly answer that question. Brian with a B. So I work with a great upstream community project called the Open Organization Project. And I think it's a great example of a way that the open source development model and the open source community model can be applied to projects that aren't necessarily related to software development. So and I'll tell you a little bit about it and what we've been working on and encourage you to get started. Some folks on the call might know that about five years ago, the then CEO of Red Hat, now president of IBM, Jim Whitehurst wrote a book called The Open Organization, which is really about Red Hat and the way that Red Hat's Genesis in open source led to an interesting organizational culture and an interesting organizational model. And several people have asked, and so Jim wrote the book, about the way that open principles, the same principles on which many of the most productive and innovative open source communities across the globe are couched in, how those can be applied to an organization, any organization. And that book, when it debuted, sparked a community conversation that five years later still continues. And that conversation concerns all the ways that open principles, principles like transparency, collaboration, inclusivity, the way these principles can be the bedrock of not just an open source software community, but any organization and organizational model and the community has extended that conversation in the form of a book series, taking Jim's original book and extending it into a series of books has continues to maintain a definition of an open organization that anyone can use and produce Creative Commons license to articles and other resources that anyone can use to try to figure out how they can leverage open principles in their organization, even if they're not an open source software company, and even if they're not an open source community. But we use open source platforms and methods to govern our community, right? So we, you know, all our books are developed on GitHub. Our meetings take place in the open and we have a community on discourse. We continue to license our materials via Creative Commons. And so while our community does not necessarily produce open code, we produce open resources in the spirit that the communities who produce that open code make their stuff in, right? So I encourage you to come check us out if you are a non-technical contributor to open source, but really want to understand and tell others about the ways that open principles can make a difference outside of software development. You can check us out at theopenorganization.org. And if you want to interact with our community, come to theopenorganization.community and leave us a note. We'd love to talk to you. Awesome. Thanks. Is that the pitch? That was. Cool. Yeah, sure. A plus. A drop your link in the chat too for everyone. And while you do that, so we have a few questions popping up. Neil, I'm going to come back to your question. I'm going to skip it for now because we're hoping that Jen, who is particularly an expert, will be able to join and have audio. So I will go to the next question. Are there any tips and processes that you all would recommend non-open source projects and companies start adopting as tools for their success? I assume that means in the direction of doing things more openly, although that may not be where they are now. Correct. All right. Should we just round Robin this one? Yeah, go. All right. I'll take the first step, which is stop being secretive about everything. Like it's not actually valuable. All you're doing is impeding progress and slowing yourself down. Unless you're in a place where you need to slow yourself down, secrets are just harmful because as soon as a decision is made or information is out there, then there are people that have it and people who don't have it and then they can't make good decisions together. So like to share information openly and to share information in the decision-making process openly is a faster way to get better decisions with everybody bought in. And like the failure to do that is, is, I don't know, it is a source of so much strife. So just stop being secretive. Yeah, we have an easy three-word phrase for that, default to open. Yeah. Everything's open unless you have a really, really good reason that it's not. I much agree. I've done a lot of government projects and even military projects and they're even finding, ah, welcome, Jen. They're even finding that secrets slow things down and are harmful even for their use. So it really gives a message to other organizations that have an easier row to hoe. Any other thoughts on that? I think beyond the upstream first and default to open philosophies, I think you know, from a tool side, a pragmatic side, definitely try to do a lot of your work on tools that allow for open collaboration. Whether that's get lab or get hub or, you know, something that, you know, changes can be made in public that can be seen and definitely have a policy in place where you allow outside contributions, you know, from outside your organization. Don't be an organization that will, you know, like that basically just says, okay, we're open, but really nobody's, we're not going to let any new contributions in. So that's certainly a key to doing, you know, beyond, you know, apply your work in the upstream first, actually working on tools that everybody can, where the work can be seen. One of the things I think we learn about collaboration from open source communities is a really interesting dynamic that I think any organization or any group or team can adopt. And it's as simple as starting with collaboration first, right? Not the model of that's more common, what I would call like sort of add collaboration and stir, right? So think of like every project you've done like in school or with a group project where it's like, oh, we need to collaborate on this. Okay, so you do this part and you do this part and you do this part and you do this part and then like a week before the project we'll bring them all together and like mash them up and see how they work together, right? Not an effective method of collaboration necessarily. It's sort of what I call add collaboration and stir, right? But the way open source projects work is somewhat different, right? They begin projects together. Every project, every initiative begins as a collaborative effort by default, right? So just as something might be open and transparent by default, it can be collaborative by default where people are working in the same thing or on the same thing and in the same direction and at the same time. And instead of having a bunch of pieces that ultimately come together in the end or a bunch of individual interests that ultimately get subsumed into a whole you have the other dynamic where you have a group that's collaborating by default and then forking only when their needs differ, right? When these differences appear, right? And guess what? The more you work together the more you realize that forking is an anomaly, right? That those divergent paths are actually unnecessary in most cases that most people's ends are the same. And so you get a really interesting model of collaboration out of the open source methodology that I think anybody can adopt and to see success with. I'll put in the chat a link to a book that the open organization community has continues to maintain. It's called The Open Organization Workbook and it's a book that takes the open organization definition one of the principles of which is collaboration and offers exercises and case studies that you can read and study and enact with your team to kind of leverage the principle from the open source way into your organization even if you're not building code, right? So there's some great exercises around for example, collaboration in here that don't necessarily involve collaborating on code but take lessons we learn from open source communities and open source projects and help insinuate them in organizations of all kinds and all sizes. I'll put that in the chat. It's useful. All right. I was going to ask thoughtfully about how difficult this is in an organization that doesn't use or contribute to open source in any way except I think Brian gave you the answer which is we have entire books and websites and resources about this. So there you go. And it sounds like Jen has audio. Do I have audio? Yay. Seriously, seriously happen too. It seems like it seized my Chrome browser and then didn't want to release me from a circular wheel of death if you would. So thanks so much for being patient to everybody and I'm sorry that I wasn't here to introduce myself in the beginning. I am Jen Krieger, Chief Agilist in the Product Technologies Division at Red Hat and I see that there are a bunch of questions in chat. Keep them coming in. And I think the one that came in first that we didn't answer immediately was how do you help bring community into agile development processes? I'm assuming you skipped over it because I wasn't around. Yep, so here you are. Go. And it's like I also realized that I invited my team to come and ask any question that they had regardless of what the topic was so that might also create a little bit of a sideways thing here. But honestly, there was a really great talk earlier by Lee Griffin if you were not in that talk. He spent like an hour, I feel like. It was a long time talking about how the CPE team in the Fedora community has been using internal agile techniques and how they're trying to make them visible to the external community. And I think a large portion of the talk centered around making sure that there were making sure that there was a human on the other side of that of that team. You know, perspective, if you would, that there was actually somebody on the other side of that not just another person who's just writing code, right. And I really appreciated the perspective because oftentimes it's really easy to to especially in the Internet to do this thing where we're just like we don't really take care in the other person on the other side because we don't have we don't have that personal face-to-face connection with them. We don't have that personal face-to-face relationship, if you would, and making sure that that comes across in everything that we do is critical. You can go into the whole conversation about how do you have an upstream community participate in a scrum team when all the ceremonies are internal and all that kind of stuff. I can go into those details. It's super easy. Invite your community to them, right, and ask them to participate that there's not there isn't magic there. But I think that really has to be a wider conversation with that team to decide how do you want to bring them in? Who do you want to bring them in? How do you know who the right people are? How do you make sure that that community isn't going to send like an army of a thousand people to this meeting? And only one of those people are really the people that your opinion is the one that you should listen to. Like I said, Lee Griffin's talk, I'll put the link to it and chat if actually if I could ask an organizer to dig it up and put the link in that would be great. But but he had some really great advice and I would hate to steal his thunder. So I would recommend that you watch his talk. Any other comments, Brendan? Do you have anything you'd like to add? I don't think I can add to that. Fair, fair enough. All right, moving on. This one is directly for Brendan. What has been a few of your biggest lessons learned from your last two years working with the rail team? I'm not sure where to start. There's only one of me and there are hundreds and thousands of them. So it's important to empower people to do the work on their own instead of being an interface for them. Probably a good one. Also, it's always more complex than I think it is. And where process is concerned, everybody wants to make it more complex than it has to be. To the maximum extent possible, we want to make things very short, very concise and very intuitive. A lot of the time, people will invent processes for themselves and their team. And they'll be this very elaborate and constrictive thing. And they kind of forget the difference between what they're trying to get to and how they're trying to get there and they end up designing a very elaborate thing that it's not recyclable and then they're very unhappy because they try to go through all the steps and then they lose heart because they never can get through it. And the thing they had in mind that one time worked and then they try to do it again and it doesn't work anymore. So simplicity and recovery, recognizing when things aren't working and reinventing the wheel as often as needed to suit is probably the first time you did it. It was not the best that could have been done. Awesome, thanks, Brendan. All right, next question from Hina. How do you find the balance between making a decision and continuing to gather feedback? Sometimes this feels like keeping ideas open for feedback can go on forever and limit moving forward. Who would like to take a stab at that one? All right, Mr. Prophet. So I've actually been doing some training about this all week. So it's fresh on my mind. So at Red Hat, what we do internally and also we try to do this with the projects that we steward, we use a technique called open management practices and also related to that, the open decision framework. And I won't really go into that because it's huge, but the gist of it is that you let as many people participate in decisions as is reasonable and have as much collaboration as you can. But as a manager, you also can't let that link what you describe as the endless feedback loop or bike shedding or whatever you want to call it. You can't let that go on. So the way around that is what we do is we try to set boundaries on the decision and those boundaries might be, we have X amount of time, we have X amount of budget. These are the constraints with which we have to make a decision. And so you listen to ideas, you move towards or away from ideas. But at the end of the day, you've set up a boundary that says, okay, but by this time, we have to have a decision made. And so that's how you sort of, and you could do this in an open source project too. You just define the limits of the discussion and then go from there. Some teams in Red Hat also use what's called the RACI model. So the R is you define one person who is responsible and has to ultimately make the decision and the A is other folks who may be accountable for that decision, but one person has to be responsible. And then the C and the I are people who are consulted and informed that larger stakeholder community who should be consulted, who should be informed, who should be a part of it, but who do not ultimately have to make the choice. And I think it's also important to remember that consensus does not mean unanimous agreement. So just because everyone doesn't have the same opinion doesn't mean that you don't have to eventually put a stake in something and move along. I love that, Ruth, because we use that internally in the REL team. We say we don't need consensus. We don't need everybody to say, yes, we need consent, meaning who actually owns this decision and are you going to actually allow them to make it because that is their area of expertise. And it's been quite a learning journey for folks internally to really know the difference between those two ideas, really. I just want to plus one what Brian said, because so often we fall in with ideas and the pursuit of the perfect plan and whatnot. It's like, no, there have to be constraints. There has to be a time limit. There has to be something that causes you to say, OK, this is what we're going to do. And even if it's not perfect, it's what we're going to do, at least for now. We can revisit it later. But without constraints, it actually stifles creativity. Having constraints makes people creative and it gets you to a decision in the end. So it's very important. How do you, Brendan, elaborate on the how do you limit, like when do you know to cut off? You just give them a time window? Maybe. I mean, so let's say you're a co-equal member of a community and you want to do something different in the community and you need the community consent and say, OK, I want to do this, but I can only do it if we can reach a decision by this point in time. And then if that point is reached and we can't get to an agreement, like, well, I guess I won't do this and I won't participate. So there's a little bit of a give and take dynamic here because it's not like you can force community members to do things, but you can definitely say, I'm going to put my energy into this if you'll do it with me and I'm not going to put my energy into this if you won't do it with me. And so the choice is yours. Fair. All right. Next question. This is for Brian B. I'm not going to try to pronounce your last name, Brian, because I think I know how to, but I don't want to make the mistake, right? To me, there are dangers with relying on meritocracy with sometimes being about people rather than making sure the best idea services. What advice do you have? Wow, okay. Got the heavy hitter. I got the heavy one. No, that's great. I really appreciate the question, honestly, because meritocracy is one of the most fascinating concepts to me in open source, open source culture. In fact, just an hour ago, I was reading a new book on meritocracy and I have another one downstairs. I've written about meritocracy as a concept and from a historical perspective for opensource.com and I love talking about it, so I really appreciate the question. So at the core of meritocracy or popular deployments of meritocracy, we'll say are two fundamental ideas that are always in tension. One is that the best ideas can, should always win and the best ideas come from anywhere, right? So again, in open source communities and in open organizations, you often hear that sentiment. The best idea should win regardless of where it came from and the idea that solves the problem best solves it for the most people and solves it in the most effective or elegant way should win. And then that's also put up against another sort of maximum meritocratic maxim which is those who do the work, those who have the longest history of demonstrating contribution should have more say, right? Those who have accrued the most merit, in other words, should be able to make the decisions, right? And so in order to have a say in a process, you need to demonstrate a history of successful contribution. Because for the former to be true, the best ideas can come from anywhere and it shouldn't matter who you are. That means it shouldn't matter how many decisions you've made or not made or how many of your ideas have worked in the past. You should have a fair shot every time. And the opposite is true, right? If you have a history of demonstrated contribution in an open source community or an open source project, your idea should matter more, right? So you have these two competing maxims, meritocratic maxims, in any governance model that's predicated on meritocracy as a guiding principle. So you have to figure out in your project how you're going to negotiate those, right? And every project is different. Every project negotiates that tension differently. But your question was specifically about the focus on ideas as opposed to people. And that is, I think, the tension, right? That is the tension where you have people who have accrued merit over the years and those folks have a louder voice, right? When Linus Borwald speaks, things happen in ways that do not happen when other people speak. And also the focus on ideas, right? The notion that the best idea should not be the loudest idea, the most tenured idea, the most senior idea, the idea that's higher up is the highest up in the hierarchy, right? So you have to figure out in your project how you're going to negotiate those tensions. I don't have the magic formula, unfortunately. If so, I wouldn't be on this call. I'd be writing the next book on meritocracy. But I leave you with that tension as a framework to think through as you explore that with your own project. It also means that you have to divine when someone says on a mailing list, this project is a meritocracy, which version of that word they mean, which end of that spectrum they think the project is working on. A great point. It also means that you have to have a psychologically safe project and community because it might be that only the best, most meritous idea that somebody has expressed is out there and people don't feel safe to put out an opposing view. So there's that second dynamic of creating a space where people actually will bring out their best. Jen, your audio is gone again. You have to wash your mic again. Seriously? There it is. Oh, it's bad. Thank you. Don't say anything bad. I'm not going to. I was going to, but I'm not going to. So Hina asks, do you run into occasions where community members try to go their way regardless of the decision that was made? And I'm assuming there's probably a follow-up on that, which is like the whispered, what should we do about it? I believe we already covered forks. Yeah, I mean, we kind of did. I mean, it's going to be a fork. And as Brennan said, sometimes you just have to say, if you're not going to put the energy into this, then, yeah, that's what you're going to do. It's unfortunate, but it happens. All right. What do you do if the loudest ideas always the same that gets the most attention? How do you give the silent, but brilliant people a voice? On those open management practices that I mentioned earlier, one of the things that you do is you do try to get everybody's opinion. Because yes, when you're in a room, there's always going to be the person who's going to jump in and speak up first. They're going to be the loudest. And so when that happens, you have to kind of eyeball the room real or virtual and say, okay, well, who's being quiet and make sure that you asked for and solicited their opinion as well. And you have to work at that. Somebody actually has to do that work and try to draw that out. And that can be hard because people have different, there's different neurodiversities. There's introversion versus extroversion. There's a whole bunch of things in there. So that's part of the process that a community architect has to do is to sort of gather everybody's opinion and make sure everybody has a voice. And on the subject of different comfort levels. Go ahead, Ruth. Go for it. I'm meeting. I would just add to that, from a project management perspective or from an open source community management perspective, the trick is to ensure that your project offers multiple modes of feedback, multiple channels for feedback in multiple media or multiple modes. That means accommodating people who might not speak up on the community call, the synchronous community call, but who are typists and love to sit down and think through stuff. That means having a live chat of option available to folks who might not be the best typist or for whom English might not be their first language or the project's dominant language might not be their first language. And so they're not gonna be able to write their feedback as well as they'll be able to express it to you face to face. So the trick is to create a project, create a team, create an environment where feedback can come through a variety of channels. And it also means tailoring your decision-making process processes to accommodating those channels, right? Making sure that if you're gonna render a decision that you leave enough time for people to think who are processors who like to type up notes and come back to you with a brief, not demand decisions be made immediately, but also open up enough of the channel, open up enough of the space that folks can have a lively debate and come do an agreement at the end of that debate if they need to, right? So historically, we've seen the most successful projects that are best at recruiting the best ideas are the ones that have multiple channels for multiple modes of feedback. Yeah, the best story I have for that is when I was a Scrum Master for a team like many, many years ago, the team was all in the room and five out of six of the engineers were all very comfortable with talking out loud or thinking out loud, if you would. And one of them definitely did not think out loud. And we were talking about a direction we wanted to go from an architecture perspective and the five engineers were all collaborating and all collaborating. And when they turned to get feedback from that sixth engineer, he was completely in his own head thinking about the first question and they had already gone forward in the conversation like 30 minutes. And he had missed most of what they were talking about because he was like, well, okay, the message bus, if we choose this one, and he was going through this like, oh, and this is the implication and the server over here, oh yeah, I forgot that I didn't update the configuration setting over there. And the way he was thinking was so far away from where the other people were thinking that by the time they kind of tried to coalesce, he had no idea what was going on. And so another thing that I think is really important is to make sure that those loud forward pushing thinkers, especially if you're in a face-to-face meeting or like a conversation, make sure everybody's along for the ride and constantly check in with people. You can do check-in statements like, I think I heard this, are we all on the same page or what am I missing or have I restated that incorrectly to kind of put a flag in a meeting to say, okay, we need to make sure everybody is all on the same page? That's all. Or even I've heard from the same five voices for the last half hour, I need to hear from three new voices before we move on. Yeah, I also do a little prep work, especially for some of the, apparently, if you all saw me laughing earlier is because Carson was saying something very funny in chat and I couldn't keep my laughter contained. But if you are struggling with individuals and you know they're gonna be in your meeting, maybe you should have a conversation with them before they get to the meeting about making space for others. And in some cases, even at Red Hat, I will call people out right directly, especially if I know that they're doing it and they know that they're doing it. Get permission from them first, but there are a couple of people at Red Hat that I will always interrupt and say phrases like, let's make room for others right there in the meeting because they're okay with it and I need to give them a clue. And so I think it's really important that you do that. And I think it's also really important that you set the intent before you do it because if you're gonna do it, some people might feel like it's a smack. So make sure they understand what the intent is by doing those types of activities before you do them. Okay, I think the next question is, how do you make people in open source draw pictures instead of writing a man page? And I think there is an elaboration in there which also says, I find that in open source experience, people are used to doing work through PRs, obviously, which are very text based, but some of us are visual learners and it's hard to draw. How do you make open source folks draw pictures? I'll say I've written man pages before and that language is freaking awful. So I would rather draw a picture. I mean, this is something that I used to work on when I was working with publishing way back when you would make a book that would be very text heavy. And then you would also make books on the exact same technology that had pictures and easy step by step. So, yes, there are different learning modalities for people depending on how they're coming towards it. I would say this is tricky because when I first read the question, I thought this is a question about how do we find things in a community that aren't necessarily developer oriented? And we have this discussion all the time in our open source program office. We don't say that a community is full of developers. We say a community is full of contributors because there are different ways to participate. But I get the sense it's not what Neil is asking. So I don't know. It's a hard question to answer without maybe a specific example or understanding exactly what the problem is. I will say I can offer an anecdote. I've at least encouraged people to give visual diagrams with an example. When I used to do a talk on the Raspberry Pi, I would tell people, I don't care how you share what you did as long as you share. And my example was this wiring diagram I found on the internet that was clearly a photo somebody took of their scribbles on a cocktail napkin. But it had all the information I needed. So good enough for me. I think this really speaks to the importance of having a diverse and heterogeneous mix of people working on your project and understanding that the value of a contribution a valuable contribution comes in many forms. There's nothing necessarily stopping a project from embedding, for example, a YouTube link to its project and a whiteboard a video of a whiteboard explanation of how it's project how the project works in the read me file on GitHub, right? Or in the read me file that somebody downloads from whatever forge you're using. Like there's I mean, it's the question was, how do you make people do it? I don't think you can make you can make anybody do it. But I think what you can do is as a project lead you can recognize the limits of your own biases in terms of media types, right? You know, we address this a lot in our upstream community when we're working with not just pictures and video and not just picture and video, but sound. You know, I mean, people like to record their audio clips of an explanation of a concept rather than write it down. So how is your project going to accommodate people with different, you know, accessibility needs, really, and different preferences? That's a great answer, Brian. We are almost out of time. We have about three minutes left. And I would like to ask everybody to using, I think it's something like probably a hundred years of combined experience between the presenters here. What is one tip that you'd want somebody to know? It could be really anything. And I know Ruth has a really great one. So I'm going to pick on her first. No, I'm not going first because I'm actually going to make it relevant. So somebody else. Okay, fair enough. But I was chuckling because I was warning the presenters in a chat channel and Ruth's tip in the chat was, always brown your butter before making cookies, which I agree with. And so she'll come back in a second. But maybe I could ask Brendan, what is one tip you'd like to share with everyone? Oh, goodness. Whatever the thing is that you want to do, just go for it. The more enthusiasm you bring, the more you want to do it, the more valuable, the more important it is that you just do that. You will regret not doing things. So the things that you desire the most, go for them. And where community is concerned, that enthusiasm, it looks like leadership. And the things that you are the most enthusiastic about are the things that other people will also become enthusiastic about. So go for it, share it, and people will band behind you, support you, or give you something even better to do. All right. How about Brian Prophet? So the thing that I tell people if you are participating in a project or you are an active voice in a project in open source, is to try to make your onboarding as simple as possible. And we have three tenants for this. What does the project do? How do you use the project? And where do you find the project? Those three basic things, if you can do that on your website or your GitHub page, or wherever you talk to people. If you can solve those three things, you've gone a long way than a lot of even current legacy open source projects have done. So there you go. That's a really great tip. I oftentimes have wished for that for certain projects. All right, Brian B, you're up. I would say probably just one of my favorite reminders is that in an open source project, as with most things in life, but especially in an open source project or in a community, everyone is only as strong as they empower each other to be. And so you are only as good as you enable others to be. And so I would say that as you act in a community, as you build something, as you contribute something, as you tweak something, as you offer something, remember that the spirit of mutual growth is what should guide you and that the spirit of lifting others up is what should guide you and that when you make a contribution, the goal of a contribution should not just be to fix a bug for yourself or as folks say, scratch your own itch, which is of course important. But also you should be asking, how is this going to make something better for someone else? And how is what I'm doing empowering others to do better work in the future? Awesome. Thank you, Brian. All right, Ruiz, go for it. First of all, I love that it's six o'clock on Friday. Brendan's laptop says, no, we're done here and leaves. It just kind of logged them right off. So great. To make my tongue in cheek brown your butter for your cookies, comment, actually relevant. There is a metaphor we use to explain this whole open source goodness thing, which is that if you make a batch of cookies for your friends, that's awesome. Your friends get to enjoy those cookies once. But if you give them the recipe for your cookies, then they can enjoy them anytime and they can make them their own. They can add some chocolate chips. They can make them sweeter. They can do their own thing to make their cookies better. So here is our open source cookie recipe. And all of you can go brown your butter and make cookies. And if you are like me and hate peanut butter, you can send me an email at Ruth at redhat.com and I will hook you up with better cookie recipes. But if you like peanut butter cookies, that's our cookie recipe. I'm wildly allergic to peanuts. So I'll have to email you, Ruth. I'm going to do that very shortly. So my tip, and then we're done, is do not forget to continuously improve. And it has to apply to everything in your projects. It has to apply to everything in your personal life, work. Just don't forget that that's a part of life, that feedback loop. They constantly saying, hey, what can we do better together as a community? Gosh, the types of ideas that come out of those types of conversations have always been super positive for me. So I just look forward to communities participating in those types of activities more and more. And with that, I think we are done. So I want to thank everybody for coming. And I think this actually wraps up the official sessions for DevConf, but there is a final session that I believe there are some fun things that are going to happen. I hear in the polls that there's comedy involved. There might be some comedy. I heard that I tried to give the organizers some pictures of me from middle school, but they said, no, thank you. That's not comedy. I think it's funny, but they didn't. So thank you all very much. That was a very interesting discussion. And it made it very easy as a moderator. Just step back and listen. Thank you. All right, everybody. Thanks. Peace out. Go make cookies.