 as a core from now on. So I started at HP Cloud at start of March 2014. And I was supposed to work on SWIFT team for HP, ended up doing lots of background research, and on my first day at the office I was asked, hey, could you jump into glance instead? So I had absolutely no idea where I'm ending up to. And having a busy team around me doing their own stuff, there was lots of stuff to learn and lots of mistakes to be made trying to figure out what's going on. And basically my first commit was a couple of weeks later, when I was trying to work out the V2 image API for us, and we realized that it was good, but the registry service does not work with the image V2 API. Starting to fix that up, and during the feature freeze we ended up pushing a couple of patches up to fix those. And busy team, small team on glance on us, I ended up relying lots of help from upstream. So IRC is priceless. If you want to be part of the community, go to the IRC, go to the channels, the OpenStack dev and the project channels. Just talk with the people, get to know with them, be part of the community, because that's all about how to go forward. If you don't get in touch with the community, if you don't get the help from the guys around you, you will be floating on the water without steering nor engines. And after the Icehouse, we got Icehouse out, we got the V2 API working with the V2 registry. I started to look how to debug glance, how to figure out what's going on on the logs, realized that they are horrible. It was absolutely nightmare to start doing anything based on the information what we got on the logs. So next step was, I started to look what we can do about that. And going into the logging, I started to pick up what's going on, because pretty much every piece of code logs something, or every module logs something. And reading all that through gave me some level of idea how glance works itself. And next step was, of course, trying to figure out if the logs are so horrible, what we should be logging. So even more understanding of the system itself was needed. And I decided to take the easy or the difficult path, and I started to read every single patch that came to review on glance. Because that's a brilliant way to learn what's going on, how it's supposed to be working, and what's not working. Looking the reviews, I didn't comment on every single one. I didn't vote on every single one. But over four months I read pretty much every single comment that was proposed to glance. And I came to understanding what's going on, how it actually works out. I started to push changes on our logging, and got pushed back quite hard. Surprise, surprise. The community has quite often really set rules and set foundations, how things are done. And if you start doing changes on something like, if you want to pretty much go through every single line what we log, and make sure that we locked it on the reasonable level, you start getting pushed back quite a lot like, hey, no, we can't do this, we can't do that. Are you sure you are doing that right? And it was on June release where we finally got, June and KiloCycle, where we finally got agreement on those logging changes and the logging levels. At that point I still haven't touched a single logging message. This was just about the logging levels, what we are doing. So on Paris we got together with quite a few people who were concerned about the OpenStack logging together. And we put the logging workgroup together. And started to get in touch with operators and other developers to see what's going on across the whole OpenStack and its logging. And that got me involved on quite a lot wider base on what's going on OpenStack and how the things are done and what can be changed and what is sacred, what must not be touched. So at that point I came to the conclusion that because of also my history in HP and being doing enterprise product support for four years before moving to cloud, I noticed that for me the important things are stability, supportability. And I started to focus on those things more than pretty much anything else. Brilliant situation was that my manager was absolutely supportive on this work and that helped a lot, so I didn't need to do it on my own time. I actually got paid for it. So it was around September-November last year when our PDL came to me and asked me if I wanted to work as a stable brands liaison for clients. And I didn't even think. I said right away, yeah, absolutely. And the next step was he told me like, okay, with that comes also a stable core position. And I was just happy like, okay, fine by me. I start happily looking after what's going on into our stables. And maybe two weeks, three weeks later he sent an email to the mailing list and proposed me also or nominated me also to Glanscore because I had at that point fairly good understanding what's going on inside the project. And like he pointed it out, I had the passion and the attitude what they were looking for. From that I got added to core last November and we started the logging work group on top of that. So I obviously took the liaison for the logging work group as well. Give or take eight months. I realized that I'm a stable brands liaison. I'm a stable core. I'm a Glanscore. And I'm a logging work group liaison. Of course on top of that I need to do the company priorities and our normal day-to-day work as well. So there was quite a few things I learned on the way. And one of those is that I have been loving open source since I was a teenager. But it's not a shortcut to happiness. And there is lots of hard work that needs to be done to do it professionally, getting paid for it and getting to the stage where you are recognized as a member of community. Not just name somewhere there. And other thing I realized quite soon is that the community will not change its own direction on itself. There needs to be people who are making the noise that the things are wrong and doing the steering. If no one tells anyone that, hey, this is wrong, this doesn't work, we cannot work like this, nothing will ever change. And if your management is not involved on the upstream side, educate them. Because if you don't get the support from your management doing the upstream work, there is no way you will be their critical member and getting those changes done and being able to affect the community on that way. Also, the right way is not always the community way. So you must remember that you need to be able to give up as well. No matter how passionate you feel of the changes and how much you think that they are the right things to do, if they are not done on the way, what community does it, there is no way you are getting them in. And if you don't ever give up, if you don't ever compromise your own ideas, no one will compromise for you either. So hold on those things that you keep really critical, but remember that it's not always the right way, what you think. Last but not least thing what I learned is that whoever claims that course are not special people have no touch to reality. There is so much going on behind the scenes that doesn't show up on any statistics. They are not work that you can go to your manager and show them on the paper that, hey, this is what I have been doing. There is so much sleepless nights just before release, trying to make sure that those last patches gets reject and reject and reject until they go through CI. There is also the balancing act between the community and your own priorities, your company's priorities. When you are core, you need to think the project and the open stack as whole. It might not always be what your company priorities are. It might not always be what your own priorities are. That's one part of educating your management that even it is something really important for your company. As a core, you might need to block it for the benefit of the project itself. Last but not least, it's also the responsibility of the project. It's so easy going and voting plus one, minus one on the changes. And when you have the core rights, going and accepting something on what you haven't really understood, may cause, gate failures. And it's not only the gate failures, it might be something that will never show up on testing and at the point when we get release out, all the hell broke loose. And we have seen that happening not only because of sloppy reviews, but also just because we can't catch every single point on testing. And first thing is always, okay, who approved that code? Did you notice anything that might cause this? The next topic I was planning was what would I do differently if I started the same journey now after seeing just over a year what's going on. And I came to the conclusion that that's actually not the right way to see things. I crossed over to wood and big thing is what I will do differently because I realized that lots of the things I wrote down when I prepared for this talk was things that I'm actually still doing wrong and I just haven't realized it or haven't taken the actions on those. The biggest thing what I would do in past differently would be that when I got nominated for the core, I actually didn't go and talk to the existing cores what the job is all about. I thought that I've seen what's going on, I understand what's going on and that's absolutely wrong. I was running like headless chicken for first couple of months doing absolutely stupid things and I would call out for every single one over this room who gets nominated to core or who is core to speak with the new people and initiate that discussion when there is new cores included into the project we need to talk how the project cores work what are the expectations and set those expectations both ways. I for example have never had experience on databases I tend to skip reviewing those changes that affect databases or the database side because I don't understand it and I don't think I'm the right guy to do that. It would be extremely wrong for me to go pull the chains down, look like okay, looks like it works plus two or plus two and approve as I had no idea and that was something I perhaps started to do at the start I thought that I'll try to speed up the process I'll try to speed up the chains approval rate and I didn't do it on the level what was expected I got called out for that and I had to learn it on the hard way and I hope not a single project on OpenStack needs to actually take that hard road and when we get new cores in we actually set the expectations right all together. What I will change on myself and my own behavior after this process going through what I did, what I have learned is that I must stop jumping into conclusions based on other people's comments. I have been way too trigger happy and I have lots of opportunities to ask on this round as well meeting people face to face for the hard attacks I've caused because I was trusting a comment or misreading a comment and I jumped to wrong conclusions out of that. When we do that on the negative things we start to be sloppy on the positive things as well if we start trusting blindly the reviews and the comments of other cores or other key members of our teams we stop reviewing their code or we stop reviewing code what they have reviewed we just trust that yeah he plus two did or she plus two did I can go plus two and approve, get the easy merging and I don't want that to happen either because we are all human, we all get tired and someone always misses something critical another thing I need to start still reading or continue still reading the changes coming in being busy is not an excuse to not knowing what's going on in the project and I have missed so many changes specifically at the end of the kilo cycle that I have no idea what's going on with artifact stuff I have no idea what's going on with indexing service and those are things I need to be catching up to know what's going on in our project to be able to tell that yeah I am a core in the project I have the rights and I have the privilege to actually merge code in last thing that I will need to change on myself is to start talking to people more not only between the course but as a core to every single one in our community who is submitting code, who is commenting changes and making sure that we understand each other because like myself we have lots of non-native English speakers and it's way too easy to misunderstand comment or message and again jump into conclusions it's absolutely critical that we talk with each other and make sure that we know what the message was intended not how it was read so those are the things what I learned throughout this process and planning this talk what I need to do and one piece of knowledge what I have learned I'd like to share is how to balance that between work and hobby work and your personal life what comes to open source because for at least me open source have been my hobby and my passion since I was a teenager before I started working on IT or pretty much working on anything and starting to work on open source I was really early jumped into the situation that I was working my 8 hours at the office I got home and I was reading the code until midnight because there was more stuff to do, more stuff to learn and I was way on the well burning myself out so it doesn't matter how much you care and love what you are doing it's never worth of burning yourself out because then you are not part of that community anymore it's not useful for yourself nor anyone else quite often there is also no one to one correlation between the community personal and the company interest and if you take it too much if you promise too many things that doesn't fit into your work schedule it's only yourself you can blame because the community will take every single bit of help what you offer to them so we must learn to say no we must learn to not take every task that looks interesting and drop something off to live our own lives it's also extremely good idea to be social with the team and not only talk about the work now when we are here at the summit let's do that socializing outside of the sessions go out to have a dinner or something like that and drop the work talk drop the talk about the project see how those people are actually doing as a person because that means world to people who are working lots remotely working from home they might not be working with their colleagues at the office and when they come and meet each other you don't want to be just resource in a project or resource in a company you want to be treated like a human being as well and none of us probably can't take a week for full days of work talk and then going out for a dinner and continue that work talk also we must keep our own interests so do your own project get involved something else if the open source is the thing than just open stack that helps you keep the perspective you see how other projects are working and you can keep your new ideas coming in so that you don't get stuck into that loop this is how we do things we must look outside of the box as well that's pretty much what I have to share I hope we have people here who have ideas, questions something you guys would like to share because I'm sure I have missed quite a few pointers here that could have been useful Thank you No questions? Let's hit on the beer then