 So I'm going to talk about these two issues. We're going to talk about milestone dates integrated to epics and roadmap bar edges using fixed dynamic start and end dates. These are two very important issues that we're going to be working on in the 11.2 milestone here and so the focus is on actually the roadmap view. So the roadmap view as it exists right now is what you see on the screen and you know it's fairly usable but what's important is that we want to get the roadmap view usable for GitLabbers. So our first customer, our first user portfolio management features right now the target is GitLabbers and the reason for that is because we at GitLab need to plan longer term and we need to have the tools, we need to have the methods to do so. So many people are using different ways to plan long term. They're using spreadsheets, they're using Google Docs, they're using GitLab issues with a lot of different labels but it's very non-optimal, it's not the right way to do things and we need to invent the tools so that we can as an organization can plan longer term and it's something we need to do as GitLab scales, grows as an organization and we work on more product areas as we grow our product teams, engineering teams, design teams as we work on more features as we plan longer term as an organization. We need these features so therefore that's why we're one of the first customers and if we can do a good job or if we can design the features that we will use it's a lot more likely that our customers will use these features so that's why it's very strategic in this case that we design the features that we will use ourselves and so one of the first jobs of getting ourselves to use the feature or to improve the features actually getting ourselves to use it and so a huge problem right now is that GitLabbers are not using the roadmap view as you see right now. I personally am using the roadmap view but GitLabbers as a whole are not using the roadmap view as much as we should be. In particular the roadmap view should be used by product managers, engineering managers day to day to visualize what work is being scoped in the future and so there's a couple of problems with the roadmap view and these two issues in my opinion will solve the problem of product managers not even at GitLab not even using the roadmap view and so once they're actually using it then they can give the actual useful feedback and then we can iterate. So we have to get them to adopt it in the first place and so we have to cross that threshold and in my opinion these two features will help and the reason why these two features will help is that these two features that I'm going to talk about essentially allow GitLabbers to do bottom-up planning. So there's two types of planning there's top-down planning and there's bottom-up planning so I'm going to talk about top-down planning first. Top-down planning is what GitLab epics and roadmaps already allow you to do right now so you can go into GitLab you can click into epics you can create an epic and with any epic as you see here you can assign a start date and an end date and so if you wanted to plan something far into the future say you have initiative all the way in Q3 of 2019 you can create an epic and you can put a start date and you can put an end date in that epic and and then you can say oh I'm going to work on it you don't even have to assign any issues but you're just going to say it's going to start you know in July it's going to end in September of Q3 2019 and you can do that and you can put it on the road map and that's great for top-down planning that's when you want to plan big high-level initiatives before knowing the details that amount of work the scope you haven't even estimated anything you haven't even created the subsequent issues and you can do that right now with GitLab and it works fairly well all you need to do is create an epic put a start date put an end date you can even have some comments and have a discussion going and then you can plan those things for it that's great GitLab should do more top-down planning in my opinion but unfortunately we as an organization traditional we don't do that type of planning we do bottoms up planning so that's why I'm pretty confident why we're not a GitLab or product managers and and engineering managers in general are not using or adopting roadmaps and epics in GitLab as much as we can because it doesn't support bottoms up planning and what bottoms up planning entails is that GitLabers love to create issues as you know and we encourage that and that's a good thing and so with bottoms up planning what you do is you create a bunch of issues and you know prime managers designers engineers get together and they have all these issues and you you combine all these issues and you put them into epics and then you say you start saying this issue belongs to this milestone this issue belongs to another milestone and so what they want or what prime managers have said they want is that they want these epics start date and end date to automatically inherit these the milestone dates of the issues themselves so currently we do not support that and once we have that once we're able to add issues to us to say here to any so let me let me give you a better example say we have this would be a great example of a epic that has a bunch of issues there's three issues here and suppose the start date and end date of this epic automatically inherited the the earliest start date or of all the milestones assigned to these issues and the latest end date of all the milestones assigned to these issues automatically then that's what GitLabers want or GitLab product managers want at least as at least that's what they've been telling me and then that start date and end date would automatically be populated here or it would inherit it would be dynamic actually and then the bar would just reflect automatically so this is how GitLabers plan primarily they do bottoms up planning and therefore with that type of bottoms up planning the roadmap bars would automatically appear GitLabers don't need to set another start end and all they need to do is assign milestones and GitLabers love assigning milestones because milestones already have a start date and end date so that's exactly what these two issues entail this issue is about so I'll let you read the details and so the purpose of this video is not to go through the details but it's just to give you that background context of why we're doing these issues or these features and and also to get you thinking about them and to as you review the designs to to say I have a better way to solve the problem the idea of this video is to provide you that context and that problem and to think about it before we chat about it in our subsequent meetings so as you see on the this first issue is about adding more fields to our to the epic so right now an epic has a start date and an end date and these are fixed fields right you set them and so what this issue is and I'll show you the mock-up in a second that Pedro created for us it will have another field that inherits the earliest start date for milestones and then it'll inherit the latest finished date of all the milestones so the idea here is I'm just gonna click through let's let's look at one of these I think this let's see this might be a good one here yeah you see it here is blurred over so let me let me just click on this one that may be better yeah so you see the plan start date there's a fixed version and then there's a from milestones version there's a none so there's a fixed end date and then there's a from milestones so this one has as none so that's not very helpful let's go go for one that has some information already and so let's look at this one here so this one you can see the plan end date it inherited the milestone April 30 of 2019 so that's saying you didn't have to enter it manually it just got it from all the issues milestones and same for for plan start date and the idea is that you can choose as you see a radio selection here so as a user of the epic you can choose whether I want to use the fixed version or the inheriting version from the milestones and as a user of the epic they're independent choices and then so you can you can read through the epic to see all the details and all the edge cases and all the defaults I don't want to go through that here because you can you can read through that and we can talk about that in a meeting later but you get the idea and so once we have that once you've decided what is your let's see what's your end date and what's your start date then the road map should automatically interpret that as well so the start date here and the end date there it should reflect your chosen selection so so once we have this issue here for the epic this subsequent issue is just about fixing up the road map bar edges to reflect that choice so I wasn't really sure from a technical perspective if we even need this issue you might need to combine the issues but you can see how these two issues are related together and you need to work on them together for it to make sense but you get the idea so go ahead and scroll through the issues comment on them and then we'll chat more as we do the kickoff meeting later in the week