 up in the Alaska Inside Passage, which I thought was really awesome. It's a beautiful country out here. So, hello everyone. Thanks for coming to Seven Habits of Highly Effective Contributors. I am Adrian Otto. I am a Racker. I serve at Rackspace as a Distinguished Architect. I am the chair of the OpenStack Containers Team, which was the precursor to the Magnum Project, which we'll be hearing more about during this conference. I also started the Solum Project back in 2013, and I work on cloud standards. So I have a unique perspective of how OpenStack works. I've been involved ever since the very first design summit in Austin, Texas. I was one of those 75 that were there at the very beginning talking about how to put a pluggable scheduler into NOVA. So I've had the joy and excitement of working with OpenStack for a really long time, and have had the joy of starting two projects in this ecosystem and figured out kind of what works and what doesn't work from a how do you start a project perspective? But also, I've seen a lot of contributors and figured out what works well and what does not work well. So I'm here today to tell you if you wanna be an awesome contributor, there is a formula. So this is my money-back guarantee formula for becoming an awesome contributor in the OpenStack ecosystem. Now, first you gotta recognize, probably half of this room is new, like first time to a summit, how many? Two thirds of the room. Okay, and who has not yet contributed to OpenStack? About half the room. Okay, so you've gotta understand about OpenStack and how it's different. So I'll talk a little bit about the four opens. Everybody understands what OpenSource is. That's a given in today's world. When you take OpenSource to the next level and you start putting your code repositories in things like GitHub so that they're available for people to see your Git commit history, that's called Open Development. You might take a pull request. You might interact with the community a little bit. But that's not enough. You need to go a step further than that and do Open Design, which is what we're doing here at the Design Summit. So we get together as a community, face to face, sit down, figure out how we're gonna design stuff, plan things out. And we do this on a six month interval and we started doing, about a year back, we started doing something called mid-cycle meetups. And I'll talk about mid-cycle meetups a bit as well. So these are kind of like halfway between the Design Summits, each project gets together on its own. And this is unique to this Open Design concept. And if you're doing the Open Design concept, what results from that is Open Community, where you can have not only all of that stuff happening, but also the governance of your projects can be driven by the community as well. So as a PTL in an OpenStack project, I'm elected to lead the project. And if I'm not doing a good job, somebody else can replace me. Code gets into OpenStack by using a voting scheme. So when you submit a contribution, you use a tool called Garrett in order to put your code up into the review. Once it's up in for review, your co-contributors will look at that source code, potentially comment on it, and vote on it. There are two classes of votes. There's the general class of voting where you can vote with a plus one, meaning you think that that code should go in. You can vote with a minus one, indicating that the code should not go in and that additional revisions are necessary, or you can just make a comment with a zero vote to ask a question or to just indicate that you need clarity on something in order to make a decision how to vote on something. And then there's a second class of voting which core reviewers do. They can vote also again with plus one, zero or negative one, but they can also vote plus two or negative two. And I'll talk about those a little bit more in a bit because the minus two vote is a special one. But two core contributors need to vote for something in order for you to approve a merge. So you can't just be a core committer and put source code into open stack. You need to have your code reviewed and two other core reviewers need to agree that that's good software for it to go in. Core reviewers are elected again by the contributors of the project. They vote on who will be added or subtracted as a core viewer. We design, like I mentioned here at the summit and the mid-cycle events and the governance is handled by the technical committee. So all projects that are in open stack as in the projects.yaml file for the open stack project list have a PTL election that is held on a release by release basis. So every six months there's an election. There's a single election and you vote for all your PTLs. And if you've contributed to a project you can vote for the PTL of that project. We also have a board of directors in open stack and they handle the business side of the foundation. Things like the legal aspects of using the trademarks and the high level non-technical aspects of running a foundation. So how do things really happen? So everybody here probably understands the agile development process. The open source development process in just about every open source project I have ever seen is not an agile development process if you're using open design and open community. They are incompatible. So I wanna highlight how these things are different so that you understand why the formula is effective. So first of all, there are no sprints. We use a release technique called a release train. So the clock moves forward and as features get done they get included in releases. So releases are tied only to dates not to feature readiness. So in order for this to work your software has to always be shippable. We also have no card wall. Instead we use a tool called Blueprints which are part of Launchpad to indicate what features we're working on and sometimes we'll use bug tickets to indicate what tasks we're gonna be working on. There is no project manager or scrum master. The only leader we have in an open stack project is the PTL and the PTL will work together with the core reviewers to decide what gets in and as a community you will decide how things get built but there's no, like in an agile process you would have a project manager who would have basically veto power over what things get prioritized and why and that concept is completely absent from what we do here. There's no release manager for an individual project. There is, we have a thing called an integrated release in open stack where we have the 12 projects that are considered part of the integrated release and we kind of test them and release them together and there is a release manager for that but each individual project doesn't have a release manager. So understanding that, where does influence come from? How do you actually get what you want to happen? So the technical committee is this group, so I said there was a board of directors, there's a technical committee and then there's all the individual projects. The technical committee decides when new projects get added and what indications those projects have, what tags are allocated to them but the core reviewers are the ones that decide what the software actually ends up being because they're the ones that are voting on every single contribution that comes in and they as a core reviewer have the ability to essentially veto a contribution by giving it a negative two vote so that it can actually not be merged. PTLs have the power to approve or reject blueprints. So if you have a feature that you want to get into a project, you can propose it as a blueprint and that can be discussed by the team in either an IRC meeting or at one of the meetups and it can be approved for both its direction and for its design independently. So typically the PTL will approve a feature, a blueprint by setting its direction and then whoever proposed the feature or whoever likes the feature and wants to work on it they come up with a design proposal that's submitted as an attachment to the blueprint and then the blueprint gets approved based on its design. So these things have a life cycle where you can control what you're working on and how it's prioritized and what releases they're tied to. Okay, so one way to get your new feature in or your change in is to go through a blueprint process. Some of the larger project like NOVA have a spec process. A spec is a kind of a contribution that you make where you put essentially a text file in a very specific format that indicates what it is at a high level that you want to do. Another way to do it is you actually skip the spec writing process and just write a patch. So if the thing you want to change is really small, you can just write a patch and throw it up for review and tie it back to either a bug or an existing blueprint. If there is no existing bug or blueprint you can actually create your own bugs and link them in your commit back to the bug. So when you submit your, when you write your code and you do your git commit and you're writing your commit log entry, the last line of your commit log entry can be closes dash bug colon and a number. Okay, and if you do that your commit when it goes up for review will be linked to the bug. So you can put the actual feature in the bug. And the reason why that's important is because when the ptl goes to tag a release you'll get credit for that contribution. It'll be listed in the release notes. So the fastest way to get code in is just to submit a patch, have the core viewers vote on it and if it's small enough it'll get in. But if what you want to do is really involved that's pretty risky because it's likely to get kicked back as a minus two does not fit in which case you're either throwing it out or starting over. So if it's little thing just put it up and see what happens. If it's gonna be a big thing you probably wanna make a blueprint, you probably wanna make a spec, you probably wanna discuss it with the team first, get a collaborative indication that this is the direction the project really wants to go and then start making iterative progress towards that. Okay, so I mentioned the negative two vote a couple of times. So this is a special thing. Why don't I have you guys come in? There's seats open up in the front. A negative two is a special kind of a vote. So any core viewer can vote negative two on your patch. If that happens that vote will stay even if you revise the patch. So normally if there's a minus one on a review and you submit a revision that you changed whatever somebody asked you to change and you put a revision up, all the negative ones get erased and you get a clean slate and you start over. If there's a negative two on there, it's sticky. So even if you do a revision, it doesn't get cleared out. And the only one who can take a negative two vote off is the one who put it on. So this is something that we tend to use very occasionally and it only really is appropriate in cases where somebody has contributed something without talking to anybody and it really doesn't make any sense or there's a serious security vulnerability that a particular reviewer wants to be sure we address or we know that this is gonna break something because there are other things coming behind it. Those are the reasons why we might wanna use a negative two. All right, so you all came to hear money back guaranteed formula and I'm gonna give it to you right now. So the first is you need to be on IRC. Every project in the OpenStack ecosystem has an IRC channel. The IRC channels are logged and they are where you have all of your ongoing discussion, where your team actually collects. So make sure that your computer is set up so that when you turn it on, it connects automatically to IRC, it automatically puts you into your IRC channel and you're idling there all the time. And so if somebody doesn't mention of you in the channel, that's their way of kind of calling you up and saying, hey, we need your attention. So your chat client is how people are going to interact with you. We really don't use a lot of email back and forth individually between contributors. We do have the developer's mailing list and each project has a, I'll talk about that in a sec, but we don't have like a one-to-one communication outside of IRC. IRC in the channel is where you should do all your discussion about your projects. Second, every team in OpenStack, which includes every project in OpenStack has a regularly recurring meeting, typically these happen on a weekly interval. You need to show up to these meetings religiously every single time and you need to be present. When you start the meeting, we start a thing called Meetbot, which is something that logs and takes, like helps us keep the minutes essentially for the meeting because everyone is logged and archived. If you say one line, if you just type one thing in IRC during the meeting, you will be recorded as an attendee. So that's the minimum. Show up and just put one line that you attended that meeting, but don't just do that. You have to really pay attention to what's going on so that you have an idea of what is changing in that project. That is your most up-to-date, reliable way to learn what's happening. All the announcements are gonna be happening there. All of the discussion, if you have patches that require team discussion, that's where the discussion is gonna happen and on a formal basis. So definitely, definitely attend these meetings regularly and treat it as a priority. Don't like block this stuff, block that time out on your calendar so that nobody's interrupting you during this time. Third, use the mailing list. So you've gotta read the mailing list, particularly any project that you're involved with has gonna have a topic tag. A topic tag is like in brackets the name of your project. So openstack-dev at lists.openstack.org is the email address that we all share. And everybody has access to everybody else's email that's sent and received on this list. But how you can filter it so that you can only subscribe to a certain topic. So for example, if I don't wanna read 50 emails a day from OpenStack mailing list, I might only wanna read the two or three that are my project. Then I would set up a filter in my mailman configuration when I subscribe to the mailing list so that I only see stuff about Magnum and Solum and Keystone and other things that I happen to be working on right now. But I might wanna ignore things that are going on in the other projects. Another thing I will do is set up a filter of like things to accept. So rather than using the filtering feature entirely in mailman, I'll get all the messages but I'll do my own filtering and I'm saying if the topic tag is Magnum or Solum or whatever, then leave that in my inbox. Or if it has the keyword, this word or that word or this word or that word, then keep it in my inbox. Otherwise, go ahead and filter that out. So that's the filtering strategy that I've used pretty successfully. Participate on each thread that goes out. If you have something meaningful to say, don't just think it to yourself. Make sure that you make a reply on there and that you get that recorded. If somebody's asking questions on the mailing list, take some time to answer those. Be present. And keep in mind that, I took a poll here. We've got people from four different continents at least here in this room. Not all of us have English as the first language. Some of us struggle in order to communicate in this language and that can be very apparent in stuff that's going up on our developer mailing lists. Keep that in mind that these are not native English speakers and take the time that it requires to understand what they're actually talking about rather than dismissing them because of language barriers. Okay, fourth is do code reviews. Every single day, make some time to look at your review queue for your project or your projects. It doesn't have to be a ton of time. It doesn't have to be two hours a day. It can be 10 minutes a day. Whatever it is, allocate some time where you look at reviews every day. And the reason for this is not just so that you're helping do the voting and indicate what should be merged or not merged. Part of the reason why is because you're gonna become a better programmer by seeing what all these other awesome developers are doing. Another reason why is you're gonna know if you're actually reading the full review queue every single day, you're gonna see almost everything that goes into the project. So you'll have a very, very acute picture in your mind of the current state of the code because you know what's going on in that code because you've been seeing every single commit that's going through. For me, doing reviews for two projects that have maybe 4,000 commits or 4,000 patch sets combined, I've probably reviewed half of them in doing this an hour to two a day as a PTO. So I would think if you could allocate 30 minutes a day maybe to do code reviews, that would be huge. And this is how you, I talk about influence, right? What's the formula for influence? You have to be participating in the project. People need to know your name. You need to be in the IRC channel. You need to be on the mailing list. You need to be present in code reviews and be, I haven't even got to contribution yet. We're just talking about reviewing other people's code and voting and making meaningful indications of how that code can be improved. So there's this like, when a first time developer comes to OpenStack and he or she submits a patch, they get like this welcome note on their first commit. Like, welcome to OpenStack. Thanks for contributing your first patch. And always the first thing that happens is a negative one vote. Always, I guarantee it. You're never gonna get a like, plus two, plus two, plus A. My code got in. That will not happen. But what will happen is you're gonna get a negative one vote, which does not mean the same thing as if you got a negative one vote on GitHub. We all understand how the GitHub tool chain works and essentially gets down to a go or no go vote. And if it's minus one in GitHub, it means we hate your code and it's not getting it. And if it's plus one, it's like, awesome job. It's getting it. Whereas here in OpenStack, a negative one just means we just wanna see more from you as a revision to this patch. So don't see it as a negative. See it as an opportunity to make your commit fit the style and expectations of the team that you're working with. So you will get a negative one. You'll get another negative one. You'll get another negative one. Most new contributors go through about four or five revisions on a single patch set, even a trivial patch set before it's gonna be merged. That's normal. And if you're doing code reviews, like I say, then only take a day or two to get your code in. When somebody votes on your code, you're gonna get an email from Garrett saying what the vote is. Look at that stuff right away and be sure to follow it all up. Okay, I talked about being constructive. So if you're a reviewer, your job is not just to do plus one, plus one, plus one. A plus one vote with no comment, if you didn't actually read all the code and really understand what it's doing, has no value at all. Don't do that. Don't just vote plus one on something. That is not involving you in the community. Vote negative one with a thoughtful suggestion for how this can be improved. If it's trivia, fine, skip the negative one, right? But if you find a meaningful way to improve the code, go ahead and vote negative one on it and suggest what should be changed. Even if you see plus two votes on something and you're just a regular fly by guy, that's fine. But if you've got a good suggestion, go ahead and negative one vote it. Don't worry about contradicting the other team members. If you're actually an idiot, then we will ignore you and immerse your stuff anyway. Don't worry. Go ahead and make those things. So your job as a reviewer is to make the code better, to get it in as quick, to help your contributors, your team get code through as fast as possible. And you do that by making constructive votes. And again, same with the email list, right? Keep an open mind. People's code has sometimes comments in it, error messages don't make any sense because they were translated from Russian or whatever, right? So, is that me? Oh my gosh. It is not. It's you. Okay, bug tickets. So I talked about bug tickets a little bit. So, bug tickets are not necessarily defects. A bug ticket is something that needs to be worked on. It is a task level thing. That is me that time. Geez, I'm gonna turn it off. So, it is a task level thing that needs to be done. So I talked about blueprints earlier. Blueprints are for features, like big, hunky things that need to be done. A bug ticket is for something trivial. Usually I use bug tickets to track things like technical debt. Like, yeah, we're gonna merge this code. Like, say I'm reviewing some code and I see something that I don't really like about it, but I really want this code to get in. And we need to move on. But I'm willing to take on some technical debt. So what I'll do in that point is I'll say, okay, I'm gonna vote plus one on this patch. I'm gonna vote plus two on this patch. But I'm gonna open a bug ticket against it that is tagged as tech debt. That says, I would really like somebody to fix this so that it has better error handling in this case. Or I would really like it if it were re-implemented in this other way. And it's fine that I have this as a first iteration of the contribution, but I would like it to be better in this other way. So a bug ticket can be used for that. A bug might be marked as a defect with a severity level or it might be marked as something called a wish list. So if it's a wish list thing and it's got a tag on it for tech debt, that's great. Because new contributors, like half of this room will have somewhere to go to look for things that are relatively easy to do where they can just start making an impact right away. So use bug tickets. When you make a commit, always try to tie your commit to something. Tie it to a blueprint by using the word blueprint and its name in the commit message or use closes-bug colon space number. And you're either linked to a bug or you're linked to a blueprint for every single commit. If you do that, all of your contributions will be tracked and it'll be getting credit for it and it'll be very easy to indicate to whoever you're reporting back to what you're actually doing. So it makes it very easy to quantify your contributions if all of them are linked in this way. If you just have something coming out of left field and you make a patch for it and it's not linked back to anything, chances are people are gonna ask you, what is this? So don't do that. So you can open a bug ticket and link it and that whole process takes about 45 seconds. You do not need to wait for a bug to be triaged in order to link it to your commit. Number six, use blueprints. So when you have an idea for a feature, you open a blueprint, a blueprint has a title, it has a description, it has a place to tie like a specification document and it has like some workflow stuff. What its approval status is, whether it's in discussion, whether it's what state of implementation it's in, all this sort of stuff is in the blueprint. So you can open one. You don't need to be a project admin of any kind or open a blueprint, you can go ahead and open it. You can indicate who the approver is so you can set that yourself. Best practice there is just to put the name, the launchpad name of the PTL in the approver field and when you do that the PTL is gonna get an email in his inbox or her inbox and it's gonna say, there's a new blueprint so that's the way that you kind of indicate them that it's there and then you would go into your agenda for your IRC meetings. So back in, like number one of the seven habits was use IRC, right? Number two was attend the meetings. So if you're attending the meetings, the agenda for every team meeting in OpenStack is published on the web in advance and it's on the wiki so anybody can update the agenda. And most project leaders are very liberal about what they allow on the agenda. So you can actually go into the agenda and put your item, there's usually a whole section in the agenda for where you put your item in order to work on it. And once you get that on the agenda for the IRC team meeting, you've got your blueprint, you've got like some discussion about how you wanna do something and why and then the team meeting comes up, you get on IRC, you make your case, everybody talks about it and the PTL either approves it or tells you, let's go a different direction and here's how, all right. You can also go into blueprints and find stuff to do. So I told you about bugs, right? Bugs are a good place for new contributors to go and find stuff to work on. Blueprints are another place to go. So if you really have figured out the contribution process and now you wanna start developing new code, this is how you do it. You go into the blueprints, you can set the assignee to yourself. One thing that's important about this, okay. When somebody owns a blueprint, it does not mean nobody else is allowed to work on it. It means that person who owns the blueprint is responsible for reporting back to the contributors at the team meetings about the status of that item. You might have four or five people working on the same blueprint at the same time, different patches that are associated with the same blueprint at the same time. They're not all gonna be marked as the owner. One of them is gonna be marked as the owner. The one who's marked as the owner just needs to see that that feature gets done. He or she does not need to do all the work, okay. Number seven, write code and consistently write code. Your code does not need to be Python code. It does not need to be Go code. It can be as simple as documentation that improves the setup instructions for the software. Those kinds of contributions, in my opinion, are equally valuable to a new, I don't know, refactoring the plug-in mechanism for your backend software. It can be in the form of testing. So if you wanna use the software in a new and exciting way and nobody's using it that way yet, go try it and report back what you found from it. Put that result on the mailing list. Have a discussion about it. That is a way to contribute that is not measured in terms of commits, but it's equally valuable. All right, and you wanna have your commits rolling on a regular basis. So the best OpenStack contributors that who I have ever seen make at least one commit every single day. Might not be a major thing, but it's just one thing. He or she will pick out a bug, do a quick fix, get it up. So there's always maybe four or five things, depending how fast these things are actually merging. You always have a few patches in flight at any given time. And this works if you are a full-time, like all the time your job is to do upstream open-source development work, you can afford to do this every single day and have lots and lots of patches. If you are only doing this part-time in your free cycles, then you can't do a patch every day, but you could do a patch say every week. But fix a goal for yourself where you're doing this on a regular cadence, not just one contribution and I'm done, but measured continued contributions. Now, I already talked about linking about patch size. So there is an ideal patch size. If you go off and develop a feature and it's 10,000 lines of code and you contribute it across seven different patches, I guarantee you're gonna have problems. Because that code is impossible to review because the patches are just too big, they're too complicated. Instead of going off and working on something and getting it to work and then taking that working thing and barfing it up onto the review, instead of doing that, start your work little by little, small patch by small batch by small patch and have the reviewers take this in bite-sized pieces, ideally 400 lines of change or less per patch. Now, not every change can be done in 400 lines. But that should be your aim. You should be aiming for something relatively small. Why 400 lines? Well, 400 lines is about the amount of code that an ordinary core reviewer or an ordinary reviewer can look at for about 20 minutes. So how many of you are brain surgeons? Any brain surgeons? Okay, well, nobody can tell me that I'm wrong. But there's a system in your brain called the limbic system. This is the lizard brain, the most basic part of your brain. And you've got your frontal lobes, which are doing all of your reasoning. And you have this interruption that happens on about a 20-minute interval where your limbic system wakes you up and is like, is there anyone gonna kill me? Is there anyone gonna eat me? Am I hungry right now? Do I need to reproduce? These are the kinds of questions that your limbic system is asking. And this happens every 20 minutes. So you get this interruption and concentration. Well, so that's why people say, well, we have a short attention span. Our children can only pay attention for 20 minutes. Well, there's a biological reason why they are only paying attention for 20 minutes. Well, 400 lines of code, it's about how much you can review in 20 minutes. So you're gonna get a vote if somebody looks at that patch because they're gonna get through your code. But if your patch is giant, they're gonna get distracted doing something else. We're all busy doing stuff, right? You're gonna get a call in the middle of your presentation. Something is gonna happen that's gonna take you off track and you might not get to the point where you can vote on the patch. So keep the patch small. All right, so let's review the formula. You get an IRC and you stay on it all the time. You show up at the IRC meetings every single week, even if you don't have anything to say, but I hope you do have something to say. Use the mailing list. If somebody has a question, do your best to answer. Review code, try to do it every day. Allocate an amount of time that you can afford every single day to review code. Use the bug tickets, both in creating them to document what needs to be done. What is our technical debt? What are our defects? But also for consuming them, work through bugs to find things to do so that you can be helpful. Use the blueprints when it comes time to build new features and contribute on a regular cadence. If you do these seven things, you will become a core reviewer on your project. It is only a matter of time. And once you're a core reviewer on your project, you will have a whole nother level of influence over where the project goes. Remember I told you the agile development process is different, right? There's a project manager. The project manager basically gets to call the shots on where things go. In open source, the influence is mainly wielded by the core reviewers. So core reviewers are the currency for steering open stack. And this is the formula for becoming a valued member of the team so that you become a core reviewer. If you do this, you're gonna have a say. And you're not gonna be at as high a risk. It's like people when they use open stack, they're like, I got this project, I wanna use it in production, but I'm really worried about the upstream because they might do something that's gonna screw me up in the off side. And I don't have any protection against them doing something insane. Well guess what, you do have protection. If you've built a little bit of karma up and you're doing these behaviors, you have a seat at the table. You are part of the force steering the steering wheel. This is how you get it done. So I'm sure you will have questions. I will take your questions on the subject of what contributors should do in order to maximize their influence in open stack. And also take questions on what project leaders should do and how they should arrange their projects to get maximum impact. Questions? It will be available. I confess I have not uploaded them. So can I give that to you yet? But I will be sure that I at least put it on Slideshare. Slideshare slash Adrian Otto will at least have it. There's probably an official place I'm supposed to put these things. And I don't know, I haven't read that email. Yes. Oh wait, I forgot a very important thing. Can we ask the questions into the mic? Sorry. Okay, is this thing on? Oh good. You were talking earlier about how to link your contributions back to bugs or blueprints or what have you. I figured I would just point out that there is a published document that outlines best practices for commit messages and what they should say and how you link them back. You can find it with some fairly simple googling. Yeah, it's in the open stack wiki. Thanks. They deal with that. Yeah, that's where you get the syntax for doing the linking. Cool. More questions? Sorry, just a single one. When you say earlier when you plus one, you usually have to put a comment on it. When you simply agree with a comment, for example, and it doesn't need any explanation why you're actually plus oneing it. If you're plus oneing, you don't have to comment. But what I'm saying is that's not buying you influence. The goal is how do you become an effective contributor? Simply voting plus one on something is not necessarily making you more valuable. Making a suggestion for how to make something better or how to get it in faster, that's what's gonna make you valuable. So that's the point I was trying to make. Yes, most of the time if I vote plus two on something, I don't write anything. I just, that's okay. But when I'm being helpful and I'm negative one voting something, that's when you have to put the comment in. Never negative one something without actually a helpful comment. Right, okay. More questions? Hurry, yeah. About doing the IRC, I'm kinda curious. I've been doing it a little while now. I'm not, I did it on the court components, so I'm curious in order to mix, and you also mentioned language barrier, why isn't there more use of video conferencing and video chatting? Because we're all offset by time zones. And I realize that, but I'm just thinking that isn't there some way to include a video chat in the process? Our old team did that, now we're trying to move into using this formula, if you will, and we're struggling not having that once in a while being able to do a video chat, it's nicer. There are some committees, like the Def Court committee, who's tried that to some extent, and it has limited utility because, mostly because of the time zone problem, because we've got people who it's two in the morning, so they can get on an IRC, occasionally at two in the morning, but they're not gonna get on a video call. And we literally have contributors in every single time zone in the world, and so it's impossible to find, we'll like alternate our team meetings so that we follow a little bit of daylight and get more people on every other week. But yeah, it's really hard for that reason to find a time when everybody can actually participate. If you just happen to have everyone in one time zone, that works really, really well, or just a couple of relatively close time zones that works pretty well. But I'm not gonna get on a video call late, late night when I've got kids in the house, it's not gonna happen, right? All right, well I think I'm out of time. Thanks everyone for attending. I'll be around for questions for a little bit. Thanks.