 Hi welcome everyone mics are good. All right. I would like to encourage everyone just at the door We have plenty of seats available. So if you would like to just make yourself comfortable Thank you very much for all of you who joined me on this very last session just right before the booth crawl I will try not to bore you to hell My name is Yeliko Wancha. I'm working for Ericsson and First of all, let me bore you a little bit about my experience with OpenStack and what I am doing Just so that you know what you can expect I started to contribute to OpenStack. Well more than two and a half years ago I have to tell you that I was a very eager young puppy and I'm still very eager. That's for sure I started with the BitSelometer Which was already a core module in OpenStack, but it was a smaller one So I had an easier job to how to approach the project and I already had a planning mind and the request from the company that what feature they would like to see In that project in the next release So you could think that I I had a quite easy job to do, but it actually wasn't It took three months to Increase the code base of selometer with 2% We actually Experienced with my colleague a nice minus 2 on Garrett Which if you are not experienced with Garrett it actually means that that patch goes into the repository through my dead body But the good news is that we made it so the API extension is there You can use the rich query functionality in the telemetry API So I'm one of the person who you have to blame for that feature and the API design Which got that nice minus two, but we actually managed to get our ways through so What I can tell you based on this that really nothing is impossible You just really should not give up when you meet the first obstacle because I'm sure that you will face plenty of them since then I became a core reviewer in Selometer and Nowadays, I'm at least trying to coordinate the OpenStack related activities within Ericsson so I have experience and I I have the opportunity to to encourage people and bring them on board and I I see their success I see what they are struggling with so this is partially what inspired me to propose this talk and share or my all my experience with you and Help you to Find your way into OpenStack I'm also involved in a cross-project feature development nowadays Trying to get multi-attach volume supporting in Nova, which is well the task is ongoing now for Five or six release cycles so Cinder has the feature support partially implemented as it turned out since Havana So we are struggling with a few things which also gave pretty many lessons to learn and I Hope that based on my experiences you will be even more successful To achieve your goals within OpenStack so I Will at least try to guide you through that what can what can be the possible ways To get a feature to get an idea into OpenStack or just simply get yourself into OpenStack Because if you don't already have a feature to To drive it's really not a problem. So it should not stop you from any kind of an engagement I Will just very quickly guide you through that what kind of tools we are using just so that everyone is on the same page and I will talk a little bit about the challenges of cross-project and inter-project feature development and then give you a short summary of all the things that I shared with you and If I managed to finish in time, then I hope that we can have a bit longer question and Answer session at the end So that you can you can ask about Your your personal struggles ask for suggestions and help All right, so where to start? Basically All right, I have to share you one thing at the beginning. I don't don't like lying I will not talk about code and technology because where we are it is a large and very rapidly growing and Very quickly changing open-source community. So where you are trying to join is is not a bunch of code. It's not list of Software packages and repositories. It is many thousands of people So in the during the mitaka cycle, I think there were over two thousand people who Contributed any kind of a code or documentation into open stack So that's pretty many people So you you have to keep in mind that that you're joining an ecosystem And you will work together with people from all around the globe So it's it's pretty different from what you can experience within a company because when you're even when you're working for a large and Geographically distributed company you can always find the boss of the other person, but in open stack You cannot or It can happen that that the other person doesn't even have a boss because he or she is just Contributing to open stack for fun in his or her free time and then who to ask that Oh, she's not behaving nice to me and now what to do. So You really have to use your social skills or build them in order to be able to part of this community Alright, so as I promised just quickly if you would happen to be that new to open stack good news is that we are trying to be structured and We are really trying to show you entry points and give you a Possibility to follow what we are doing and to be able to join to what we are doing So we are using tracking tools Mostly we are using launchpad So if you would like to find the bugs and the blueprints, then you can you can check that web interface and I think currently it's only the open stack Infra project which is using storyboard We are communicating much in Every format mostly written by many formats It's basically I Think it's a larger part of of the work that you you will do So not exactly the the cold development and implementation will be the large chunk of of something that you need to learn how to do So basically when you are for example trying to introduce a new idea, which is more complex then we usually Advertise the mailing list where you can really target more people On the best way that you can just have The only thing or well multiple things that that you need to keep in mind regarding That media is Always tag your your mails So in the subject just give the name of the project or give them all if you would like to really talk to everyone in the community so that everyone who's using filters in their inbox can easily find Your mail and so that you can really reach out to everyone to whom you would like to and Try to avoid HTML mails because that's kind of the best way to find people who will not like you at all and And You will you can have experience on on Christmas Eve that someone from the Nova core team just Pings you on IRC without even saying hi that I see you're using Microsoft Outlook Good choice. All right, so maybe you would like to avoid this and Simple plain text based mails work the best on the mailing list, so Remember this even you're using Outlook you can Configure it to Send out plain text mails Not easy to find but it's manageable. I was able to do that after I think one and a half or two years But I managed to so now I'm a better citizen of this community If you would like to have more Let's say online communication. We have plenty of IRC channels so basically we just flew back to the 20th century and Experiencing all the joy of the text based Messaging, but the good news regarding to this that all the channels on free node are logged Including the meeting channels. So this actually means that we do not have to worry about the meeting minutes because when you have voice meetings then Meeting minutes are the the things that kind of just people forget to do right? So after a meeting you have no clue That who said what what decisions were made? In case of open stack you can always read back the meetings And it is also very important from the perspective of the times on differences that we have to experience within this community so There might be Occasions when you just really cannot participate on the meeting because it's 2 a.m. At your time zone So in this case it is very very useful when you can read back the logs and I always suggest to to do so Okay, now I will talk very tiny a little bit about the code We are using version control And we do that in git It is very handy I I first used it with with open stack and I think I learned it within a day So it's really really not hard to learn I Will I would assume that most of you have someone in your close neighborhood who knows already how to use it? so just Always reach out to people and ask for help if you need to we are using get it for code reviews and Garrett is actually the third bullet point on the communication item on the list Because we are chatting pretty much With each other on Garrett because in in many projects the the blueprint and specification Reviews are happening also on Garrett so that will be the place where you will discuss new ideas with people and Also, you will argue about why your code is awesome on Garrett with the core reviewers So that that will be pretty much one of the interfaces that you will really use the most and Well, we are trying to Ensure that we are we care enough about quality So we try to test as much as possible and we are using Jenkins who's our automation friend to run our test jobs and Jenkins will also comment on your Batch on Garrett and we'll let you know whether the tests run successfully or not So pretty useful to also I will not talk more about these tools. You can find many many documentations either on the open stack documentation web pages or Just in general on Google You will also find this figure on on the slide in the open stack developers guide So I would like to encourage all of you to start with with these if you're if you're not familiar With either of the tools I just mentioned Alright, so Let's assume that now everyone knows all the tools have registered to the open stack foundation and ready to join to our Nice and friendly and open community What to do so I would assume that those of you who are here and not a manager Would like to do cool stuff and hack around and you know, I have a great idea Let's push it in and this is what I would like to do Not a surprise that all of us would like to do this But it's not really the best way to be part of an already Existing environment because you're as I mentioned you're you are joining a group of people you you are joining a team which is Working together the people in that team to Maintain Enhance and develop further each and every single module So if you would like to really join open stack and not just be someone loud On the side that this feature is really important. Why you are not merging it Then I would like to suggest you that Try to look for For those items which are really Which really don't look that fancy, but actually will be very very useful for you and will be very very useful Also to the community Because they will see That you you you really care and this is very important because when you're trying to push in a feature Then the team also tries to ensure that that you or someone from your team will be around to actually Maintain it fix the bugs that you introduced because most probably you will and you will be part of this whole environment to keep all these things together that we have today and When you're trying to to fix a bug or when you you're trying to add the piece of documentation That will be actually a pretty good Competence build up work for you So also from this perspective, it will be very very useful. So Don't think of it as a as a dirty word because Even writing documentation can be very challenging. You can believe me I wrote the the administrator guide chapter for telemetry. I don't know one and a half years ago 35 pages in the PDF format and That was quite a bigger bit of a challenge to get that merged in and I Actually managed to understand many of the parts of the API and and the behavior of that module just because of writing Of that documentation so never think that those things are are not useful for you because they they always are Code reviews I already mentioned that we are using grades for code reviews and You're all new so you would think that code review is for core reviewers, right because that's their job and This is why they are part of the core team But it's not true So being part of the community also means that you take part In the code review activity as well it will be also Competence build up for you because you will learn really really much about the code base and You will learn much about all those features that That are added to the already existing code base You you might even find bugs just by reading through the changes and trying to understand the code That the author has changed So it is again a really really good Task for you to do so I would like to encourage all of you to Really take your time and spend your time with code reviews This will just like all the other parts of the dirty work section This will this will be one of the activities which will show The core team and the contributors around the module that that you really care you would really like to participate You're learning your lessons you care about that what kind of changes go into the code base So when you're when you're doing all these activities Including the previous dimension bug fixes and documentation People people will recognize your name you will you will be visible for the community and This will help you in pushing features in so it's again part of part of the Socialization, but it's it's not about chatting with people on IRC about the weather It's actually real coding work but still it's I think more a bit more part of of the social skills because Giving good and valuable code reviews. It's really really not easy Also, when you're uploading a patch and waiting for reviews you you have to be patient Because the core team is usually very very busy, especially in case of larger and more complex projects So if someone so if no one Looked at your patch within a few days or a week then just don't panic It's totally normal it will happen But if you if you do code review work then people will recognize your name They they know that oh, yeah, I know that guy or girl who uploaded that patch. Let's let's look into it Let's see what he or she has done So you you will you will get most probably get reviews much much earlier this way and When you receive a minus one, especially when you're a new contributor I have to tell you that it is good news seriously so when you receive a minus one that means that someone finally looked at what you're doing and Obviously, no one is perfect So you made mistakes or even if you if you didn't make mistakes each and every project has their their own guidelines of how they would like to see the code changing and What is their style of writing documentation and adding new things or doing called refactor work? so It's minus one is is not not that kind of a critique that you should worry about It is important to try to respond to the review comment as soon as possible Because it will again show people that that you actually care about what you are doing And you're really trying to be part of this whole ecosystem and joining a joining a team and Try to fix all the issues that that the others found or just really answer the questions or describe that why you're you did something in a way that you did Because if someone added a review comment to your to your patch It does not necessarily mean that that person is right. So it will again trigger a discussion Which will which will bring you closer to find your way within OpenStack I As I as I encouraged you now I I usually try to encourage people who who I who I worked together with We Ericsson, we are also cooperating with the university and there are there are also several students who who are just trying to find their way within this really really large community and Even from from OpenStack, we we usually periodically discuss some some For us, let's say weird Behaviors so there are some you should do and you should not do when you're doing cold reviews Focus is one thing that is generally true So don't try to review all the projects within OpenStack because that will just not bring you closer to what you would like to achieve So try to focus on either one project or one cross-project feature That you're interested in and try to learn about it as much as possible You can you can always download the code from Garrett actually the user interface will show you the link and The comment that you just kind of have to copy and use and you will have the code on your machine So you can you can run the tests locally you can check whether the code is really tested by those test cases That were added whether the code really fixes the bug or implements the feature that someone tried to Achieve you can always Try your code in DevStack DevStack is our development environment. So when you're lucky and trying to deploy OpenStack from the master branch and branch and DevStack is working It will take you around half an hour one hour depending on your networking bandwidth to clone the repositories and spin up Live OpenStack on your laptop and you can play with most of the features that that are added to OpenStack and People will be really really thankful for all your feedback that that you give After trying out their patches When you're when you're giving a minus one Because even even if you're new it it does not mean that you will not be able to find issues within the code You you will always be able to if you if you read it through carefully and really try to understand what it does So if you give a minus one then always follow up the the patch and what's happening there Because It is it is important To always double check whether the author really fixed your issue that you found and then give your plus one and the sign that okay from your perspective the the patch is good because If you if you get there to to join a core team, this is what you will need to do Actually follow up on all the patches that that you keep an eye on and and reviewing and ask questions, so Even if you're new or if you're not new it can happen that that Either the the author did something in the code change that is just really hard to understand or you just don't know the code Based that much or you're just really curious that that why That changes added in in a way how it is added Never be afraid to ask questions. You don't have to put a minus one on that patch just Go on Garrett and highlight the part of the code that you don't understand and put your question there and Someone will will answer or if you happen to not get answer On the review you can you can always try again on the next patch set of the review or jump on IRC and find the author and Ask for clarifications It is really a little bit of be selfish and try to learn as much as possible What you should not do because I'm always trying to encourage people to Not be afraid of giving minus ones Because actually minus one will be something that's valuable for the author because that's That's kind of that's a real feedback that you check the code you you understood and something is really not good with it But you should not Jump on the other side and then try to give too many minus ones because I assume that most of you have Managers and they are sometimes looking for numbers and you would like to show that yeah I didn't did much of the valuable work and I gave out 30 minus ones yesterday. So I must be awesome That's not true. So for example repeating what Jenkins said you can do that but the author was notified through mails So you repeating the Jenkins output is really not valuable except one case which is that you check the The test logs you found the issue and you have a suggestion to the author that how the issue in the test should be fixed That that's an exception when when you can when you can repeat the Jenkins output But you're not really repeating the output, but actually giving valuable comments to the author Also always give an explanation when you give a minus one And try to avoid just to say that yeah, I agree with the other reviewer. So minus one It's just that's not your thoughts. So don't don't repeat don't repeat others and as I said really really don't work for the numbers and Never try to look for the easy reviews I mean plus one thing Type of fixes. It's yeah, it's good But I would assume that it's really not taking that much time to anyone to learn how to give a garrit review And and these kind of reviews do don't add anything else to you just to really Memorize this process that how to how to use garrit itself. So Even if a patch is 500 or a thousand lines long, it doesn't mean that you should not spend time with it. It will take more time and One thing I know Because of my experience because yes, I'm working for a company too that managers Sometimes many times do not really understand that What are you doing for a week because you haven't produced much cold not nothing much happened So so what did you do try to spend some time and explaining them that why you're doing this and how this will help in your work because They have to understand as well that what they should and could Expect from you and and it's not not about you But it is about how this whole community works and what is like being part of an open-source community And Again, this will be a very very good Lesson for you and cold reviews is is something that that you always should do Alright We'll run out of time because I talked too much. So do cold reviews because that will be just really really good for you alright Driving without plans because It can happen that that you didn't really get clean directions on on what you should do just you should you should be get engaged with OpenStack and Just do stuff and get visible but but but how to do that So I have to tell you that I don't have a step-by-step plan and the recipe for you because each and every one of you has to find His or her own way to get get engaged with this community There are many entry points So you can find smaller projects to to engage with just by doing the dirty work or Or looking for already started implementations and asking people whether you can join because you're interested in that particular feature You would like to learn and speed up the activity by joining the implementation All of these things are are valid entry points Again, this will require some of the social skills Of you so you you need to be able to communicate with people to to achieve this but I can only recommend you to do so and what I already mentioned at the review part try to keep focus because OpenStack well it it is way more messy and complex than than the picture on this slide So it's it's very easy to get really very lost So you can check the list of the projects. We have a wiki page for that You can briefly check the description that what each and every project is trying to do and you can decide on whether you Already have experience with certain areas or you just have interest and you would like to learn something new Pick one project or pick a cross project activity, which is about to add a new functionality to to the whole software package And try to stick with that and join the activities and talk to the people and get your way in Because otherwise if you if you if you don't keep focus Then after a certain why you you will be a little bit or pretty much under motivated because You will not have that many successes within the community because you will be visible everywhere But you will not be visible enough anywhere in order to be able to achieve what you would like to do So always keep focus go step by step and don't have too big Expectations so keep yourself motivated by by joining that area that that You're interested in but don't expect to be a core reviewer in Nova in one month Because even for the most eager people it takes years at least By now after six years that project is just so big and so complex that it's just very very hard to join so be aware of That that this is just not that easy and and takes time it takes time for you to learn and it takes time for the community to get to know you to trust you and accept you and We arrived to the you would think good news part when you already have an idea you have an agenda or you have Bossy manager who told you that you have to implement this feature within a week So good news you know what you want to do, but well bad news. I still don't have the recipe for you. So Because you still have to find your own way Based on your own experiences That how to do things what I can suggest you when you're trying to push An idea and a new feature into a code base. Don't forget about the dirty work part Because this is this is how people will will be more open to what you're trying to do and When you're introducing a new idea Always think that twice that what what your use cases are and Discussed maybe with others in your team or or in your Company whether they they understand clearly what you are trying to do based on the blueprint Specification that you wrote up or or the or the mail that you wrote up Because you need to ensure that others will understand what and why you are trying to do and If you don't know exactly how to do that thing Or how to do the exact change in the code base You can always ask questions This is why we have a mailing list and this is why we have an IRC channel for each project You can just jump on and ask questions From people if you're doing code reviews you will most probably know after a certain while that in a given project Who is the expert of which area so you can? target people with specific questions and This way you they will help you how to get your change in in in the best way that fits with that project and It if that would happen that your idea really does not fit anywhere The good news is that it is quite easy to create a new project and create a new repository within OpenStack Whether it will be part of the big tent at a certain point or not That's another question, but you can always try out new things and This can be useful from a perspective as well that By by today we have a few very complex modules and we are trying to reduce complexity and not not Increasing it any further So when when you have an idea which which you see that it would could fit very well as a standalone module Don't be afraid to to spin up a new project and gather people on events like like this design summit And just do cool stuff alright In the remaining very few minutes Inter project features so everything that I I already described you is true But what you have to keep in mind specifically in this case when you're trying to add the new functionality that impacts At least two OpenStack projects that communication is way more much much more important than before because you have to ensure that the interfaces between the two projects will fit and Unfortunately, I have experience or I know people who have experience with Trying to implement cross-project features and have some implementation in one project and then after a release time It turned out that the other project will not accept at all the changes that that would be required in order to fit those two things together and that meant actually to Just go back to the drawing table and do the whole design from scratch or almost from scratch again So you would not want to waste a half year or a full year just because you didn't or haven't discussed it with The core teams of both or all projects which are affected so I can all again suggest to to have a Clean description of why and what you would like to do and ensure that both of the core teams or all the core teams are involved within your proposal and You have the right contact To come up with the best design that you can and you still have to expect that it will take more time Than than you would originally think so make your managers understand that that these things not happen that fast Because of all this communication and Changes in multiple projects is just not easy to get in but if you if you Go further enough with with socialization and being visible within the community you will be able to easily get help and Find the right people to talk to and make your idea Reality It can happen that either you have an idea that that would require a change in In open stack as a whole or you would like to join an already ongoing activity We are trying to keep more and more focus on On these changes because it requires much coordination Within the project. So now we have cross project specifications and cross project liaisons just to keep an eye on this So if you would like to Introduce a change like this then you will you will need to introduce your idea in the cross project specs repository and Ensure that all the liaisons and projects who are affected are notified and being part of the discussion and This is the part when the technical community will come in and Committee will come in and they will also double check that the idea and the proposal of the solution really fits with the ideas of open stack and and design directions that we have and They will approve or they will give guidance on on how to do all these changes that you would like to make happen So Just very very quickly always focus find your area find the right people and Just start doing Because It's really up to you whether you're able to join or not You you have to you have to go there. You have to do you you should not give up Never give up as I as I mentioned that the starting point of my talk a minus two can happen But it still does not mean that the API design or the change that you would like to do cannot happen You just need to talk to people a little bit more explain a little bit more that why you're doing that thing why you chose that type of a design and You can you can still make things happen you need to be collaborative you need to be professional Never ever take anything personally So that can happen that the other person who did that particular cold review Just really had a bad day because all of us have I have a bad day every Monday. So That can happen But they they never meant it to the comment to personally you most probably You never met before they don't know you at all They only know the code that you wrote or the documentation that wrote they they might didn't like it that much that day It happens But what you need to focus on that was the content of that that comment that what's the technical issue with the code and What you can learn from it and still remain professional remain friendly and collaborative because this is how people will accept you and This is how this whole community will remain a friendly and open and welcoming Environment and no silver bullets bullets. So what worked for me will might not work for you I cannot tell you personally what to do again. I can only encourage you to just Put yourself out there do it be eager and Show your willingness to to join and your care about the community the code the particular Module that you would like to join to and as I talk too much and drinks are available already You can you will be able to find the recordings of of this Talk and let me see whether I can just go back to the very beginning So you can see my email address my IRC nick on free node my Twitter handle So you can find me hunt me down and ask questions if you have any I Promise whenever I have time I will help you and find more people who you can talk to and who you can Help you so Enjoy the summit Make connections Talk to people make friends make colleagues and enjoy and have a great time at the booth growl. Thank you