 Thank you, Stuart. First of all, I'd like to say I absolutely love New Zealand. This is my first time. And one of the things that I have noticed since being here is that I cannot hold a coherent thought in my head. So I have been unable to create a thought and then actually vocalize it. I have no problem vocalizing it, but I have no idea what I'm about to say before I say it. So I hope that we both get some benefit out of our time together. So the name of the talk, Garrett and Gertie. So who knows what Garrett is? Yay, who knows what Gertie is? I read your talk submission. Awesome, awesome. Okay, great. Well, we'll get to what Gertie is in the talk. Who the heck am I? My name is Anita Kuno. My nickname on IRC and most everything else is Antea. Let's move that mouse, shall we? Go over there. I'm a member of the OpenStack infrastructure program. Who would know what that would mean? Who knows what that means? Okay, why don't I explain? OpenStack is a very large open source program to provide an open source cloud computing solution written in Python. It is comprised of a number of different programs. Right now we're, I think we're at about 21 different programs. The infrastructure program is the team that sets up and runs all of the services that are necessary for the development community. So that is any of our communication tools, all of our automated testing. If we use paste, if we use, we use a tool called EtherPad. So the infrastructure team runs and does all the system administration for that. I'm not a system administrator. I do a lot of gluing things together and running and helping out and communicating things while other people are busy fighting fires. So that's kind of my role and I like to move around a lot. So I do different things within infrastructure program, but that is my home. I spelled among wrong. I can't spell. I am among the top 50 reviewers for OpenStack. OpenStack, as of when I checked this morning, is two, I think it's 2,103 reviewers that are being tracked right now. So I'm in the top 50 of those. And I started during the grizzly release of OpenStack. We're currently working on the kilo release. And I'm an employee with HB. Things that I had to guess about you. I really enjoy doing talks, but I'm bad at predicting what people want without asking them. So I had to make some assumptions about what you want from the talk and why you're here. So I guessed that you understand the value of code review. How accurate am I on that one? Value of code review. Yes, code review is valuable. Awesome. You recognize a need to improve review throughput. Yes? Okay. So review throughput would be your ability to review the patch contributor's ability to come back, your ability to review again, and also to be able to distribute that out. So teach other people how to review so that you're not the only one. You have, I also guessed about you, that you have the ability to evaluate your behavior and implement modifications. Now those might be modifications to your behavior or those might be modifications to code that affects your behavior. Would that be an accurate assumption? Some of the people in the room? Okay. All right. Some what? Some what? That I can convince you the value of that last one, of being able to evaluate your behavior and implement modifications. You are hoping to get something from this talk. I hope to be able to give you the location of the Garrett documentation. I hope to be able to tell you what GERDI is. And I hope to be able to help you understand the anatomy of a habit. And I apologize for the line wrap in the title on that slide. And this one as well. So I have long titles for slides. Sorry about that. Why do we want to increase review throughput? Code review can be a bottleneck to development. Who has experienced that in your workflow? Who has experienced where either someone else's code review habits or your code review habits provide a bottleneck for development? Okay. So all right. So quite a few people in the room have experienced that. We can increase review throughput by distributing the load for more reviewers. So hopefully we can take what you're actually doing that works and help you communicate that, give you a tool to communicate that to others so that they can review more, start reviewing, review better and help to distribute that load so that there is more activity happening for reviews. Also, if you include more people reviewing, you improve the code because you've got a diversity of reviewers. If you've only got one or two people reviewing the code, then they're actually going to start driving the design of the code because it's their aesthetic or their values that are saying what gets merged in the code. And if you increase the diversity, you're getting different people's opinions, different people's experiences with how they want to see, and you actually have to justify what your decision-making process is rather than saying, oh, it looks good to me. So what I'm going to try to cover in our talk today is the... So for habits, the anatomy of a habit and the implementation of a habit. Garrett, a very, very thin overview since most of you already know what Garrett is and some technical suggestions. And with Gertie, what is it and how do I use it? So for habits, a definition of a habit is an acquired behavior pattern regularly followed until it has become almost involuntary. And I got that off of dictionary.com. And the two things that are important about a habit. One is that it's acquired. It's not something that you're born with. You acquire it through continual behavior, repetitive behavior, until it's almost involuntary. A habit contains no decision-making process. Once you're in the habit, it's a routine, and it does not finish until you've hit the end. So the anatomy of a habit. So we start over here on the left-hand side with a cue. So a cue can be anything that triggers the beginning of the habit. We move up to the routine. That is what someone else would observe as the habit. And then we finish with the reward. You can think of a habit as a cron job. So a cron job, you've written a cron job, and it starts quite often as cron job based on time. So the clock changes. The event, the trigger, is a certain time happens. And then the job, if it hits the filters for time and day and frequency, then it will execute a behavior. The behavior is whatever command you told it to do. Then, hopefully, the job will finish at some point. And that is the reward. So the cron job has to know when it's finished. So hopefully by executing, when it's finished executing that command, then it will stop and that would be the end of the habit. Does that make sense in terms of thinking about as a cron job, in terms of understanding the habit loop? So a habit is something that has a defined beginning, an observable middle, and a defined end. So the difference between a habit and an addiction is an addiction doesn't stop. Can you see that? Yes, unless you can't. It's a slide of goats running around and around. So they've got a series of benches and goats love to climb up hills. They want to be on top of things, a bunch of baby goats, and they're climbing up to the top and then they're jumping off and then they're running as fast as they can and knocking other little baby goats out of the way so that they can climb up to the top again. And so they just keep going around and around because there's no stop. So that would be considered an addiction because there's no end to it. So starting with a cue, what could be considered a cue? A cue can be a location, so that can be a geographical location, also a physical location, your desk, your chair, a time of day, an emotion, people around you, or a given action. So the trigger for this one if you were getting together with friends. So I'm sure that everybody has a group of friends and every time you get together you might have a ritualistic greeting. You do the same greeting. Maybe you meet at the same time of day or day of the week and maybe you go to the same place and maybe when you go to the same place you consume the same food and you do the same activities. So one of the triggers might be when you get together and you hang out with some friends. The routine part is whatever the behavior is. So the cue is whatever set it off and said this is the beginning. The routine is actually what the observable behavior is. So your brain has no way of discerning what is a beneficial routine and what is not a non-beneficial routine. Your brain can't tell the difference. All your brain knows is that when the cue starts the behavior comes afterwards because you're into a part of your brain where you're not consciously thinking. It's a part of your brain that has to act as a routine until it's finished. So something happens you're going to execute a behavior. The reward is the feeling of completion. You have gotten to the end of the routine and the reward is how you acknowledge and say this is the end. So some sort of sense of completion. This is why using food as a reward for a behavior and lead to a behavior because the eating of the food is not linked to hunger or nourishment. It's linked to identifying the end of a routine. And so if you link a routine with a chocolate chip cookie in order for your brain to say we're done now, you have to consume the chocolate chip cookie. So using food as a reward for behavior is probably not the best choice. Pick another reward that somebody can do repetitively over and over again and it still will be helpful for them. So what? So how does understanding the anatomy of a habit increase review throughput? So if you are looking to increase your review throughput, the first thing you need to do is select your reward. Doing reviews doesn't tend to be a reward laden activity. In code submission, in development, it's submitting the code, getting the code merged. That is the point where everybody can acknowledge that, wave the flag, we all get gold stars because everybody can say we did something. We have provided value. We have lines of code with our name in them in the code base. That is not the same thing with code review. It's hard to do. It requires a lot of work and focus. You have to understand the code, sometimes to a greater extent than the people writing the code. But you don't have the same sense of reward or completion as people who contribute code and get code merged. So in order to motivate people to do reviews, you have to be able to find a tangible reward so that code review becomes desirable. People have to be motivated to want to do code review. We have a tool written by one of our contributors. It's available at that URL. If you go to git.openstack.org, that's where all of our code repositories are. Russell Bryant wrote this tool, and he contributed it back upstream. What it does is it pulls Garrett, and it takes a look at reviewer statistics. These reviewer statistics are for just the infrastructure project for the last 365 days. You can see that C. Boylan, that's Clark, one of the members of the infrastructure team, has done 2,876 reviews in the last 365 days. So I use this tool myself when I started reviewing and I still use it because I use it the same way as I would motivate myself to walk. So if I'm walking and if I did 5K one day and 10K another day and 2K another day, I like to write that down. Not because I'm in competition with anybody because it helps to motivate me to have something to measure. I can write that down and I say, I did this today. I don't have to tell anybody, I just know myself. And so when I was getting started reviewing, I would just start out and look at my statistics and then I'd say, okay, I'm going to have to do 5 more for tomorrow. Or I'm going to do 1 for tomorrow. I'm going to make sure that I've got 1 more for tomorrow. And that was my way of measuring because when you're in reviewing it can be such a big ocean you can't recognize yourself. So you have to give yourself tools to recognize what you are doing and being able to measure it. If you can measure it, then you can see where you are and you can evaluate whether or not you're improving. So if anybody would like to use that tool for their own Garrett implementation to take a look at that, you're welcome to. It's an open source tool, grab that. It will be configured for the open stacks Garrett implementation, but you can go ahead and change that and use it for yours. So the point of this one is when you're developing a habit you have to start off by selecting a tangible reward that people are motivated to be able to evaluate for themselves so they can tell when they're done. The second, for the actual routine, is filtering. Code review can be overwhelming. So people come to open stack and they say, how do I help? And we say it would be really great if you could review some code. So then they go to Garrett and they look at the open reviews and at any given time we have thousands of open reviews and it's overwhelming and they don't know where to start and then they go and they start merging code or start submitting code to be merged because code review is so overwhelming they don't know where to start and they don't feel that they have a place that can be a foundation where they can start learning. In creating a habit, habit is a pattern. So you have to be able to put yourself in a situation where you can repeat the behavior. And it's not important that you can repeat the behavior many times in one day, but that you can do it that day and you can repeat it tomorrow and you can repeat it tomorrow and you can repeat it tomorrow. When I tell people to start reviewing code they say, oh, well it's so difficult and I don't do enough reviews. Just do one a day. Do one review a day. If you can create a habit where you're doing one review a day you will get to the point where you will want to do more. But even if you do one review a day in 365 days you've done 365 reviews and that's helpful. But if you have in your mind that you're going to do one code review a day that's when you actually start developing the habit of a repeatable pattern and then you will eventually want to do more reviews. In order to develop a repeatable pattern I use this query with Garrett. And what that query did is that brought back all patches that had touched the ACLS directory. And there was such consistency in those patches because it was a new repo creation. So the Garrett ACL that's access level control so that's Garrett permissions. And that's what you need when you're creating a new repository. So there was one pattern in all of those patches. I started in just reviewing patches, changes to that directory and then when I learned I started expanding so that I could review all of those kinds of patches and now I'm a core reviewer on the repository that contains those kinds of files. So the point with this is to select a query, select a routine that you can repeat. The minimum amount that's effective that you can repeat day after day after day. People want to bite off a big chunk. You don't do that. Bite off the smallest possible that you can do every day. Identify a trigger. So you've got a reward. You've figured out how to create a repeatable behavior. Now, so you're working backwards in the habit loop and you need to identify a trigger. So the trigger can be anything that works for you. Location, time of day, your social needs and completion of another habit. So I went with completion of another habit and what I do is as soon as I log on the first thing I do is I sign in to everything. I get my recent emails and I've signed on to IRC and I read the back scroll and so on. And once I've got kind of the news, that's when I open up Garrett and that's when I bring up my custom query I'll show you in a minute and that's when I take a look at my personal, my own review queue. So with Garrett I construct a query and it looks like a big mass and we'll go through it in a minute but you construct a custom query and that's mine. Everybody I know has their own custom query but if you create your custom query that's creating your filter for your repeatable behavior. It's bigger now. It collects more than just the access level control files because I have that habit and so now I'm able to expand so that I bring in everything in a single repo. So with Garrett, the big question when I'm talking to people about reviewing there is internal documentation in Garrett about how to create a custom query, how to create a search query. So you go to documentation right at the top level navigation. When you click on the documentation the bottom navigation will change. You will have an option for searching. Click on searching and what's down here is what the result will be. It will open up in a separate page and you'll have Garrett documentation about how to do searches. If you don't know anything else about Garrett learn how to use Garrett custom queries. They are how you filter down so that you've got files in a single repository, changes to a specific repo, so that you have a query that you want and you know what you're going to expect so that your brain can fall into that habit and that you can review. So you construct a query. The top part, the top phrase, I want to take a look at patches that I didn't create. So if I'm reviewing I'm not going to review my own patches. Some people review their own patches and then we have to comment and say that's not a good idea because we know you like it. You gave it to us. So I don't want to see my own patches. That's for other people to review. I want to review patches that are open. In Garrett they can be open, abandoned, merged. So I want to see open patches. If something is merged, I don't care. It's already gone. I don't need to review it. And if something's abandoned, again, that's a dead-end trail so I'm not interested in seeing those in terms of reviewing them. Labels are helpful. I want to see the labels that I have not voted on. Plus one, minus one, plus two, minus two. So anything that comes from me that has code review zero. That also returns patches that I've commented on if I have not voted on them. But if I've already voted on them I don't want to see them again. And if that patch gets a new patch set to it that will pop up again because the new patch set my vote will have zeroed out with a new patch set. So I have to review that again because it's a brand new patch set. But if that's still in the open state but I've already reviewed it I don't want to see it again. Label workflow zero with Garrett. You can set it work in progress. That's minus one for workflow. And if it's approved that's plus one. If it's work in progress I don't need to see it because it's not ready for me to review unless somebody specifically asks me to but I don't want to return to my regular review queue and if it's plus one it's already been approved I don't need to review it. And I'm going to take a look at patches that are submitted to that specific repository which is the open stack in for project config. So I am running out of time so we will just move through the rest. So this, if I run the query in Garrett this is my review queue. So I've actually got a page and a half because it's about 20 patches returned on a page. So I've got 30 patches that meet those criteria which is better than 500. So I will go through and it doesn't mean I'll get through all of them in a day but I start with my review queue and the thing is because the query says that if I've reviewed it I don't want to see it so I review it and then I refresh the page and what I just reviewed is gone. So as I'm going through my queue is getting smaller. GERDI. What is it? GERDI is a console-based interface to the Garrett review system. So if you're using Garrett for code review and you'd rather not use a GUI you'd rather use a console. Garrett, our current Garrett which is 2.8 has a REST API and so Jim created GERDI for a number of reasons and Jim's back there. Thank you, Jim. If you would like to take a look at GERDI it's available on PiPi. Why was GERDI created? It has a local database so it's good for offline work. We have a number of our developers who fly around in airplanes and so it's difficult for them to be able to sync changes with and use the GUI so they can work offline and then when they land and sync back up again they can submit their changes and their reviews. Some folks like to use a console rather than a GUI and Jim also writes good software. For GERDI configuration you can configure GERDI use the same queries as Garrett. One of the things that I have done is I've been using GERDI more and providing Jim with lots of bugs or unusual queries. Jim is working through those bugs so that they're able to match exactly or as close as possible because Jim has his own parsing to pull it out of the local database. You can map keys to certain actions so when you're reviewing you can submit plus one, plus two. We call plus two an approval we call that plus three and we can map that to a key. If you do a review of minus one that should always include a comment of why you've submitted you've chosen to go minus one on that patch as well as some instructions as how that person can improve the patch and get to plus one. So this is how it looks like in my terminal so that's all of my open subscribed patches with GERDI it doesn't pull down everything in Garrett it's not big for local database so it just pulls in projects that you subscribe to. And this is a Josh Hesketh patch and what it looks like in GERDI so that you have all of the information and then you are able to go through that with your keyboard. If you want more about GERDI you can learn more. Jim has a talk Wednesday scheduled at 2.15 but keep an eye on the schedule in case it changes called REST APIs in the return of the console app. It will have nothing to do with how to use GERDI and it will have everything to do about why Jim was motivated to create it and why you as well should write your own console app using REST APIs. If you would like to file and fix bugs that is the storyboard link we use storyboard for the bug tracker for GERDI. So closing thoughts on habits you can never remove a habit you can only create a competing habit or a more compelling habit so if you have a habit in your life and you say I don't want to do this behavior anymore you have to have a more compelling habit that draws it away. A habit never goes away so you can't try to do nothing you have to do something that's more important to you every time that you feel that trigger you do a different behavior. A habit won't stop until it's reached the end of the file so when you do that pick ways for you to be able to acknowledge that you're at the end habits are not logical so anytime you're trying to argue with somebody about something that's a habit, habit is not logical so if you just accept that then you're able to work with it better and once a habit is created the thought isn't no longer involved so with people saying I won't do that because I'm smart, smart has nothing to do with it if the habit is there, the habit is there and it won't change unless you do a more compelling action on the same trigger. I want to thank you very much for your kind attention we've reached the end and I am out of time and I don't believe I have time for any questions do I have time for questions, Stuart? Your call. Is there anybody with a question? Either because I bored you all or I was so thorough I answered them all as I went along thank you for your kind attention.