 Hi, welcome everyone. You can move forward if you want So the idea of this talk is To explain based on a use case How you can train? Usefully to get your blueprint accepted quicker. So the game here for everyone is to fix bug implement features Create consensus on an idea find other developers and so on it's a game that is fairly easy anyone can play it and Most probably none of you have ever trained to do that It does not mean that it's not worth training But there is no training program at the moment except the one that was created a year ago Which is called upstream University? Which is basically an idea of? Being together with the people who implement patches or blueprints to help them level up So instead of discussing in theory how this should go what I proposed to you is that swami here who during the last cycle Proposed and implemented VP and as a service which is a fairly complex blueprint will it tell you the story of how it went and That will give you a base of Okay, this is how it should go and then after that I will tell you what training program you could use to follow the same path and maybe do Your own blueprint within one cycle instead of two so swami, this is you welcome everyone Thank you like So what's a blueprint and how do you create a blueprint? So looking at the picture here, okay? You may wonder like how big how tall is this tower like who built it? Like does it take how many years to build it? Is it does it happen in a day like in months in weeks? So all these questions will actually linger in our mind when we try to look at these kinds of buildings So assume a blueprint is like that like for people who are new to blueprints Okay, they don't know what is blueprint and what they wanted to do But all they have is an idea and what is a blueprint from a layman's perspective when it's talk about blueprints It's a big uphill task. We don't need to think about as an uphill task But what we have to do is we have to think about what idea we have How are we going to get there? And how do we do that in particular steps and particular order the reason I'm here is like six months back I was at the same shoes as we you guys were like people who wanted to submit a blueprint were thinking How to submit a blueprint so I was at the same boat like how do I do submit a blueprint? How how it would be accepted? What are the procedures it takes? Where should I start and where should I end so those things were all like There's there's no such there's there's a website out there for developers Okay, if you want to contribute code, this is what you should do But all it says is okay submit a blueprint and and the steps that you have to take But most of the things that I'm going to talk here is going to touch base on those steps but apart from that there are going to be some additional things that that are mandatory or a kind of a Adds value to your blueprint when you submit those things so Again when when you wanted to submit a blueprint think how big is this is the task? Okay, did it happen in a single day? No, it will not happen in a single day But the idea may arise in a single day But you wanted to capture that idea and then enhance it enhance that idea and present it in a way so that people Understands it or appreciates the blueprint and people who are reading the blueprint should get an impression that okay There is some value in this feature or in this bug fix Patch that you're trying to upload or it may be a new plug-in or a new feature that you're trying to add So that those things as soon as someone sees and takes a look at the blueprint They should immediately grasp that so that's where we are here like how do we need to do that? So again planning is very important for doing any kind of things all of a sudden you cannot just say in a one day just push a blueprint and Is it effortless? I don't say it's effortless There is some work you had to do like in your spare time you get an idea in a spare time you need to spend some extra time in order to write that in details and then submit it as a blueprint and Effort-wise implementing the blueprint. It's not like when you submit a blueprint and if it gets accepted If it is a big task you are not the only person who is going to implement it It's going to be divided into multiple tasks. So it's just a story point Okay, this is one big story that you have I need to build a big tower and then that's a big story point But how do you achieve that? So you have an idea so do a rough sketch of any idea so take notes whenever possible Take some hints. Okay. This is what I'm going to do This is the idea that I'm going to submit Do some quick prototypes if possible prototypes are always not required when you submit a blueprint but if you have a theoretical idea and if you have validated your theoretical idea with respect to the existing design and If you think if it is right Just go ahead and submit it prototypes or I would not say that it's a must before submitting a blueprint It helps you Speeding up the process in submitting your code, but not the blueprint because the initial blueprint that you are submitting as I said It's a big story block. It's not the actual task that you're going to work on So publish your blueprint as soon as you write your Snapshot of whatever ideas that you have write it in simple words in a paragraph write a blueprint and then say what is the problem description that you are trying to attack and By doing that watch a solution and how it is going to help open stack or the audiences of open stack So that's all they wanted in the blueprint So once you do that just go ahead and submit it and before submitting it There is also one thing that you can pay attention to you can check if there are if there is any other blueprint That have been submitted in the same area of interest that you have If there are other blueprints that have been submitted in the same area of interest that you have Take a look at the blueprint and see Where you are deviating from the other blueprint even if it is the same idea don't feel free bad saying that okay? That idea has been already captured by someone. I don't want to submit the blueprint What I'm suggesting is go ahead and file the blueprint even if it is of the same idea Because when you submit the blueprint as I said it's a big story point it may end up that there are multiple people can work on and Multiple people having the same ideas if they see that then you will be also provided a chance to submit your code or You will be at your blueprint will be accepted to do the implementation Yes Yes, so what what you can do is? There are two ways. Yeah, I think the question what he asked is because he didn't have a microphone I'm just repeating it If you see that there is another blueprint that has been submitted which is of the same idea that you have Will you submit a blueprint or will you actually participate in the discussion review discussion of the original blueprint and Take participation on that original blueprint. That was his question. That's a good question I think you can do either way if you miss it if you never paid attention to the existing blueprints And if you have submitted your blueprint then it's okay You don't worry about that you will be automatically included in all the discussions because you are also an interested party on that same idea If you are not submitting a blueprint and if you see another blueprint and if you are if you wanted to participate in that Implementation work then you can actually do the review of the blueprint and provide your feedback and by that you can be part of that team There are two ways of approaching it either you want to be a part of a team where In that case in the second case. What happens is you may not get much of an exposure Okay, you will be under the covers working in a sub team But if you submit a blueprint then you have a chance of having an exposure Saying that okay You are the guy who implemented the other blueprint and if there is any changes then people can talk with you And you will be automatically included in any of the discussions or in submit design submit discussions So that that is for sure So again as I mentioned you have an idea so there you go you you are ready for a blueprint Okay, so then go ahead and capture your ideas an idea can be as simple as an enhancement to an existing feature So if you see there is an existing feature out there And if you want to enhance something in that existing feature then just write a note on that That's an idea again Just write it down and then submit a blueprint and say this is the problem I'm seeing in this feature and this enhancement will help address these issues and that's where I wanted to Provide this blueprint again an idea can be as complex as a new feature or a plug-in or even a bug fix So for any all those things each task that you are going to do Is being monitored by the blueprint that you write or a wiki page So a blueprint can be a document or it can be a wiki page So preferably initially while starting you start up with a doc and then once you are Approved and ready to implement then you actually transition from a doc to a wiki page wiki page is the most preferred one through open stacks so people can view it at one single point Docs it's it's difficult to upload docs. So you have to have it in a different repository So people don't like it the community doesn't want that to happen but for To a to have a starting point you can do that as a doc but while moving forward then you had to transition to wiki But the the the reason I'm telling this is like for people who wanted to do that at one shot If you don't have enough time just write a wiki page Don't do a doc just write a wiki page that way you don't need to transition back and forth So as I said your blueprint should capture what problem or idea you're trying to solve How does it matter for the community? The problem that you're trying to describe and the solution that you're trying to provide So these things has to be very clear and crisp So that way when people are reading it, they know, okay, what you're trying to address and that will actually give them more Thought or interest in actually going through the details other solutions If even the abstract or the initial thing is not crisp enough to go and read it Reviewers or some people may not even take a look at it. It's just just it'll be browsing So if you want someone to pay attention Just make sure that your blueprint has all all these things And again, the reason I'm talking about this one is When we say an idea and submitting a blueprint, there are As lauik mentioned, there are some technical people here. There are some managers here And there are most of us are related to technical areas and we have We all have technical skills on our own expert areas And technical skills are enough to get an idea or capture those ideas But the problem is we apart from the technical skills We need some soft skills in order to put together everything and present it in a way that everyone can accept it So technical skills are a must no one is saying that technical skills is not required I would say like 70 30 in this case 70 percent of technical skills you want and a 30 percent You need some soft skills in order to work with the larger community like open stack and basically As lauik mentioned six months back I was in the in the same area As you people are interested in where I I didn't get a chance like Who approached to how to submit these things? I had the technical concept I have written down the technical notes, but how do I present it the soft skills came from the training that I attended from upstream University, which was a two-day class. It was a free class when I attended six months back in portland So it was very useful for me when I came to that class I came with a notion saying that okay, they're going to teach me how to code they're going to teach me How to debug the problems in open stack they're going to teach me how to View any of the issues that I'm having in open stack, but it was entirely different It was not that it was the soft skills that they teach you how to approach people How to put your blueprint how to present the blueprint the reason that you're seeing these slides in here Like what how do you describe your problem? How to provide a solution? was actually These were the ideas or knowledge that I gained from the soft skills. So that would actually definitely help Boost your blueprint. I would not say that you just by soft skills you can do you want But as I said, it's a 70 30 you still need the soft skills in order to be a winner You don't you don't want to just submit a blueprint It's just a story point there lying in the launch pad. No one looks at it If you want someone to take a look at it, you need the other 30 percent that I'm talking about So again, you it may also you may also need to capture. How is it related to your business decisions? Like basically it focuses on enterprise customers cloud offering What does it focus on so in my example like the blueprint that I submitted was basically a vpn So it's and then when I submitted a blueprint there was these questions were actually initially asked To me by the upstream university. Okay, you're going to submit this blueprint. Okay. How is it going to help you? Why did you choose vpn? Why not anything else for secure communications? So because vpn is a proven technology at that time That's why and it has been used by all enterprise customers for a long long long time So there is no such a new invention in there But the invention there is basically the idea there is to put everything together Have an abstraction layer to configure and deploy these services In an existing open stack neutron environment. So that was the reason we added all those things So this is an example like how I did My blueprint presentation. So again when you present a blueprint Make sure you have your use cases covered the first thing that The community is going to watch is basically what use cases or what problems that you are trying to solve So in this case in my thing I had like two different use cases like site to site communications and remote user communications So these these are use cases that your complete story point is trying to Attack but these can be sliced down into multiple tasks like one as a site to site and one as a remote users One task will be done at a at a particular point. The other task can be done at a different point And both the tasks can be done by by one person or it can be done by multiple persons Or even one task can be split up into multiple smaller tasks So that way you You do you do need to capture all the use cases the reason I'm saying you need to capture the use cases is Your blueprints will be prioritized based on your use cases It will not be just based on a high-level story point that will be prioritized based on use cases Each use case will be prioritized and based on your prioritization. You start implementing it So again, um, your your blueprint may cover the use cases and apart from the use cases It can also Provide a high-level overview of how you are trying to solve this problem with your solution What kind of data model you have what are the api definitions cli Test cases and dependencies. I would say that these are all Even a secondary option initially These are you don't need to spend too much of time on defining all these things if you have more time I would recommend go ahead and do that But if you don't have enough time to do this one Just leave it there put a use case and if you have an idea capture it capture your solution Go ahead with this one. The reason i'm saying is your cli api All those things may change when you have a discussion with your peers when you have a discussion with the community Community can come up and say, okay, you need to change this you need to change this Because we need to come with an agreement with the community. It's not your own idea That's going to go through the community. So your idea is what you have captured and thrown it into the Storybook and once it is in the storybook it can be now re return or refactor to address and And to get all the feedback from the community people So that way don't don't spend too much of time in putting more details on the blueprint it it can be Very high level Just with object model if you want you can include object model But cli level api level always will change because based on customer's feedback I've seen like cli and api definitions change even during the implementation phase like phase three Okay, so it can change anytime. So don't worry about those things So, uh, how do you uh, again register your blueprint you have a blueprint now Now you have to actually push the blueprint blueprint to the upstream So you you create a launchpad account, which this has already been in the developers Website create a launchpad account submit your blueprints through a launchpad So again assign the blueprint to a particular milestone Don't leave it there as such the problem is when you submit a blueprint There is an option that you can actually assign your blueprint to a milestone If you leave it without a milestone people who are reading it may get a conclusion that You are not very much interested in working on this for the next release And you just throw it in your idea and you don't care about that idea So I would recommend that while you post that make sure You actually assign a milestone release the next milestone isos or j How's that we are going to attend And again assign an approver for the blueprint so that approver will get notified that when you post a blueprint And then he will actually go and review your blueprint. Otherwise, no one is going to watch your blueprint Yes If you are submitting say for example, if you are submitting your blueprint for Nova or or specifically for neutron or for specifically Self anything so you know the ptls or you know the core members who are there who are approvers select one of them It can be random. You don't need to even talk to them. You just select one of them and say he is your approver It doesn't need to be a specific person It should basically align with your own group or project that you are trying to contribute to And then so the blueprint as I said Whatever you are throwing up on the launchpad is basically A backlog story point that will be there forever And it will not be addressed until you create another summit session registration Basically for the summits like this for every six months. There is a design summit that That happens and for design summit if you want your blueprint to be discussed in the design submit Make sure you resubmit your blueprint for the design summits Because if you don't resubmit for the design summit if you just throw it in the launchpad It's just in the backlog. No one is going to look at it unless there is a another blueprint with the same idea Then that person will try to pull in you on all the discussions and he's going to now go and present it into the summit sessions So make sure you submit it for the summit sessions. So summit sessions normally That website opens up a month before the summit So make sure you are looking at watching the emails or attending the meetings And once you attend the meetings, you will be notified of when they open and when they close the summit dates So when they open just go ahead and submit it on this link. So these are the links The the top link the launchpad link is for capturing your backlog and the second link is for Summitting it for a summit session And after you submit, um, I don't want just to say, okay, I have submitted everything is done I'll be called by open stack people and say, hey, you guys go and implement it. That's not going to happen So basically when you submit it, you need to monitor What's the status of your blueprint because there is a status flag on blueprints that you can actually monitor When you when you submit it or for the design review summit, there is a status. It says either accepted unreviewed or rejected Or approved or pre-approved. So those are the statuses that you can see So if based on your status, you can just take the next action Normally if your status is is has been refused. Also, you have the right to ask, okay Why why was it refused? What was the reason it was refused? And and for all those things you need to have a log of what you did with the open stack It is always best to maintain a log what you did whatever actions that you're doing When you submit a blueprint, just go ahead and first submit the blueprint Send an email to the distribution list for the developers distribution list saying that, okay This is the blueprint that I have submitted persons who are interested in that. Please go and review the blueprint And wait for a week if you don't see any response from the community send another mail Again wait for a one week Then I would recommend go to the join the irc meeting For the for your particular project in the irc meeting copy paste your Mail that you sent out or the review doc link and say I have posted a blueprint I have not Here anything from the review comments. So please if possible can anyone go ahead and review it So that way your actions are being captured And if there is a valid reason for your refusal, then you can accept the refusal If it is there is no valid reason then you can actually go talk to them and see what's the problem with that Most of the time it should not happen, but yes When it is refused you can ask them like why is was it refused there may be some reason Okay, there is another blueprint of the same type. Okay. What they will say is okay You two submitters blueprint submitters you talk to each other and then you come up with a single blueprint So for example in my case when I submitted the vpn there was like four blueprints on vpn And I had the same problem. I I had to go through the same problem Initially it said it in the status changed to discussion And during the submit time one week before the summit time the status changed to refused The reason I saw in the email was it said, okay There are multiple people who are submitted. So just come up with the one single blueprint You need to come up with the consensus if there are multiple parties You need to come up with the consensus with the multiple parties So once you come up with the consensus then you will automatically be part of the implementation sub team So that that way you can work it out So again, um, as I said if the if you find multiple blueprints start having discussions with your peers Who have submitted the blueprints? So once you start the meetings you you organize meetings talk to them What what is wrong? What is right? What do you want it? If everything is in alignment and then once you have it Then you finalize on the use cases which use case you are going to target for the first release Then try to um slice down the use case In different tasks and then finalize the features So blueprint details as I already mentioned, uh, it may not be detail Just submit the ideas with uh with the problem solving solution Uh, it it can be in a word document, uh, or it can be in a wiki preferred format is wiki I think I discussed that one so again reaching consensus with the community So this is the major part that we all have to understand First of all, we have to be very polite and gentle with the community be patient with what You are you wanted to expect don't be harsh to the community Just send gentle emails and talk gently when you are on phones So don't expect anyone to take a phone and talk to you in open stock So that is not going to happen unless you form a sub team Um when you are just submitting a blueprint everything is should go through irc and email exchanges don't expect anyone to go Take a phone and talk because you are not going to get the numbers because you are dealing with people Across the country across the world. So um, there are people from different countries Dialing in working on the same feature So you have to try to come up with irc chat Learn how to do the irc chat and that's how you can communicate things people are there Every time it's because across the time time zones. So you you can get help from any people whenever you want from the irc So once the team agrees on the features and use cases Then then your sub team will be identified. As I said, then the task will be split And the the owner of the specific task then they have to rewrite the blueprint for that particular task as a wiki page With all the details like api data model specifications all those information will then go there So as I said in the initial step that you took it's it's an overall thing that you're trying to put together You can throw in your ideas, but those ideas over the course of this approval process will change And what i'm saying by will change is You have to be have a mindset that it's going to change Don't have a mindset that will never change and I will not allow it to change You should be in a position to accept changes and willing to work with multiple people listen to others Then make changes and submit it So this one I already covered as I mentioned we need you need technical and soft skills. Yes Yes, it's uh, so once you have Normally when you you will find out the lead whoever has submitted the first blueprint or whoever is working Across the team members So they will actually try to lead the Feature discussions or whatever it is and they will be the lead and they will actually it's there is nothing Called lead in this case. Okay, except for the core members other people are all flat developers in this case There's no kind of lead but people who organize meetings and try to pull in more people That's what I mentioned by lead, but don't think that there is a lead and they don't work Everyone develops code Yes, yes, so they they you try to work with them and then they find out who are all interested parties So these things even happen in the summit. Okay in the design summit you go there You attend a session and and they talk about and they say, okay Whoever is interested in implementing it you raise your hands and you become a member of the sub team So I think now Like will take over and see how he um, you can achieve the soft skills as I did Thank you swami for this crash course into What it involves to have a blueprint accepted So you have a choice you you can just remember All the advices that swami through his experience gave Right now Or what I propose is that you can get training at upstream university And that will help so the way we go for this training is On a real example Getting involved in free software in theory Is easy there is almost nothing to say But in practice it proves to be difficult So the students for the upstream university course they come with what they actually want to achieve When swami came with the vpn as a service blueprint it was by far the most complex Goal that we had It succeeded, but It was very different from the other students. Yes Well, it's never sure But uh, swami was able to do that. Yes So, uh, you never know. There is no guarantee But it helps to be trained So the key is you come with an actual work that you want to do Now that the problem with the actual work is the format of a training is like two days But you won't get your blueprint accepted in two days Even a patch won't be accepted in two days So we structured the course so that there is online follow-ups until the work is finished So in the case of swami the goal was The blueprint needs to be scheduled for the next cycle So it took about three weeks. I think so after three weeks I was in paris. He was in his in the us and we drank champagne remotely So the way uh, the course Goes is the first day life day Is divided into Um, during the morning we go over the chronological order of a contribution So it's uh, I put slides They are theoretical slides such as Who are you going to talk to and every student already has a topic in mind? So they relate that to what they are going to Try to achieve they think about Who they are going to talk to and we have that kind of interaction During the first morning In the afternoon we try something completely different We do a simulation That is we pretend that a lego town Is a first after a project And we have fun being contributors and upstreams around this lego town So it's always fun to play with lego But the the goal of this simulation is really to reveal the weak points that you will likely Need to fight When you do the actual contribution And since it's a game you don't feel too bad when you see that you lack communication skills It's just you know that maybe you're shy or as I am I'm not a native english speaker So it's a problem and it triggers communication problem during this simulation you can figure that out and the second day We do the planning and practice so no longer theory not simulation we go down to work So the students every student is handed 11 slides deck Where they have to prepare during one hour How they will go about the contribution and then they come on stage and they present These slides to the rest of the students who get to come on and give them advice See a different perspective of the contribution since each topic is different You you have diversity during this morning In the afternoon We prepare for the online sessions that will follow up So we we make sure the tools It's mostly irc Are are okay. We agree on a date for the first meeting and Are That's about it if there is more time then we just get to work and that's the end of the live session After that the online sessions is basically like agile when you organize your work In a agile team you do stand-up meetings So let's say you work Every day on your contribution then you will have Maybe every day an online mentoring session of one hour So the goal is you explain to the monitor what you did And the monitor does not Get to say anything just to expose what you did you past URLs dialogues, etc And the monitor tries to Understand exactly where you are In the second phase That is the most important phase The monitor is either assign the task of unblocking you if you're blocked So a very common blocker is I try to talk to people they won't talk to me I don't understand. I tried to be gentle. I tried to knock them But that just doesn't happen So the the monitor is in this case Engaging a dialogue with the student to try to find a solution And when we are too trying to fight A battle in the free software field 99% of the time it works. We're not in a hostile environment where a blocker is definitive The other situation for the mentoring session is when you have No blocker at all And then the task of the monitor is to help you improve That is say if you just have a bug And you know how to fix bugs you took this bug for the training and usually that kind of bug takes you three weeks So the monitor will try to find ways for you to fix the same bug in half the time Maybe reduce the number of mails you have to go to maybe because he is an external Eye to your contribution. He will see that You spend More time because you don't explain enough in the comic messages It's also a very common drawback you you fix the bug and then in the comic messages they are fixed back But you have to explain the rational the choices you made The monitor may help you Flesh out your comment in the comments and all of a sudden Your patches will be accepted quicker Now if you are a member of a company if you're a manager and you want your team to follow that kind of training You're welcome to Subscribe them to upstream university But if you are an employee and your manager doesn't see any value In this training you can still attend for free And If you're lucky enough to be in a new in a university I know it's uncommon for people who come to the open stack summit to be students from university Although there are some thanks to the Sponsorship program of the open stack foundation You may find such a course in your university in france. There are two university offering such a course And now I believe we have a few minutes. Do we or yeah, we have about three minutes for questions If you have some One two. Yes, I think you don't need to come to a I think the question here is if he's submitting a big feature and if he assumes that it's going to prolong for more than One cycle meaning six months or one year or one and a half years What he thinks is How do we how do you assign it to a particular cycle? Isn't it? No, I think what What you have to do is in that case if you think your story point is big enough You basically assign it to the next release cycle Whatever is the next release cycle and then put your use cases and try to split down your use cases. Okay Anyway, your use cases will be based on features Okay If we have like 10 different features write 10 different use cases And then go present it to the design committee and then while you are presenting you say, okay These are the 10 different features. How do you want me to prioritize it for the next release? Okay, you take like baby steps step one. Okay, you implement out of the 10 features like five features Step two you implement another three features and then rest give it to the other one Yes, you can have dependencies and if you have a dependencies You can say these are my dependencies and I'm going to assign this as a dependency as for my blueprint Yes Yeah, most of the time what happens is you have to communicate with the other Team and talk to them if you can actually Work together while you are working rather than waiting for them to complete because normally in open stack What it happens in parallel you communicate it and make sure your design accepts those changes Okay, julie your turn you you're uh, you're uh last So one two three Julie, please So the question is is upstream university focused on open stack or does it work for other free software project? The thing is It actually works for any kind of free software project There is nothing specific to open stack in the upstream university training The soft skills that you get out of upstream university universally apply to all free software project that are healthy That is where you have a community Now if you have a project that is very sick, it won't cure it Dave so I think Yeah, what they have is like If there are people from different countries and if the sub team spans multiple countries There are two or more people they normally Sometimes I've seen they come together have a get together they talk And then try to implement it and basically when you when you split those kind of tasks Make sure that you are aligning that task to a specific zone or specific People but that's not Really healthy in that case because people wanted to span across the world. That's the reason for open stack But if you wanted to be if you want to get rid of that language barrier Without going through irc, but irc is is the one preferable thing that I would say it works so far But so we're regarding the time zone problem. It's it's an awful one. I'm I became this year core contributor to the saf project And there are people in asia and in the u.s. And in europe and the only where we came You know For the summit for instance, we have an online summit every three months And We organize it in two half days With overlapping time zones that include those one half day as overlapping time zones for europe and the u.s And the other half day with asia and the u.s. It And It's a mess. So I don't I don't know if there is any solution to that. It's real problem. Yes, sir last question Yeah, I think Can you repeat the question if the future is big enough like a vpn as a service What he says is will it be immediately accepted for implementation? Or it will be an incubation for a while and then will be done later Is that a question? Yeah, so most probably whether a feature has to be an incubation or a feature has to be immediately Implemented it all depends upon the community feedback If the community feels that this feature is a must and a desired feature that they want They they want this feature yesterday, but they're still waiting for this feature Then if you have submitted an idea which actually correlates with that feature Then they will actually give you a a green flag on go ahead and implement that feature If the community desire is not there for that feature There may be like a one or two persons raising their hands and saying I may be interested in this one Then it may be in an incubation phase You have to incubate it and make sure that other parties are interested in that Come together get together the party and then try to bring it up You can create desire during the summit. Yeah Thank you very much