 Okay, good afternoon everyone, I'm Nikhil, I am former PTL of Glance and I have experienced mentoring some outreach interns as well as new developers in the project and I've collaborated with new developers who incubated different projects when BigTent was a really big thing in OpenStack and we actually had two decently big projects evolved out of Glance and became successful ones, so we'll try to share as much experience based on those historical aspects of OpenStack and share with you guys. Yeah, I'm Brian Ross Mada, I'm the current PTL of Glance, so I've had a lot of experience reviewing code and interacting with developers who want to work on projects, so hopefully you'll all want to submit some patches to Glance by the time we're done today. Alright, let's get started. So first things first is, you know, if I want to contribute to OpenStack, how do I exactly go about doing that, what is the first baby step I need to take, right? You can use different platforms, you must have observed there is an upstream institute, they had a couple of sessions, a couple of days of sessions at the summit and there is a dedicated mentoring platform, then for under-presented as well as women in technology there is a separate program that goes for all of the open source, which is called Outreachy. OpenStack has good history of collaboration there and we have, I think, about a dozen interns or more so far, so that's one thing to look out for if you can join in. And Google Summer of Code is a program that we join on and off depending on how much interest we get and how much Outreachy interns are joining us, so that's one thing that you can potentially target if you have a good project in mind that's definitely welcome. Then Women of OpenStack do have lots of training sessions on contributions, so that's probably the first thing to look out for besides that you can get in touch with any of the developers and then they'll be happy to get you introduced. But what you need to do, we can talk about this in the further slide. So how many people went to the Upstream Institute earlier this week? Just a few. So the advantage of the Upstream Institute is there's some sort of paperwork kind of things you have to do. You have to sign an agreement with the foundation for your code and then you just have to get familiar with the basic processes of using Git to create a local repository so you can fix your patch and then using Git review to upload it so that it'll be reviewed. And so that's why that's useful. And these other projects, so if you only do the Upstream Institute, you can just jump into one of the projects if you're interested, but you won't have a formal mentor. So it'd be up to you to sort of interact with the people and we'll talk about good places to interact in a second. So we will highly recommend starting small, even if you are a champion in different open source project. OpenStack has its own quirks and the best thing is to get yourself a feel of different projects, a feel of the community and individual projects and how people are working there. So you can choose a project or choose different projects, try to jump in and see how things are going there and then you can maybe zoom into one of the projects. Yeah, just pick a project based on your interests. So if you're interested in image cataloging and delivery, glance is a great project to work on. NOVA is pretty enormous, so there's a lot of stuff to do in there. But if you're interested in authorization or authentication stuff, there's Keystone. So there's a lot of projects. Just pick one that matches your interest and then you can find something to work on in there. Yeah, and we do have some libraries that people can work on. It's generally easier to get code into, merge into a library than into a server because just in terms of stability, the server needs to be a little slower in terms of the pipeline. So there's a good documentation available. For developers, I would recommend definitely going through the dev manual and making sure that you're familiar with the agreements and the different kinds of accounts that you're going to need and joining the foundation is mandatory, so that's one thing. There is a special repository so that folks can test out the accounts and the setup. It's a throw away comment, basically, if you commit anything to that. All you basically need to do is just add a line, then do the regular git stuff, put up a review, and then make sure that everything's working. Sometimes people have issues with their proxies, sometimes the SH keys don't work, so stuff like that can be easily figured out with the sandbox environment versus trying to go into a project. And then, right, so all the projects have lists of bugs on Launchpad, so you can go through and see what the bugs are. Some will be enormously complicated, some will be smaller. So page through, find something you're interested in. Key thing is to make sure you assign yourself to the bug, because OpenStack as a whole is so distributed. There are people working in OpenStack 24 hours a day, just in various time zones. So if you don't assign yourself to the bug, somebody else doing the same thing might also sign the bug to them. Well, not to sign the bug, might work on it, and then submit a patch, and then we have duplicate patches, and it's a waste of effort. Yes? Oh, yeah, it's pretty much Python. And you don't get much choice as a bug fixer, because you've got to work with the language that's there. But yeah, there's pretty much exclusively Python code. There has been some movement towards Go in Swift. And then there was one other project that was using something else. But it's pretty much a Python kind of shop. And Python was chosen because it has some nice features, as far as being easily readable. And the idea was that the code's going to be read by lots more people than write it, so that was the main reason for Python. And the community is pretty gung-ho for Python. Right, you have to end, to help you with that, some of the tests that your code has to go through. We'll check for style, check for indentation, check for the imports being proper. So you'll get some assistance that way, also. But yeah, so it's, right, so Python, just if you haven't used it before, I guess there's some good online tutorials. There's what's the one that, learn Python the hard way, or something? There's something called, it's learn Python the hard way, I think. Okay, so that's a good online thing you can just go through real quickly to just sort of brush up on your Python. But yeah, you'll be writing Python if you fix bugs in OpenStack. And maybe bash scripts and stuff like that. That's true, there's some bash scripts. Yeah, and if you work with DevStack, so DevStack. DevStack and some in-project. There's been changing DevStack recently for Terran as a service, but I think it's mostly bash. It's mostly bash and stuff. That sets up DevStack. And that's a place where you might want to contribute. That's another interesting project. And that, I personally tend to focus on the ones that have APIs, because they're the sexy projects. But there's Infra and DevStack. Those are all really important things, because there's a lot of tooling that keeps OpenStack running. So if you're interested in that kind of thing, there's always room to work. And people are always finding bugs in some of the infrastructure. So another good place to work. Yeah, if you're an OpenStack user, you can also try contributing to the SDKs. Like they do have Java SDKs and stuff like that. So maybe we can start with the client and then find your way through the Python code as well. All right? So easy to miss. So please remember, we are a community. We are not an enterprise. So there's a difference that you would find in the culture. You would make friends and then you would just express yourself, if you may, through the code. So pick your interest, what suits you the best. And try to make sure that you have an impact that you love. So starting that, going through that is making sure that you have sort of right orientation for the project. And you sort of meet somebody at the summit, get involved that way. But I guess your first involvement in the project would be at the weekly meeting. So all the projects have weekly meetings. And some of the bigger projects will have subgroup meetings. So at the start of every meeting, there's usually a roll call. So you can just say hi. And then after the meeting, you can go into the channel for the specific project, if you want, and introduce yourself or say hello to somebody. It's a good way to just get known because you're going to rely on people reviewing your code in order for it to get merged. So it's best to try to have some kind of relationship. And also, you'll need some help from people. There'll be weird things that'll come up where somebody who's more experienced can help answer some questions. So, and as Nikhil said, it's community. So we like to see new people show up and take an interest in the projects. Oh, it's on IRC. Yeah, so basically the way it's set up, all the projects have their own IRC channel. So like OpenStack-Glantz for the project we work mostly on. And those, I think all of them now are logged. I don't think there's a choice. So there's a way you can sort of review discussions that have happened out of your time zone, if you need to. But you should also just be aware that they're logged, just so that whatever you say in there is preserved for posterity. And then the meetings will be held, or usually held in one of the OpenStack meeting channels, not in the project channel. And those are also logged. And the transcripts of those, if you just do a Google search for OpenStack meetings, it should take you to the Wiki page that'll have the list of all the meetings, all the channels. Each group tends to handle their agenda slightly differently. Some keep them in the Wiki. Some keep them in etherpads. But the main meetings page should lay out exactly what each project does. So it'll give you the time, where to connect. But it's all in IRC. So everybody's communicating by typing. It's eavesdrop.openstack.org. And you can just find everything on that one page. No, so it's a weird thing. Yeah, it's sort of evolved. There was like an OpenStack meeting. And then there was OpenStack meeting two. And then OpenStack meeting three, and OpenStack meeting four, because there were time conflicts. There is an OpenStack meeting two. That's a weird part. It's an OpenStack meeting all. Right, that's right, though. OK, so to answer your question, no, there's several different channels where it could be. So you really do need to check, because you can't really guess where it's going to be. And one or two of the groups have their own meeting channel. Yeah, operators have their meetings in their own channel, stuff like that. It's a pretty wide-open community with a lot of free spirits. So almost every project, we all sort of observe the same basic tenants, but do things in different ways where it's not essential, and it makes it kind of interesting. I guess to generalize this a little bit more, I would say, we have a common culture. So OpenStack has its own way of doing things, but we don't have a definite system or specifics of how we do things. So you would find that all the meetings happen on IRC, but they don't necessarily happen on the same way or the same amount of time, or how they are logged, or how they are handled, administered, if you may. All right, so coming back to the slides, if you're picking up a bug, just make sure that you are looking at all the metadata on the bug. Like if it's not a two-hole bug, the bug is a couple of years old, it's a good possibility that you won't see that bug anymore. Yeah, some projects are better about closing out old bugs that are no longer applicable than others. Like, clients isn't that good about doing it. I gotta admit. So it's good to just read through the bug real quickly. Make sure you see which release it applies to, because it's applying to, there's some old bugs that were never fixed, that apply to old releases that are out of life, so you don't wanna have to work on one of those. Although you could test to see if it's still relevant. If you're an operator and if you're still seeing the bug, you might wanna test it out on a particular release that you're operating and then comment on the bug saying that you still see the issue and somebody should be able to help you. All right, so the best way to test a bug is to use a DevStack. Well, you could potentially install individual projects by scratch, but it's just so much easier to have a virtual machine that just get blown DevStack and run the script and then you have all the projects running and then you can easily test out. Has anyone here used DevStack before? Okay, yeah, so it's a great tool, I mean, because it just just crank it up, it installs everything for you and you've got a full working OpenStack in your laptop or I tend to use it in a VM so I can just throw it away and it doesn't mess up my laptop, but however you wanna do it, it's a really useful thing and then you have access to all the logs, you can see what's happening with all the, anything you're trying to fix and you can fix the code right there because you'll have it available to you in a Git repository and you can try out your bug tests right in DevStack live. So it's really good for reproducing a bug because sometimes people will file bugs but won't leave complete reports, so it's good to test it out and verify that the behavior they've seen is reproducible before you start trying to fix something. Yeah, just be mindful about the release that you're testing, the bug may be applicable to Mitaka, but not, say, Pyke and you may see responses differently for different releases, so you wanna say this is the release I'm trying testing this out on, the request body as well as the response body and if you have any logs that are super helpful, if you have logs, it's probably a short shot that some reviewer is gonna triage that bug and give you good points on it. Yeah, and with DevStack, you can check out a specific branch if you need to. So if you need to... If you wanna work on them. So it's your own branch or your own branch? Well, that's true. Yeah, I mean, as a start, DevStack is good to start with, but if you're using, so with DevStack it'll set up my SQL, so if you're not using that in production, you might be seeing something different. So it's all, I think our advice is just make sure you can reproduce the bug yourself before you start working on it. So if you've reported it yourself, then you're set, you know exactly what the environment is. But if you're picking up a bug from someone else, it's, I mean, as a start, DevStack's an easy setup where you've got everything available, so that's why it's start there. But also reading through the bug, if they, so for instance, if they're observing it with Postgres or something, then you're not gonna be able to do it in DevStack. It would be something else. Yeah, and if you have a bug that's, that has some missing information that you have found, please add it. Depending on the criticality of the bug, you get karma points on Launchpad, and you can see the activity on Launchpad of who's working on what and stuff like that. So it's just a good way of getting involved. If you're an independent developer, that's one way to get highlighted. And you're also on the bug, you can, the person who filed the bug, we usually get email when people leave comments. So if you can't reproduce it, you can just politely say something, I can't reproduce this, can you give me some more information? Or you could ask if they're still seeing it, because sometimes there are these transient bugs that come and go. So the main thing is all our communication in OpenStack is not all of it, but mostly it's asynchronous because we're distributed so widely. So you need to have these conversations. So if you do take the, so one thing you wanna do is, make use of your time. So if you've spent some time looking at a bug and you can't reproduce it, don't just move on, put a note in the bug just saying, I tried to reproduce this today using this dev stack and I wasn't able to do it, can you give me some more information or something? And that'll at least, even if you don't go back and finish it yourself, that'll help out the next person. So it's a big cooperative kind of thing we got going here. Just an extra note on that. You will see a list of subscriber on the bugs. So that's usually on the right hand side of the Launchpad. If you're not seeing somebody you intend to email, so you can use Launchpad messaging system to send them a note and it'll go to their subscribed email on the Launchpad. So the next step forward is to make sure you run tests. Of course, assuming that you wanna contribute. So each project has their own way of testing and then we have like OpenStack infrastructure system which does overall testing. Tox is the testing tool that we use and we have got a good wiki on it, fortunately. It's a little bit old, but it still works. And if this is the first time that you're trying to run tests, make sure that you clone the mass branch, try to run tests on that because that's something that's been verified and that's something certified by OpenStack to be able to run in most environments. Yeah, just a general thing. If you're gonna work on a bug and it's a new environment you just set up, just always run the test before you start working just to make sure that they actually do run because sometimes you get weird interactions or there's something missing from the Python environment or something and the tests might not run. And you don't wanna discover that after you've changed some code because then you're not sure if it was your change. What you wanna be sure is that when tests fail, it was your change that broke them, that's something else. So that's why it's just a good thing to do. It takes, depending on the project, it can take up to 20 minutes to do this, but just let them rip and just make sure you got a clean baseline before you start making changes. Yeah, there's some system packages like Python.do and Lib, FFI or something like that that's usually not installed, reinstalled into a system. And depending on what kind of operating system you may find different sort of packages. So we cannot document all the environments or all the systems that OpenStack will work on. So there's something that you'll have to search for yourself on the internet. Of course, you'll get help on IRC and you'll get help on if somebody has a good blog or Wiki somewhere. Yeah, you can use Google to see if somebody's seen the exact error that you're seeing. Most of the time installing stuff is pretty stable, but every so often you just run into weird things. It's just like working with any other software. So don't be afraid to reach out for help. All right, so assuming that you have the environment set up right now, let's say you wanna add some code. We would highly recommend using a TDD and that's the best way you're gonna get good reviews on your patch. Once you have the tests written, make sure they fail so that you know that your code is doing the thing that you wanna do. And we have hackings and other sort of requirements on the code that you publish. So try to run Pepe tests as well as if you run talks in general it's gonna do a good amount of coverage in terms of tests. Yeah, so talks just by itself will run all the tests that are configured for whatever you're working on. You can also, if you look in the talks I and I file, you can see what's defined. You can run just specifically tests for Python 2.7 or just run the Pepe tests just to make sure that your syntax is nicely arranged the way OpenStack guidelines like it. Yeah, and if you're adding docs or if you're adding release nodes, then you'll have to run tests for those specific environments because those are run separately. And then the running individual test is a useful thing because like I said, there are a lot of tests covering pretty much as much of the code as possible. So if you run a lot of tests, as much of the code as possible. So if you run all the tests, it's gonna take a long time. So if you're just focused on one particular thing that you're trying to fix, you can look at that wiki page and it'll explain exactly how to run just one particular test. Save you a lot of time. So let's just go over a few examples on what tests and reviews look like and how we actually handle that. I guess before that it's just, so you've got local tests, so you can run them right in your environment where you're making changes. After you submit the patch, the continuous integration system will run tests on your code to make sure that they pass in the big environment. And then when you go to, when code gets approved, there are even more tests that it goes through to make sure it integrates properly with everything else. So there's several different stages. You can test run properly in your environment, then you put stuff up, and it's possible for a test to pass in your environment and not pass on the CI. And then it's always exciting to try to figure out exactly why that's the case, because it's just debugging. It is exciting. All right, so most of the times the CI works just fine. And this is a very good example of that. So Andrea's has published a change to the docs.ini file, and it's not on there. So this is Garrett. This is the interface that we use. So you make your change, you do, you commit it locally in your local repository, and then you do git review, and then it will send it up to our CI system. And what will happen is this gives us an interface for reviewers to look at your code. It also gives you the interface so you can see which tests have its pass, which tests that may have failed. You can see success is in green, means that everything's fine. The bars at the bottom sort of give you an idea of how complex this change is just in terms of lines of code. So it's adding green stuff and subtracting the stuff that's in red. And then in the bottom you'll see you get a history of the patch. So it'll be you can leave comments relative to particular patch sets. And then right up at the top just to scroll down tiny bit, just above the owner, oh no, okay, over in the right just by the download you see patch sets two of two. So you can use that to display different patch sets. So you can sort of go back in history. Because what will happen is you'll leave some comments and then somebody will, you'll leave some comments, the author will respond to them, put up a new patch and in the meantime somebody else will review it and the author may respond to that. So sometimes you need to go back in time just to see what comments were left one. So there are two ways to leave comments. Some is right inside the code. So for instance if you click on the Tox.li.ini. Yeah, this is that, okay. Do we have comments here? Well if you just, there aren't any, so this is the interface. So you can see a diff from the base version of the code and then the change that Andreas has just submitted. Oops, I'm just trying to, oh and you can see up on the top now that it knows that Nikhil is the one doing the review. But this is, one way you can leave comments is just like write, this is very handy, like write where you've seen something. So it's, he'll be, if you submit that I wonder what he's going to think. So comments don't actually get published until you hit review on them. So you can leave drafts and then if you save them, you can switch between devices and then the comments will stay in your account. It's true, you have to watch out for the drafts because they persist almost forever. I finally cleared out some drafts I had from like a two year old review. I think I might have some from the last two years. So you can see that drafts comments here and then if you hit the reply button it'll have a list. So here since Nikhil didn't save the comment that was in line there's nothing there. Otherwise you'd see underneath by where the code review buttons you'd see a list of the lines where you left comments and then this is your overall comment. So usually what's going to happen is you'll go through, or say something about and then you leave an overall comment just saying this is basically good but I've got a few problems with the way you're doing this. The code looks good but there's some really bad typos. You might as well fix them right now. And then you can assign a value. You can assign a value and depending on what access you have been given you'll have either plus one or plus two or minus one or minus two. It's a good idea to have an opinion and you know. I used to leave a lot of zeros and then somebody pointed out to me I'm wasting my time. So it's because you figure it's the quality of the comment that matters but basically one way to think about it is you should have an opinion when you're finished reviewing that it's either decent and you want to give it a plus one or it requires some work and you want to give it a minus one and just explain why. I'm going to say you're not really contributing much. I used to do that just because I don't want to really hurt somebody's feelings with a minus one but you have to just sort of get used to it. Minus one just means that you'd like to see something more happen before this thing gets merged and so you just have to say what it is. So what happens is the way it works is for I guess it's all open stack projects you require two core reviewers. You can give plus twos. So regular people can just give plus ones or minus ones. Well it's a practice to require two but even just one person again. And then the workflow is only allowed for the course. So the workflow is where so on this one you can see Nikhil's clicked one for workflow. So that's what submits the patch to the CD for everything to be checked one final time so on. It depends on which project but that's roughly it. The idea is the core reviewers are people who understand the project so they've worked around a bit. They've interacted in the meetings maybe done some work as a cross project liaison. So with each of the projects they have interactions with some of the other projects. So there's usually somebody who does that. So like for security it's usually a core person but for something like documentation or something a lot of times it's a person who's not a core reviewer. So there are various things you can do in the community to get yourself elevated and one of the best things I'm probably preempting some of your discussions. Some of the best things is just doing good reviews because it'll start to get noticed and the reviews that I really notice are ones that are minus ones but are very thoughtful. And this is the kind of thing where you want to everything that goes around comes around. So if you leave a nasty comment you're going to get them back and you're going to feel bad. But what you want to do is be helpful. With the plus ones too you might look at the code and it seems great. What is there to say? One thing you can say is just always because sometimes when you're in a hurry I forget to do this. You want to look at the bug and it's easy to get lost and just looking at the code and saying this is really beautiful the way it's doing this looping this is really efficient I like it. But it might not actually address the bug. So even if you leave a comment just saying this code looks good and it addresses the bug that's a really helpful thing. Things like that are just you want to be as helpful as possible in the reviews because what you want is to get helpful reviews yourself. So it's not just like you got to fix this loop. You would like to know what's the problem with this loop why is it inefficient the way I'm doing this. So you'll see as you participate the more you share the better experience for everybody. Yeah I think my experience has been if you help out cores with their time you're going to get good feedback from the cores or efficient feedback from the cores. Because we start to notice people's names because we get this whole list and as I'm looking at the lines I'm seeing all the other comments people left. And you start to notice this person is making really good comments. You can save time by testing out the code that's published like you can remove the code and see if the tests actually work if they're failing. That's one thing to do because all the time cores will have luxury to pull down every code just remove the base code and test out the added tests. Figure out if tests actually have a coverage for that code or not. We also look for good documentation and proper syntax and all those things. So it's just so many things to look at. Just with the amount of reviews coming up and not having enough cores bandwidth to do the reviews because people timeshare and stuff like that. Anyone helping out with a plus one saying oh this stuff works really well a core can come in and plus two and plus one plus workflow that's a really really good feedback and that's a good way to get into the core membership because you're actually creating a positive feedback cycle within the project within the ecosystem. It saves time and increases collaboration in the community. If you have in your local environment you can use the get review command with minus D to just so if you give the number of this patch it'll just download that and create a branch right in your local repository so you can just run things. If you do that and you test it out definitely leave a comment just saying I downloaded and tested this and that's always very helpful. Alright so just doing a I think we have maybe couple of minutes so do you want to go over this really quickly? Alright so maybe this is a little bit advanced and maybe we can just talk about it later so let's go over the slides. We do have some general ideas to share with you. So with the codes like any other software project we have our own way of doing things we'll have guidelines, we'll have project technical guide and then we'll have different types of processes to help out with the code but just a good practice making sure the basics are right you get the test working you have a good commit message that indicates what the code is trying to do if the tests are there what the intent behind that is and what exactly does it address for this particular release or if it's trying to do a long term fix which is a part of and your code may be a part of that and stuff like that so a good description is always helpful in getting good feedback so of course you want to interact with the community and get used to their way of working in the project and that's how you sort of improve on collaboration as well so okay please use TDD want to talk about reviews? As you've been saying reviews are really important so everything's got to be reviewed get two approvals from core reviewers before it's going to get merged so and code is going to get read way more than is written so it's just reviewing is part of life the only way to get your code merged is to get reviewed and the way to get reviews is the trade secret that Nikhil has here you got to give reviews so you need to budget budget some time to review some stuff as well as submit patches well the golden number is do three reviews every day one maybe a small one one is medium sized one is a complex one and you sort of get brownie points for doing the reviews and you get to learn using reviews of others and you know as well as trying to get into the code by reviewing stuff so that's it's like brushing your teeth and then taking reviews with a grain of salt I mean you're going to get everybody gets minus ones and minus twos and it's just don't take it personally and it's not everyone shares the common we all sort of share a common language but we have different levels of facility in it people express themselves in different ways I have a friend from Finland who explained to me that there's no word for please and finish and it made me understand his reviews much better so it's the kind of thing just be aware that we're working across cultural atmosphere so when you leave reviews it doesn't hurt to say you know this is a good start even if you don't believe it but it's good you know this is a good start but here are some things you need to address and if there's for nitpicky things some of them have like 70 patches so by the time you're working on your 70th patch you're pretty much done with this and if somebody comes along and says in this comment you switched I and E it's like yeah it doesn't matter but you know so you can put that always say just like a nit because you want to say that you noticed it and especially you don't want to be reading stuff and notice a problem and not say anything so if you just say nit colon you know this is misspelled you don't have to minus one it sometimes you can point some things out without minus one but always be kind of nice just remember if you make nasty comments nasty comments are going to come back to you and if you receive nasty comments always think well very possibly this person didn't quite mean it that way there's a different way to do it because the one thing to keep in mind is when you're sitting next to somebody it's easy for me to just say hey that's a stupid move you should use something else in that loop and he's going to take it fine and I write it to him and then he reads it in an email this is a stupid move it's kind of insulting so just keep in mind since our communication is mostly by writing you're not going to have somebody there next to you who you can just say something to so anyway just keep that in mind yes glance yeah I mean glance no I'm serious because the thing about glance is it's pretty stable it's a small project it's well defined what it does there's some weird interesting things about it so it's not like so obvious that everybody can do it but everybody here can do it but it just takes a little time it's a small community so it's not like some of the other ones where there's so many people that you get lost if you show up for a couple of glance meetings we're going to recognize your IRC name so it's a fun project to work on and it's our project yeah if people keep showing up at meetings we welcome reviews from folks but that may not be the case in all the projects right are we going to add a timer or what sir yeah I think we are just a little bit over time so let me just brush to the slide so that if people want to take pictures and then you know come back we're going to post the slides on the slide share okay so there's some more good information in here so Nikila posts the slides on slide share if you can ping us an IRC or by email if you have particular questions and we'll look for all of you in the weekly glance meetings so Thursday is 1400 UTC we won't have one this Thursday because we're here but after that feel free to show up and make contributions to glance and you can say I was at your session so you should review my code yeah I guess it's a good slide to end on so we're on open and honest communication when you're providing you want to provide constructive criticism in a professional manner because that's what you want to get and the other thing respect the project priorities so projects are working on particular things we're trying to get accomplished within this cycle and so the particular thing you're working on might not fall directly in there so just sort of keep that in mind that your code might sit a little bit might not get immediate attention for reviews if there's something else that's especially particularly when we're approaching some of the milestones we're trying to get particular stuff in the cores have to review the things that are project priorities so just keep that in mind alright thanks I'm sorry yeah I'm Brian yeah Twitter or IRC it's just my last name that'd be fun that'd be fun okay oh okay it'd be great yeah okay yeah an open stock has its quirks I guess I'm still mic'd oh okay that's great that's good now it keeps it running