 Cool. We are now recording. So thanks again everyone for attending the first managed monthly meeting We had a technically our first one We were at summit and I spent some time talking through the slide deck and about a little bit about manage itself But I think it's the first one we're doing on zoom So super excited to to dive into the to be agenda with everyone. So Thanks a lot for adding to it over time. I I guess we have no accomplishments to talk about I'm hoping that we will in the future and we can use this This meeting to kind of celebrate some of those wins and awesome stuff that we shipped if we hit our okay R's in the future It would be great to use this as a celebratory moment But but I think Dennis you had like the first the first comment under concerns or questions Yeah, I was just trying to Understand like the definition of what is a the deliverable likely to or anticipated slippage So issues that are likely to slip. So I was just trying to figure out like what? What is what does that entail exactly and I you answered that in the Doc, but I don't know if you want to extend on that as well Yeah I mean just more context is that in the we have the in our Pre you know kind of like planning cycle that starts off with like product kind of meeting with EM's and trying to do like a Pre-planning session and the goal of that is to basically come product comes with you know a list of features and you know Future related issues you want to ship and then EMS can and we kind of collectively represent bugs and tech debt We kind of come together on like what exactly we can ship But since we're doing that in the middle of the release cycle, you know There's some stuff that might slip out of the current cycle and influence our you know The future planning session and our capacity So that's what that list is it's just like, you know If we haven't started something our confidence is obviously lower than it'll actually get into it And so it's just for me and for product to say like oh, you know We don't want to kind of over-connit We want to make sure that we leave a little bit of room in case you know important things slip because if they're worth working on in the In the current release, they're probably still high priority for the next so that's all that that's all that conversation is Yeah, that makes perfect sense Yeah, I was just trying to get understand the detail of when you covered it It's like what hasn't been started what is in dev What's in review and like the different ratings of what would be like different levels of anticipation I guess for different levels with it. So yeah, thank you. Yeah, yeah Cool and Liam you want to talk about everything else issues? Yeah, absolutely. So I'm not sure this is in the right section What we've been sort of concerns or questions. It's more about since I joined I guess one of the things that I found more challenging is trying to Understand the remit of the team and I think that's basically because obviously when a split from platform happened Which had kind of a really wide scope and I think it was very much was to sort of be everything else team and I think create got quite a Clear scope in terms of what they're responsible for And I think managed it as well But I think there was there's quite a lot of things that maybe don't fit necessarily nicely elsewhere And one of my feelings was a lot of those issues were coming to manage I think they are but it also seems like that's happening with other teams as well And so it seems like there's a lot there's a lot of issues at the moment That we're just not able to categorize particularly well And I think a lot of them are around kind of not necessarily technical debt But technical improvements and things like that and the main point of putting this on on the agenda was just to point people In the direction of the issue that has been opened recently And there's a good conversation going on there at the moment as to what we do to kind of solve this going forwards and I think short term we're going to try to um It's going to be encouraged at the pms try to kind of evenly distribute some of these issues Some of which I guess will naturally fall into teams some of which won't And at a longer term I think there's going to be a discussion as to whether We have a specific engineering team who who takes on the seemingly sort of everything else issues And no clear solutions as to the long-term plan yet, but certainly have a read through that that issue because I think it's It is definitely worth well doing so Yeah, I feel mixed. I mean, I think one of the Suggestions floated in the issue is actually creating like a specific team for it. I'm personally against that I think that the main problem is that someone There needs to be like someone that represents like the priority of these kind of like everything else issues And I think that who the team that actually works on getting it done You know, we can we can kind of load balance between the teams um, I just I think that that's the main the Making sure that the prioritization is understood and being well represented is like the main problem in my mind Because if this falls into the crack It's always going to be secondary to like all the important stuff that manages like working on right now That is that there's a clear owner of like that's you know, unless it's some, you know massive security hole like one issue is like this fuzzy kind of how do we perfect sequel injections in the future? And there's no clear like Proposal in that issue But if there's someone that's actually like Kathy from the security team who's like responsible, you know For pushing like that forward and saying like this is something that we need to solve Then at least the ems can say like, okay Let's let's let's look at, you know our road maps who might actually be able to pick this up and then just say like create You're gonna you're gonna pick this up and and move this forward So I think that that's the real thing that's that's that's a gap in my mind It's like who represents the priority and that that I think should have clear ownership Yeah, and I think that was a point of doubt I made on that issue It's almost where where everybody owns something then often nobody owns it because you kind of have that bystander effect So I think that's much of what the conversation in that issue is around So if nothing else, it's quite an interesting read and I don't think we're close to kind of coming to that long-term solution yet But um all input is of course, um going to help us get there Cool cool So James, I think you're next on the SAML issue. Yeah, so this was an issue where I'm adding a simple button Originally, um, but then it was suggested that we should disable it when there's stuff in the form Because otherwise people might lose the things they've entered so after you actually it started to need front end and It's I managed to write that in JavaScript, but it turns out that we're not allowing jQuery anymore so that's stalled on that And also it most jQuery is easy to rewrite but the tooltips part would need to be moved to view so That I'd need front-end help on that or I'd need to learn view so I could have done that from the start Might just be a really good 201 session Yeah, like something on how to get started in view in our code base that'd be really useful So I've built some apps of my own in it, but it's very different to The way we we structure things You're happy to jump in like call with you if you want to go through that Just a quick question. Um, were you told like in your review that you shouldn't use jQuery or Like what is behind that thought? Uh, yeah, so in in room I uh, the first part of view someone said we're not using jQuery as much anymore. Um And I think I could have proactively Sooner kind of asked like what's the best way to approach this but um in my mind It was originally similar to some other code. So I kind of took use that as inspiration so another thought is that um Like uh, similar to how we use rubric op and rules that and exceptions if we go back and add exceptions to the bases Where we've used jQuery and that will kind of make it more obvious that that's not something we encourage anymore Yeah, but if it is And it's only if there's already existing jQuery or existing JavaScript It's better to use one either JavaScript. It's that is also possible if we have We have some sort of jQuery black in there. I think it's a very pragmatic and very Very usable choice there. I will have a look at it because we shouldn't do just view for the sake of view We should be pragmatic and move stuff forward in there and yeah, I will have a look cheers Sorry, do we do we have any guidelines in the handbook outline kind of what we should be doing in this space Kind of like best practices are I think we have a few different pages So I kind of I looked for that and I kind of saw style guides on on how to write the jQuery And so I kind of took that as uh, yeah, it's allowed. Um But it's there's different areas. Um, so I I feel like I might have seen something that suggested the other thing when I went back and looked but i'm not sure where Yeah, we've we're working on a new front-end guide as well We still have the existing one as well. So we haven't merged all that in but we do Generally discourage the use of jQuery, but if we're working in something that's already 90% jQuery and you have to make a one-line change then it's like Preferred to do vanilla if you have to use jQuery then that's okay, but it's not crystal clear But generally we're kind of moving away from it The other thing related to this is part of the thing that made me not Pushed me away from view slightly is I need to rewrite the views that we'd kind of Done on before So that might be something where we don't want to Do a back-end feature then as we start to build out the front end and make it more complicated We don't have to rewrite things. So maybe um, yeah, so Yeah, but in this case, I think what andre because I had now a look at it what andre man was less He wrote that you might be also an option But in that case it would be the main option would be vanilla JavaScript so that we can Simply skip jQuery and perhaps then is or Martin you can jump in here to Get this one alert. It shouldn't be too hard. I think it's only two files and You simply need to change some queries over there. Yeah Yeah, that'd be that'd be really so I think the jQuery tooltaps is the only bit where where it might be a slightly more Yeah, I think it makes sense to to use vanilla chess or even jQuery if there's a lot of vanilla and jQuery stuff on the page already so I was in a similar situation with one of my issues where I decided to use jQuery just because All the other parts of the page were written in jQuery and it didn't make sense to just introduce a new feature in you there Just send in maybe you can post an issue and then we can look have a look at either then is or me and check How we can write it in vanilla chess cool, um moving on so, uh, andreus posted a Item here about ambitious planning I'm not sure if everyone's aware there was a merge request that was merged that Talks about ambitious planning to the product handbook and the direction page and the TLDR is that instead of Hitting 100% of deliverables our aim will be to plan aggressively so that we actually aimed at about 70% of our deliverables um, so we'll intentionally be kind of you know Over you know overshooting this kind of stuff that the number of deliverables that we hope to To deliver in a release As a result of that stretch may be going away In favor of either stack ranking or using prioritization labels I'm personally the favorite of the latter for reasons that I articulated in the issue But we'll we'll see kind of see where that conversation goes But it looks like the stretch label may be deprecated in the very near future And we'll just you know over stuff deliverables and then prioritize those somehow and then use that to educate Like the order in which we get things done in a particular release so We'll see where that conversation goes Would you already target uh for this release the ambitious planning of 70%? I think I think yes Yeah, yeah, I would say this next release the 70 number is uh It would be the goal I think that you know the only thing that's tbd is kind of how we order the issues across gitlab But on this team we've been stack ranking using the board, um, which is the next is the next item, but yeah Lean would you agree with that? The infinite definitely agree Cool. Cool. Does that work for you as well, Tim? Cool cool So I wanted to talk a little bit about release So like we just mentioned the like we've talked about using this board kind of for stack ranking issues And the one thing I just wanted to mention is that we I I changed the link on our Manage page so that actually points to this board here and this board which I'll just share super briefly Uh is the prioritized label which now only has like so there's 19 issues in back ends 16 in front and 11 in UX And the idea is that like it was super unmanageable for me because before there was like 100 issues in back end It was impossible to stack rank them all But now the scope for this board is basically what we're working on the current release and what's coming up in the next release And that's it and the stack rank should only be about 20 issues in each particular list So, you know, if there's ever a question like what our near-term priorities are and like what the order is It's always this link top issue is most important kind of moving on down So this at least breaks down like the issues that we think are the most important for us to kind of tackle in the next Release and then the ones in the order in which we should kind of consider doing them the point, you know if the really the um deliverable plus milestones should always represent like the Aggregate number of issues that are, you know marked as deliverable and then we you know hope to hit 70 percent of um at least and That board should kind of define the order in which we do it and again Like that might change and you know evolve into like p1 p2 labels or whatever But for now the board is a single source of truth and that stack rank kind of tells you what the priority is So I think Liam had a question about you know comfort level there Yes, definitely just a continuation really of the points that you've made there So I just wanted to make sure that everyone was kind of happy and understood What the new kind of prioritization process looks like and kind of what you should be looking to do when it comes to pick up Picking up new issues. I know previously obviously we used to do I think probably more work up front in terms of waiting the issues And I think often at least it seems to case when I joined we used to assign a lot of the issues to engineers up front And I think generally we're not doing that now I think there's some issues where maybe some work has already started or it makes complete sense to assign them And I think the the method we're moving to is having kind of just a Long prioritized list in in terms of the backlog and then when you're ready to pick up something You sort of pragmatically pick up something that's if not at the top then very near to the top And then obviously that that coincides with what Jeremy was saying about the prioritized and prioritization label And I think in a doc as well where I've Highlighted issue boards that take you through to a border. I'm using which I found helpful And I think generally that's probably the same feel so that everyone else is using but I just wanted to make sure that that was clear and everyone understood and We're not going to be kind of picking up issues that that maybe aren't a priority due to kind of Me or maybe Jeremy not not communicating clearly Yeah, and one goal is to kill the spreadsheet like the the spreadsheet that I've been using I think that I'm going to continue to use that with Andreas to help our own planning process again, like you know So we don't have like 500 issues that have the prioritized label. It's impossible stack rank those will live that list will live in my spreadsheet But you know the Pride the immediate priorities of what we should be working on this release and then the next release Should live on that board. It should be very clear It should be like just a handful of issues that are very easy to kind of like to crock So i'm love to get feedback here or and async on like whether or not they make sense So if people find it confusing you can improve it Would love to get some feedback It'd be a shame to lose that google sheet code Jeremy. It's awesome You get that printed and frame Oh god I'm sure all the printenders be horrified at my javascript capabilities I The only problem that I see and and I've seen in the past is simply with dependency management because this means that there might be The first frontend issue is number four Bacon has only capacity for the first three What happens then um That's a classic problem in such Circumstances and sometimes the other problem that I see so that uh most probably we will keep a size Issues simply based on the priority list, but we want to assign issues from the front and side at the beginning Is also what I see sometimes is especially if you get new people on board And number three is a eight super hard one Then of course this person will not pick up the number eight and the super hard one But then rather an engineering manager should have the Feeling okay that person Is capable of doing that stuff or that person needs some Has already super advantage knowledge about exactly that screen. So perhaps number three is better for that person. So That's that's something that uh, yeah gets complicated with a rather with a list of pick up Yeah, so so I I agree with you and that's kind of why I like the the p1 p2 method a little bit better than stack rank because you know if you have a situation in which you have a junior dev versus a new dev and You know there you can at least look at like the the p1 issues Maybe there's four of them or something and you can say like well It doesn't make sense for them to pick up, you know Smart card or some you know hard authentication problem But there's other p1 issues that are really important that they can kind of dive into and it's very easy for us to make that The student product, you know Whereas in a stack rank, you know, it's just a top issue Which you should technically always pick up, you know, um, and then you kind of have to say well Maybe it's second. Maybe it's third and you know, it gets a little fuzzier Um, and then if you have the p1 p2 strike if there are dependencies you can prioritize like The you know the the first issue that needs to be done whether it's front end or back end or whatever Like first and make sure that that gets picked up first by that team um and so forth so I I that's why I personally like that and I think that the dependency issue gets reduced a little bit if you have Separate issues for each one which this team has been doing Like we've said specific product discovery back in front end issues And if there's back in that needs to be done first then that goes to the top of the list Or they get to p1 or whatever so they get to picked up, you know sooner rather than later So I think that you know, these are tractable problems But I agree with you that you know, we just need to be thoughtful about them as we look forward And I think it's almost when we when we assign issues or the only reason we would maybe assign issues Is to solve some of those problems So it might be if there's if there's an issue that's absolutely urgent and it's related to subscriptions Then because of the urgency we may just automatically assign it to to Reuben because he has knowledge in that space Where if it was less urgent the preference might actually be to have an opportunity to do some knowledge sharing and And basically somebody else pick it up as and when they get around to it Um, I guess that's something that we have to be sort of pragmatic with and if anyone notices that you're finding it Harder to pick up issues or to understand issues because they're not in your Usual domain area then obviously just just sticking out in slack and we can we can figure that out But at that point if we know that it's like going to go to someone that has that That domain knowledge and that would already be pre-assigned, right exactly that exactly that. Yeah. Yeah Cool Uh, so on that note on 11.5, um, again Feel free to kind of take a look at the board spend some time looking through the issues kind of thinking about it But at a high level, I wanted to share what that's kind of looking like at the moment um, so on the back end side like the Priorities that have talked kind of talked about from a product and customer perspective that remain really high are billing and The smart card off smart card because there's just it unlocks a lot of business in our public sector again And then on billing there's just we have lots of improvements that we need to make To kind of help our customers answer questions and manage that So those are in me like some of the biggest priorities you can see like the smart card and Back in support for some billing improvements is kind of top in number one and two in the list But I think that right now the biggest thing that we're facing for 11.5 Is just a lot of bugs that we kind of need to crush before we can really move on There's I think I think seven or eight p choose Six of those bugs right now on the board are security issues So that's kind of you know being a serious headway towards more more progress we can make on back end So we need to burn some of that down On the front end side, like we're working on some really exciting things Chris Peresini worked on some design routes some really awesome improvements for billings or License page for self hosted in dot com So we'll work on getting those in along with like this new help menu which will help Improve our navigation to a big degree and then some awesome awesome awesome improvements to make the product make it land more lovable than project project improvements tool tips and the better activity feed Which are all really exciting On the ux side, we're going to keep moving and we're going to keep working on billing improvements I think chris is going to continue to work on like customer portal stuff And how we can improve the billing experience and payments for customers Um dev ops score versus cycle time is something we're working on and then also I think Matei might be working on a really really awesome Personal dashboard features that i'm i'm pretty excited about So that's kind of things at a high level. Um, you know, we're we've been prioritizing the billing work and we still a lot We still you know, it's we're going to start making like the first improvements start implementing the first First improvements there and then continue to make progress on billing and smart card in a lot of these kind of UX UI improvements for uh to make it a lot more lovable So that's kind of how 11.5 is looking right now Feel free to kind of take a look at what's on the board right now And that there's things that are missing or if you disagree with the with the with the ranking, please Please let's talk about it Cool over to you sonad I was in the middle of adding it um Yes, so going forward, um We should plan on delivering the qa automate automation test the entrance test along the the future So In the same way that we deliver documentation When we with our merge requests So i'll be reaching out to developers who are working on on their respective features to help them understand the uh The qa test the qa automation test base if they are not yet familiar with it um, and I will be also helping them contribute to it James and I had a session on on on saml Entrant tests and I did post a video on the group channel as well um So yes, just calling that out That we should keep that in mind while planning Our The delivery of the features so sonad, what's the What needs to have what what do you what do we mean by keep things in mind like is there? um, do we need to make this Like us like a definite part of our kind of definition of done when it comes to new features Um, I I know that quality there was an issue in quality where we were trying to debate Like how test plans kind of fit in I don't know I don't recall if that issue kind of went anywhere, but um, how do we how do we write this down? How do we formalize it? So we do have We do have a page. I'm going to post it over here in the Right here hold on So so there are some updates to uh, the test planning process and how the uh, the test plan fit into uh, the release so Coming back to your question We we have to we have to integrate uh The automation test as part of the It should be a deliverable In the same way the documentation is a deliverable for a feature So when I said we have to plan ahead I meant that we have to keep in mind that uh, At the end of the release. We are also supposed to have the end to end test in place and the merge request is in place How how are you sort of determining the Scope or depth of the end to end test that need to take place on each issue Is that a conversation with the engineer? Is it a conversation with product or maybe a stakeholder or a customer? It will be a conversation with the uh with the engineer and And the test plan would be would be there to guide the end to end test So, um a decision would be made in in collaboration with the test engineer Uh on on the scope of the uh end to end test Does that answer your question? Yep. Thank you Cool. So when does that conversation take place? So does that does that happen kind of during feature development? Well, we're talking about developing the test plan in parallel with the future and then at the end, uh, we kind of make that a yeah, like like you said Like documentation a condition of Of our definition and done and getting this merge and production So the test plan would the test plan would be Would be created at the start of the release And the conversation would be like ongoing throughout the release The test plan would have the the expected Expected tests or the coverage that would be needed and as the features being developed The test engineer would continuously monitor What tests are being added and at the end of Nearing the end of the release um I think that's when that's when the end to end qa end to end automation tests would be added But again, um, it would be a high level test and uh and something that the qa test engineer and And the and the back end engineer or whoever is working on the uh on the feature would decide together what needs to be covered What kind of features um, do we expect To do these end to end tests for because it's something like somewhere out there where there's a lot of setup It's really useful to make sure the configuration like everything will work in reality But for a lot of smaller things like uh That's not Exactly We should not have interest in tests for everything like Not every feature not every small feature that we develop or deliver as part of the release would have end to end test uh For those that would require end to end test we would We would have a conversation around it and then decide. Yes. We need we need something more here So is this something that we just pick up in review? Like would say this is missing end to end tests and at that point go back and then for the future get in the habit of planning for them um, if I I don't think I industry your question correctly But for the feature that we are we are developing as part of the release For the larger features that would warrant an end to end test. Uh, we would discuss throughout We would discuss it During the release And then decide that we need to have A label or something on the issue Yeah Label just had sorry. Um, did you mean A small feature as in label? No, so so if we um Decided that this would need end to end test would it help to have a label that said this this should have end to end test And so that when a developer picks up even if it's a community contributor, they know that they've kind of got to add end to end tests Yes, that kind of makes sense and it's a good idea um Yeah, we we can think about adding a label for um for something that would require for a feature that would require an end test. Yes Well, can we make it just part of like the mr template to like ping? I don't know You know Remy or mech or someone on quality or to sub for for that for someone to say like either you need to have someone sign up and say this doesn't require end end tests or Link to the test plan and you know that needs to be part of you know of what gets merged So that this check happens when you create the mr I don't know we don't we don't have to discuss it here But I think that I think my point is that like like that James was kind of alluding to like it would be helpful if there was like a specific check or mechanism or a discrete way of saying like This needs end-end testing. This does not need to end end-end testing Um, and that would be really helpful in helping us kind of like identify what we need to do Because I become I would prefer it to be less of a of a judgment call. There should be like a very discrete kind of way of telling um, yes, that is uh, there's something that we can talk about and um How how about if we if if a feature has a test plan associated with it then, um, Then we have then the developer looks at the test plan and The test plan would clearly say that we need an end-end test for this If there's an assault, so if there's an associated test plan Uh, go go and look at the test plan The test plan would clearly have an indication of adding the End-end this Okay, um, that might make sense I you know, let's let's let's talk about it. Maybe an issue or in an mr to the handbook um You know, I think that that makes that can make sense I'd be concerned about cases where you know, you're really busy the test plan doesn't You know, isn't isn't available that that's a precise moment But you want to do it in the future and then we you know I think in the meanwhile it gets merged without actual without us like keeping track of like the need for the testing So, you know, and that's why I think that's something very lightweight Just like either a checkbox or a label or just something to say like this needs it And then you know, we either check the box or remove it when the test plan gets kind of like fulfilled Um, that way if we miss stuff along the future, we can just like filter by you know needs test plan And then is open or something and we can very easily see where we're missing coverage Um, so I'd prefer something like really lightweight like that But we can discuss it offline in like another issue or you know with the rest of the quality too Yeah, sure. Thanks for bringing bringing that up by the way and I do like the idea of for of the label Um, but we will still discuss it Cool, I think an issue will be good It'll be good to get input from other teams as well and even if they don't have something like this in place So maybe they'll they'll find it useful All right, I'll I'll add it to my list For talking this through with the quality team as well Thanks a lot. This is this is important. So, uh, we just want to make sure we get it, right? All right. Thanks. All right. That's it for me Cool on the okrs. So, uh, I wanted to talk a little bit about okrs Um, what we've got so far in the okr page for the managed side Um, was what you see there sourcing team um I wanted to talk a little bit about okrs. Um William and tim does that kind of cover the okrs that are there any existing mrs or discussion that I'm that I didn't cover there Or is that kind of what what the status is or what's on the page? So we have over all for the frontend engineer. We have frontend okrs. Um, and There are two okrs who Are valid for a match so overall in the frontend team we want to hire two more managers and 10 more engineers uh until the end of the year so What will happen is that we are actually spreading them out Based on priority and I'm touching base as much as I can With all the different product managers and all the team members of each team to figure out When do we need or where do we need the the next engineer the most urgent? Currently, I think with free frontend engineers manages has even the most in one specialty. Um, so let's see How this works out and how soon we will need another one But at least definitely one more frontend engineer will come to the mage team until the end of the year. That's for sure Um, right now it looks like that we will even be able to fill all those positions in the next weeks. We have Two already in offer stage two more are in the final check stage We have I think 600 more applications to go through for the other six So I think we should be fine To to fill those positions as soon as possible and also to get With of all the interviewing that we that all levels in the frontend department currently doing So that's part of the manage, uh, ok rs and the other thing is that we um, uh, we'll have now the quality the dashboards that quality has created about the the error budgets and through them, uh, we want to We want to count and keep track of everything that Was created on the backside. Uh, that falls into the error budget for manage So we will have a board for frontend for manage and figure out that we keep our error budget Yeah I think i'm i'm quite envious of those numbers on the on the hiring side because we're not having quite so much luck Um from from the back end, which I think everyone everyone is aware of I think there's various different reasons why and I think tommy's kind of been assigned a personal mission of figuring out how we can Kind of increase the flow coming in And I think we've got about five candidates at the very start of the pipeline at the moment specifically for manage And so so fingers crossed. Um, we can kind of see some progress there But I think the the number that tommy was shown yesterday. I think it's a we're hiring pretty much about one percent of Um applicants that we screen. I think it's one or two percent. It's not a big number And so kind of The good thing there is we have data around this now And I think we're trying to use that to figure out where we need to focus our concerns And to kind of pick some of those numbers up And but I I would you know, I I don't expect To be to be making any offers within the next week or two given kind of what the pipeline looks like Hopefully this time next month while I'll have some better news on that And at any other one was obviously around the sort of the specific team initiative Um, which was specifically on the two way one session and another sharing And and you know, I I think I There was good feedback when when we suggested taking that on as an initiative I think it actually may have been in re who said it seemed quite an ambitious goal And I think in part it is I think, um, you know, if you look at doing 10 that that's nearly one a week Um, and I'm sure between all of us, you know, that that's not kind of to actually run that session Maybe isn't a huge undertaking If you want to get value from them, obviously we want the majority of the team to be part of those sessions And so I think you know, this is a great opportunity. I see James You've already made a couple of notes as to topics that we could discuss And and it would be great to see input from from everyone and hopefully by the end of the quarter I'll have some value to add there as well and and hopefully I can run more myself Cool, um, maybe we should open an issue on topics and we can kind of drop Yeah, and drop these ideas in overtime I will take the, um, I'll take a note to do that Awesome. Perfect. Perfect Do you have a link to, um, where you described the structure of these? And like is it to the rest of the team and like, how would we go about that? So I don't know if I understood I understood all the questions that I've got a link to the, um, the merge request effectively that we created to have the, um, to have it merged in Which gave a bit more of an in-depth description as to what we're trying to achieve with the 201s And I can I'll certainly link to that and I can link that on the dock. I don't know if that answers all of the question Oh, yeah, because I remember you mentioning it somewhere like you said it could the structure could have this for 10 minutes that for 10 minutes But I kind of I'm almost certain the mr covers that if it doesn't I'll I'll add it in and and I'll assign that or I'll link through to that on the dock Sorry, is this back in specific or is this for managed team? I just I thought I moved under the back end bullet point I was making sure Yeah, I think this is actually a bit of confusion for me kind of going through the process because, um It was kind of the the engineer and managers responsibility kind of As part of the process to kind of work with the team to come up with what the specific okr should be I know across some of the other teams there's kind of some back end technical debt issues that they've covered I am I would actually encourage that we make this seem my initiative rather than back end um Firstly because it means that obviously there's going to be more contributors and and more chance of kind of Getting some of these sessions out there, but I think it'll also help knowledge sharing And I think the topic that you and James were discussing earlier in terms of vanilla versus view versus jQuery Um, I mean, you know, they're the topics that would be really useful to be having as a team Yeah, that's a good point though Like I think 10 talks might be very aggressive if it's back in specific And I don't know if we've ever done like a shared okr between front end and back end I would I I would you know wonder if tim would you know buy into the to that okr I'm I Have a hard time seeing and push back at it but uh Experiment and on the other hand, I mean the reorganization is going exactly in the direction So why not started already? Yeah, it's less the okr and more of this this is useful. We should And just to clarify so is this something we do like a presentation where everyone kind of watching Is that the audience? Yeah, I think so. So I think it's an open invite I mean if you're comfortable just doing it with the team That's fine if you think it'll be useful to the wider team So specifically in terms of you know, how we address some of java script concerns And you know, I'm sure like every team would good to get some value from that And so I guess what as and when we come up with the topics we can Can probably determine who you really should be And I had a really good conversation with tommy when we come up with the okr about the different types of metrics I think he he has a definition of kind of a A lead in metric and a lag in metric and I think the metric that I've created here is effectively a lead in metric Where it's quite prescriptive in terms of what we're trying to do kind of we're at the beginning We're saying this is exactly what we want to achieve As opposed to saying we want to see a result and then we figure out almost a journey to get there And and I think the reason say if you think about what we want the result to be it's increased knowledge share And it's increased team collaboration And I think certainly the suggestion of having all of the team involved And you know, maybe it would be even be great if Jeremy and I did a session as well in terms of kind of That the things that we're focused on and then Certainly in a more than area. I think anything we can do to help kind of cross collaboration would be it would be useful Yeah, I'm happy to do one as well But the way that I've been thinking about these two of ones and you know, this is me in a vacuum But if I were a developer and I was working on it like an an audit event issue or like SAML or something What is a video that could live in google drive that I could just double click on? Watch, you know, maybe there's some interactivity in it where there's I can actually get hands on and like get a really good overview But at the end of it kind of have an at least a very high level of like How that feature works in git lab and how I might be able to dig into whatever it is that I need to work on So like obviously you won't be able to get you know a comprehensive view in 30 or or you know, 30 to 60 minutes or whatever But at least gives me an overview of like how do we track audit events? What table do we use what methods do we use well models? I need to worry about To at least get me started. So that's kind of how I've been thinking about it Cool. Awesome. Sorry I so I had the You know, like, you know, I asked when we should start the answers now. Let's start student SAP So hopefully we can even create that issue Get to get something on the calendar sooner rather than later. I think that'd be a goal There's one thing so I think that there I thought that there might be a features level okr I don't know if there's other okr's lay up going on I know that yob asked me for like the features that we wanted to hopefully ship in q4 if we could ship nothing else Those were the three that I provided To him. So that might be that might pure is an okr at some point The last point that I had and I'm going a little quickly because I know I wanted to make sure we get the show and tell You know, does anyone follow a care about okr's and how can we make these more valuable? I think that I would just love to see us like keep track of these okr's keep talking about them on a monthly basis in these meetings so You know, at least we can keep an eye on like our progress and kind of how we're doing because I don't because as a product person like we don't Really talk we only talk about okr's when we set them and you know, kind of when we uh, when we you know, push the hand But the the handbook and like what happened But during the quarter, right, you know, I feel like we we can we could talk about them We can keep talking about them in this meeting Um I had this point here about uh team vision page and then sharing with git lab There were just two links that I wanted to make everyone aware of The one first is the first which you can see there under vision Which is kind of the page that we're using to kind of talk about the overall scope of the DevOps manage kind of in the in within the DevOps lifecycle What we hope to what were what our scope is what kind of the vision is for what we hope to achieve in the future Um, there's obviously content there that that page will continue to evolve over time Um And then do we have obviously the team page which is more kind of you know, how we operate as a team Uh, kind of the process that we use in order to make that happen So the first is the vision for like that Stage of the DevOps lifecycle and then the second link is the team that actually gets us done Which is this this group obviously, um, and then how we kind of function operate as a team So if you haven't seen those links take a look, you know, these are obviously open to mrs And I will continue to add to them over time um And the last point was that manage, uh, there's a there's a issue there link manage is going to start doing FGUs Um, we'll we're trying to figure out the date and when and get get these on the schedule But um, once that's done, we'll figure out a template and then we'll kind of probably rotate presenting responsibilities Um in terms of in terms of that I'm sure Liam, Tim and myself will probably take a leading role in the first one And then we will uh, we'll kind of hopefully rotate that around on a monthly basis. So that is uh, that's coming All right, so show and tell so if you're not familiar with the term show and tell it's a very american-centric term And show and tell is something that you kind of do in elementary or primary school generally as you're a kid and you will like you stand at the front of the class You show off something cool to the class and you tell people about it and that is show and tell um, so I Thanks a lot for i'm going to turn turn things over to dentists Who's going to do a little bit of show and tell about some stuff that he's been yes Or you cry you're afraid of your presentations or we're all friends here So uh, so dentists over to you, uh, we'd love to hear about what you're working on and uh, and see a little See see see about it. So over to you Uh, just for the record, I have not cried giving presentations. Um, get really nervous when I was a kid, but I have seen that from classmates, so Not for everyone, I suppose. Um, cool. So first one i'm doing is just to set user status in the modal I'm just doing this one first because I have to fire up the uh enterprise gdk further the group level project templates Which Rubin and I have been working on so we'll just start off with um user status, so it's pretty straightforward. Um, so previously I mean, we just recently launched user statuses, right? And so right now the current way to do uh to update or clear your status is to go through the settings edit page, so um I think the main goal is to make this more accessible So, you know, if you're in some random page of get lab or to do or whatever you can just quickly change your status From where like wherever you are on get lab. So in the user menu, you have this option here It actually displays your full status. Um, of course, if you have a longer one it truncates and just shows in the tooltip and um, you have the option to clear edit or Yeah, just basically set your status here. So if I just remove the status then just sets everything um resets it Back so if you're if you only use it for like your out of office, then you can just go back and clear it And then you can same basic concepts with setting profile the profile setting page, so You can set your status and then you can also do the whole emoji auto complete within Set it and you're good to go one caveat that we have right now that we set up this follow-up for is that I'm currently reloading the page just because We have to update the status and to update we have this issue in A number of places where we change some field and it doesn't update through the rest of the page. So right now Um, it's reloading the page just so we can update that in not only in the drop-down But on issues and merge request pages or other areas where we display the current user's status so that's Something that we're going to continually improve but for now It's just a more accessible way of updating that Then I'll pass it on to uh, germy It'll all I fire up next dk. No, that's there's any questions. Yeah. How does this look on mobile? Uh, great question. Um, it's Not bad The flyout menu is a little weird. Um with the emojis If I go here and edit status, uh, it's It's fine, I should say But there is some Consideration with like having like a layer on top of a layer and selecting everything still works but, um, You know, it's just a little bit smaller. It's responsive, I guess. So I don't know if that answered your question But it's still functional, right? So Yeah any, uh Anything going on under the hood that I don't know was That surprised you or What anything any like challenges you ran into on the way or was it all pretty straightforward? Um, it's the classic story. I think Tim's very familiar of this as far as my time at get lab is where it seems very straightforward at the beginning but isn't um because the Code that we use to set the status in the profile settings page is a mix of hamel and jQuery and vanilla javascript. So kind of The same problem that that james was encountering as well and so, um That required some I'm finessing particularly because it's easier for us to develop these things in view Especially because we have to get live ui framework with the new modal and tooltip components that we want to try to push forward So getting that to work with so basically just to Provide more detail This emoji menu is in jQuery This uh, and then getting this to basically play nicely have this layer appear on top of the bootstrap modal Required some changing in the code. So, uh, it wasn't actually until this week that I was kind of doing that finessing. So, um It's it's a I think it's a classic case of as we're trying to move these things to to view When necessary at least vanilla that there's this integration that we have to do with jQuery or or porting or refactoring to make it all work and Also more maintainable because at the end of the day, we don't want to have to keep jQuery around. We want to get rid of it, right? so We'll continually find these areas in the product where we have to say If we just update this line here, or do we need to kind of fight the bullet and do a bigger refactoring But at the same time not refactor just for the sake of refactoring, right? So Yeah Awesome. Thanks. Any other any other questions? cool Thanks a lot Dennis. That was awesome, man. Sure Um, I'll fire up the e e gdk. Um, but if you can stall for me Yeah, yeah, no, that's good. It sounds good Uh, so the one thing I wanted to talk about and thank everyone for so we had three respondents to the september pulse check So thank you to those three people. Um, if you didn't fill this out shame on you Um, so I just wanted to say thanks and then also kind of run through their results real quick What i'm going to do is i'm going to Just kind of discuss them at a high level. We have only eight minutes left So i'm going to create an issue for all of the Interesting bolded points that I bolded and hopefully we can kind of discuss them async and then see how we can improve Um, so things we're going, you know, there's a lot going well One person kind of Love to see us deprecate the the google the the my crazy insane google sheet for get lab issues So hopefully the board is like a stuff forward there Stuff that we can improve at Was like maybe a team call we could not talk about work style stuff, but more hanging out in nature I think it's a great idea. I would love to see us do more there as well Um struggling at the transitions between milestones mrs to review issues to wrap up. It's chaotic sometimes Planning a bit further ahead possibly I would be keen to to discuss that see how we can improve there Second bold point was about identifying and solving problems of having issue slip Trouble with scope of issues when back in and front end are involved You know, I'd love to discuss of ways that we can improve there as well Like we already split out like back in and front end to try and reduce that but like there are always dependencies that You know may or may not kind of be the obvious and you know things get picked up Different time. So definitely definitely keen to improve there Um It's lost on how the meeting how the team is kind of meeting the goals for the iteration release or what the confidence level is meeting the goal Um, stand-up bot, which is still, you know to be configured. Um, I'll poke that issue again But there's there's probably other things we can do there as well, which we can discuss async Um any suggestion for managers ok ours for q4 I thought it was interesting that someone says I don't understand the current ones So we can obviously should make these clear so that we're all if we we have no chance of hitting our ok Or as if we don't understand what they are So we can definitely make these clear and hopefully the ones that we set forth will be will be clear Um, and then there's some great suggestions there on other things that we can we can be doing as well Um issues making time for user onboarding overhauling pages that haven't seen much 11 years I couldn't agree more. I would love to know if there are specific pages that we're really kind of keen to That we feel like need some need some love I have some thoughts in in my mind of pages. I'd love for us to get to But always, you know prioritization is always always hard Um, and then this that issue that's linked is is what is a security issue that we are playing to tackle 11.5 I think the idea of having like a general pool of issues that any team can just kind of pick up If they have spare time might be a really good one to kind of make like Stretch to like not totally eliminate stretch, but maybe make it like get lab wide especially for those kind of plumbing type issues I think that's that's a real interesting idea Um, so, you know the uh, thanks again for everyone that kind of proved that that shared their thoughts. It was super helpful Um, and I would uh, I don't know if it's worth doing this again But I this was this was really great feedback and I really appreciate it. So you can I'll take it I'll leave things there for now and then we'll take them into into an issue for more discussion But thanks a lot Does does everyone understand now q4 ok ours? awesome Yeah, please please please say no if they're not clear like if there's things we can do make them more clear Like they should all be be super crystal clear. Um, and hopefully, you know, as things get added They will they will not get any money or so Like I said, we can't hit them if we don't know what they are. So thanks Over to you Dennis, maybe Yeah, gdk just finished Giving it to business. Um, I was a little I was just going to fire Sorry, I was just going to screencast the the loading screen for a while or at least talk about the project labels But um, it's all fired up now. So, uh, the other thing I've been working on for this release is the fun and for the group level project templates, so I think it was 11 to be launched Or 11 3 One of the recent releases we launched instance level Uh project templates and you can define that in your admin area But something that I think what's much more useful is to define it per group and you can select a subgroup for you know creating templates within a given project's namespace So the way this is going to work is um Stolen you to Well, I can't think I can demo that But what I was going to say is that you can go on the groups edit page and define it there So for every group that you're in, um, you can uh define a subgroup that you can use as a source for your project templates I was also working on moving that in the settings page. So that's probably why that's not working But let's just pretend that didn't happen. And so when you create a project, um Uh, you can go you're in the blank project. I just clicked something else awesome Uh, so when you're in the project create screen, you have a tab for creating from a template Um, we'll see if it switches my page. Yeah, sorry Uh, so you can go to create from template and originally we just had built in and then we have custom Which will now be renamed to instance and then we have group Uh for the group level templates now if you're entering the project create page from just the general top level of navigation menu and you can see all the different subgroups, but when you select a Uh template it will go to that main Uh groups namespace But then you can change the namespace within that group if you want, but you can't go from Like h9b in this example belongs to h5vp. I can't put this under um twitter or uh Whatever any other group. So from here you can preview it takes you to the repo to look through it And then you can just use template then you go on your merry way to finish the rest of the project details And then you can create the project from there um And that's group level project templates. I've been working with rubin on that and so Yeah, any questions for this one Uh, I just want to mention two things. This is like really really awesome. There's uh, like this is This is going to solve problems at git lab like we have we need these templates for like the account management team who like they set up they set up a separate project for every account that they manage Now we can just templatize that and then make that really easy But those are obviously templates that we want to live at the group level We don't want them to live at the instance level. So that's super that's super awesome And then other customers who typically work with like uh contractors or external Customers really often and they set up like bespoke projects for each of them and like their project or customer group or whatever Um, they can just simply like templatize these and then make their lives. It's really really easy So really awesome from you know, it's going to really help our users. It's really great um The one thing I wanted to mention to martin though is that now like the Like the the the snow plow tracking that like he's been working on Are now it's immediately out of date because we just added like stuff to the project page So martin, I guess for context has been working on like adding snow plow click tracking to the project creation page And then now we now this this new functionality is going to be untracked. So I'm maybe we need to think about for new features Making sure that click tracking gets added along with those features or if there's a way for us to include This in the tracking that's being pushed You know, we we should consider how that happens because you know The he's he's doing awesome work on on the on the tracking side and now if that it's going to be out of date when the ships Yeah, I would I mean we can talk about analytics In a separate topic or issue I would venture to say that it probably made make sense as a checklist item For when you're creating the issue or the merge request of basically asking yourself Does is there anything here that needs to be tracked in terms of feature events? Yeah, but yeah anyways, yeah I think that applies to Most of the new features probably right because we might want to add click tracking to all the new stuff as well At some point. So I think the checklist is a good idea Is there a handbook page describing how to add tracking and everything about it? Um, I think not yet um But that's definitely a good idea to add something there because it's it's it's a straightforward process But you need to know how to do it and at the moment it's just documented in the code. So we should definitely add a Guide there topic for knowledge sharing Yeah, yeah, that's a great idea. Cool Thank you so much for the demos Dennis. That was awesome. And it's uh, really exciting stuff All right, we're over time The only thing I wanted to I will mention is please share your feedback about the monthly meeting. There's an issue there linked on 6a You know if you have ideas to make this better if you thought this was a giant waste of time like please You know feel free and unfiltered in your your feedback. So Thanks a million. This was awesome And we'll we'll leave the rest for uh for discussion and slack and and async Thanks everyone. Thanks team. Cheers. Cheers. See you around. Have a nice one