 Okay, so I'm recording. I'm gonna show you my screen and we can get started I'm in a restaurant. So the noise is a bit loud for me, but Jacob assures me the signal-to-noise ratio is okay. So please let me know if I have to shout. So we're doing charts. Yay So why are we doing charts in GitLab? For a couple of reasons because we want to give insight and analytics to people in a self-serve manner. So in the broader context We have been beating up our Chart ability in terms of like people who know about charting and data and stuff like that So we have a data team that that type of thing. So we have a lot of initiatives at GitLab for charting and analytics and data But and one of those Initiatives is actually doing the analytics inside GitLab itself. So we have a data team We have a lot on oh, we have we're using open-source tools We're using tools like looker to to get data and chart for GitLab purposes and short-term purposes But for for our customers and our users and for ourselves long-term. We want to be able to Bring data analytics to users within the product itself So that customers don't have to hook up something separate So it's pretty much aligned with our GitLab strategy and that we want everything inside the product So that's why for example in the monitoring team They already have a bunch of charts and dashboards That I should have showed or I should have pulled up earlier, but I'm not gonna do that because I don't know What to show immediately but suffice it to say the monitoring team or the monitoring part of GitLab The product has already a bunch of charts Which is critical for their part of GitLab and then for other parts of GitLab It is increasingly relevant as well and one of those parts is the plant or the plant side and so for the plant side We already have a couple of charts One of them is within Within the milestone view we have a burn down chart for Milestones so you can see a burn down chart here. So this is really great. It's within GitLab the product it works great, but We want to do a lot more. We want to give more detail. So even before I joined this call I was looking at some really cool things that Like this thing called cumulative flow diagram, which is very similar to a burn up chart But there's a little bit more information So I've just been trying to understand how this works and create more issues and things like that So the burn down chart itself If I could find again is an existing visualization in GitLab We want to make it more awesome and that's one use case of charts on the plant side of the product And another thing beyond the burn down chart is we want to do maybe burn up charts like I just mentioned So variations of the burn down chart. So basically any way you can For a team to know the progress of their iteration So for a burn down chart, which is obvious you can know that you know You're not going as fast as you should be maybe like this is the linear drop off, right? And you're going too slow here. So there's other visualizations to help you with that And so you'll notice that burn down chart is within a milestone page But we have an idea as to bring the burn down chart to the issue board itself as you can see here So bringing the burn down chart So this is an issue board as you can see and if you click the word The button burned down you would see these the burn down chart in the board itself already So you see the board chrome so instead of having go to the milestone page You can go to the board and you can see burn down chart away And so if you scope your board to what's relevant to your team in terms of issues and your in your sprints Whatever you call it then this is an immediate improvement So I just wanted to give examples of what we're already doing in Gillab in terms of charting Especially relevant to the plant team because I'm representing the plant team But you know the things that we're talking about today are going beyond the plant team, right? Because we're going to be probably the first users of some of these things are the technologies that we're going to invent And and so I mentioned for example the monitoring team is already doing some boards But likely they will want to refactor some of that We will want to use the new technology and apply to our existing designs for boards And and get parody in terms of underlying technology And then another place where you have visualizations is Places like this with contribution analytics Where you have information such as this and also with the Something like this you have this so all this to me is if it's not words on a page if it's not If it's any time of visualization data visualization I grouped that into a chart and I think At least for the folks that I've talked to on this call previously in like a pre-meeting about technology solutions I think you would agree that we want to you know Harmonize all that at some point inside Gillab and have a strategy to do that So so that's going to be the topic of today's conversations So before I get to that I wanted to show one more thing that to motivate this discussion Which is A vision that the plant team has is to just bring charts as I said, right? So we have the burn down chart as I mentioned and we have the A contribution analytics monitoring so there's an outside plan, but those are existing charts And then the third or fourth way is just bringing charts in general To the group level. So this is a concept I have here. So right now bring charts to the group level. I see two Two needs for that. So one of them is a need from the engineering side of the house And that's I would say represented by I think mech is on the call and mark is on the call And so they're from the quality team in addition to doing quality. They've been I believe Been tasked with let me see Charge showing issues created per month with improving our ability to Bring engineering type metrics. So engineering performance like saying things like how many deliverables that we miss How many bugs are we creating? so just, you know issue triage issue hygiene that type of thing we want to be able to Surface to users again inside the product Really easily and so our engineering department ourselves Had been using tools like looker building our custom tools to do that building off of the our gLab api But ideally we don't want Um, I mean I see ourselves always being ahead so that we'll always have extra tools But if we want to have our customer do use this we want our users to be able to click a button within gLab So this is an example of that. So I don't think this is a a really good View let me show I think it was I think it was this one So this is a screenshot of what's already mark And team have created which looks really awesome to me So this is you know gLab insights is a separate tool and so you can see things like Seeing things like bugs by severity and so stuff like that So you can see how many bugs were created and closed bugs and stuff like that So this is all information that we have inside gLab already. We want to expose it via a chart So that's one application of getting charts and data visualizations into gLab that's driving this work, right? So it's it's engineering type metrics that we would use and our customers would use in terms of per team or per department And yet a fourth or fifth if you're counting keeping track is What we're calling Value stream management and so we can spend a lot of time talking about it, but I don't want to do that and bog down this meeting, but suffice it to say It's just not just but it's a it's a new way of thinking about it Of gLab it's very similar to idea to production where you have multiple stages of of of gLab of software development and Let me see if I could find I think it's this one So Right this one has it so the idea here is that if you have gLab and You have a board something like this And so you have the first stage might be You have idea you have a concept and and you want to share with stakeholders and then that idea becomes You know a design idea, but you need some design work and then It becomes architecture requirements phase and it becomes Database requirements phase so depending on your organization you might have a lot of pre-work or stages or sign-offs before you get to even development And once you have development there's code review and then sometimes some teams do code review before qa Some teams do qa After and then then some companies have uat user acceptance testing And then you might have beta alpha beta gamma and then you might you know canary and then it goes to production So if all these stages here and so you want to quantify that you want to say how much time is it taking and so on and so forth So within gLab we have many ways of doing that or we characterize that in some ways But we haven't really given a customized way to do it yet And so that's yet another reason why we want to present um This type of chart here inside our charting Customization so you can see in this particular chart Within january the ready in dev stage on average took Or in february to five days and then the in dev stage took six days and qa took 15 and then seven And then it improved over time and so on and so forth So this is just a a sketch of how that could be used From what we so-called a value management is value stream management perspective So let me stop there and take questions and comments and just open discussion before we get to the technology Implementation on just various like if you just have you want to say like oh my team is doing charts Are thinking about charts this way and you just want to talk about it for a couple minutes Let's do that. So any other comments questions About charts and usage of charts in general chart or graph I have a lot to say about that. Here you go. But any other comments on just charting or why we want to have charts and get that Um, I have a quick question Some of the things that you're showing Look more like static dashboards and um, some of the other things One of the wireframes was more for kind of a like a dashboard building flow I guess ultimately you're probably going to want both things, but is there one that's Wanted together that's the priority right now is the priority to get static dashboards or To have like a dashboard builder that um, so clients can create their dashboards Great question. So I'll answer from a couple of perspectives. So from uh perspective I mean, I'll I'll play josh l here who's not in the call So josh lemur from the monitoring side p.m they already have Existing charts and then they have a vision for dashboard So they likely will want to do some dashboard work So I don't know What the priority is there is it to to create a dashboard framework And then iterate on the charts or clean up the charts first. I have no idea. So That so but the answer is yes We want all of that as you alluded to Amelia and then For all the other things that I mentioned that I care about from the plan perspective Again, I want all of those but um, I would actually defer to some of the conversations today And the future conversations say in the coming weeks to figure out. What is the next thing? So you're totally right In that I showed you a couple of examples of burn down charts where it wouldn't be a Dashboard and so the burn down chart would be very local and strategic to the the relevant UI And then some other charts maybe it shouldn't be local and then maybe we want a A combination of both where you click one thing It zips you to the dashboard or maybe you're in a dashboard and zips you to another part So to me that's not defined yet, which is exciting because we need to figure out how that applies And also it's it's at least from the plan side It's pretty green field because we just have burn down charts and we pretty much don't have anything else Monitoring has some charts and then the manage team which owns the contribution analytics They have a lot more legacy things But for the plan side, we're pretty green field. So so that's exciting to me because then we can pick Which one to do first? So so hopefully I answered your question Um anybody else or before we jump into to additional things If not, I'll share one more Visual and then I'm going to kick it off to To jake up and mark and other folks From a more technical perspective. So I just wanted to show dovetail what Amelia said earlier is that one of my visions of I alluded to this earlier, but I wanted to I ventured off to talk about sort of use cases But more more specifically that the concept I have here in terms of design Is that you would go to any group level like say get lab.org Um, and then you would go to some type of charting So maybe one of these things so get lab.org one of them would be a chart Or maybe it would be a subset of issues if we do issues only I don't know and then you can create any number of Dashboards here. So similar to a board Uh design so you can create any number of dashboards and then from each dashboard You can create any number of charts by clicking add chart and then um When you go to add chart You would get some modal like this to to pick your favorite chart and you add it So this is not really rocket science in terms of the design I just wanted to put it out here on the epic to illustrate at least my initial thoughts, but again Uh, you know, Amelia how how we work at gilab is we What just put stuff on the page? We try to put nice problem statements that make sense, but we also don't shy away with Really detailed implementation suggestions because at gilab. That's how we found success in making people think and so You should feel like you're not tied down to this design when you're looking at designer But if you're uh, but at the same time if somebody proposes a design It has good ideas. Everybody should evaluate on its merits as well Um, so that that's exactly what i'm doing here. I'm trying to force the conversation by saying These are the problems. This is my initial thoughts If nobody has additional ideas, we're just going to run with this Um, so, you know people better start generating ideas because if not, we're going to implement this ugly idea So so that that's the idea we we try to work at gilab so If there's no further discussion, um, we had a chat last week. What's up with mark? So mark are you on the call mark? I think you're in the car and let me scroll down Yeah, you're in the car. So mark and mech I'm here. Hey, hey marky mech. Um, so mark is is uh, is gonna Last time I checked in with mark and mech marks going to be able to help out from a back end perspective um, because as i mentioned mark and mech are representing the The needs of the engineering team. I think their their goal is to iterate on the thing you see on my screen here Make it more awesome for an engineering department. So so it's in their interest in their goal to do that um And then I think mark can help up on a back end perspective And then the plan team would probably need to participate from a front end perspective to actually do the front end implementation Because we I don't think we have anybody else to do that from a design perspective We have Pedro and annavel who are dedicated designers On the plan team and amelia believe you're a dedicated designer for the monitoring team I think I can only presume that was you've been assigned there because they need so much of that data visualization work And so when I asked sara can can we have amelia participate here? sara volunteered amelia as well So I can see us collaborating closely on on some of the designs whether the chart Uh, the the next chart that we build is relevant for whichever team. I believe the designers all all the designers here But will be involved in some capacity Um, and then of course we have we have jacob representing maltano, especially on the front end So maybe maybe the first step we can do is maybe uh, jacob explain your vision of how Uh, maltano and front end pieces can be leveraged within git lab and update everybody from a technical perspective Okay That makes sense I was listening to the whole thing so much and then I was like, oh, I'll just get something to eat As soon as you said do that I just like stuffed my face with a pita um Okay, so maltano As far as everyone here is concerned is a completely separate entity um and not to be Mean or anything or whatever like whatever we do Almost like has no bearing on this. It's the idea is that If we create something that uh, you guys can use Or if you tell us what you're doing And we create it and they can uh, they Intersect and great if they don't No big deal. You won't use it. You know, whatever you want to do Um, but the way that I'm building the dashboards for maltano seemed very similar to the way that um Dashboards were being created here And one of the things we're doing for maltano is to create something that is um Version controlled so version controlled dashboards means that for us it means that you create a dashboard in um In yaml or some sort of Format and then that yaml defines the dashboard and this was not So if you've ever used looker looker has the ability to define their dashboards in yaml So i'm literally just following What looker is doing with their dashboards? A similar thing except looker also allows you to drag and drop And we're not going to be doing we may be doing drag and dropping But it would also have to like incorporate into that version control situation because We at least on our side want all of our our dashboards to be completely version controlled Nothing that necessarily gets saved in a database um And files that can just be passed around so I've already built the charts Uh for our situation. I didn't build the dashboards yet like the part that incorporates the yaml, but um The charts are pretty dynamic and then you can you know, you can just kind of pass them any old data and it kind of figures out how to Do it i've also got the uh the data team that's been helping me out because Um for the data team they want data in a very specific way And they're really good at saying like for example, don't use pie charts, you know, they don't they don't want pie charts So all of our charts are following the data teams um Requirements for uh data. So yeah, that's what we're doing. We're building a dashboard that uses YAML to configure it And then you're going to be able to drag and drop but it will also like reincorporate it into the source control so um So i have a couple questions maybe christian on jake could could answer so So we're going to be leveraging a lot of the technologies that jacob builds. So will there So we'll need a lot of work from the front-end team to take what jacob is doing and put it in. Is that is that the idea? Yeah, there is there is one idea My question there is more more I need more details on how things are being built right now because one of the experiences we are having right now is building the git lab ui component wrapped component framework And we're building that as a separate project Which is independent we can pull that in as a dependency into git lab c And if it's the if it's that kind of a structure, I think that could eventually be like a joint effort of being that thing up today because as You saw when in on victor's mock-ups and slides Um, it had a bunch of things that we're going to need to develop specifically for our solution So we would need to also participate in the development of those graphs as well and building on top of what's already there So I don't know jacob right now. Is it is it a separate repo? Is it the current repo on on inside? It just matched with the rest of the meltzano code. How is it structured right now? separate repo that gets pulled in as an npm package that you import um What I was going to do and I didn't I didn't do this yet Is I was going to make it so that you don't have to use the yaml to configure it and it you can also just use the charts so Let's say you're using d3 or using chart j. I said really like almost doesn't matter Because in the end you have like a bar chart on top of that is another layer Which allows you to just very easily incorporate any sort of data and just kind of shove it in square peg and around holes sort of thing um And that's kind of what i'm doing because the meltano data can come in from any data source It could come from sales force. It could come from this and so I've made it so that you can kind of like as long as the data Follows some sort of convention, you know, then we are able to um You know Graph it which the graphing does work right now. It's just it's not uh, the whole library itself is not completely separate So one thing that I wanted to forward is that what happens with most of the dashboards dashboard applications is that uh, the kind of data sets that the back end provides Isn't exhaustive for the most part because entire rendering happens on the client side So for example, if you are visualizing Data points and rendering bar chart out of say for example 10,000 records, uh, then it kind of slows down the entire rendering process of the charts So in in my previous company what we used to do was that on the web We would show the sample size of the data and render the chart based on that sample But we also used to provide a way to download the Entire report and uh, that was something that most of the enterprise customers really wanted Like they wanted the entire report to be available as a pdf download and what we did was that Instead of a screen grabbing the entire chart from the screen and then creating pdf out of it The entire graph rendering used to happen in the back end and When you for example on the ui when you would click on download as pdf that it would make basically make the request and back end would Take out all the data that the back end has to offer and would render the chart using the back end services and then the File is ready to download it could just serve the file instead of You know show the chart that was appearing on the ui So that is also something that we might want to do because as jager mentioned like the data source would be anything and At the same time we may not know how much the size of data would be The one thing that i'm doing from my side is Because like we have a like a literally a text in brother that asks how many rows you'd like back And if someone writes 10 000 what I do is um The array could come in as 10 000 rows, but what I do is I um I do some like filtering on the data So that when you see it could you if you show 10 000 first of all if you showed 10 000 axes labels Then it's just going to look like a line of black So I filter through that and only show like every Three or something depending on the so I do some uh, you know d3 has the scale Stuff that you can do so I do something similar to that but not using d3 um That's what I do again. Yeah, you don't have to use this like it's just something i'm making. I just was mentioning like hey We're doing it if you want to you can use it if you don't want you you don't have to but I would I was just thinking like hey, it looks like we're kind of like duplicating Uh resources here and you know why not be frugal and save money But the other thing is yeah, it's in a repo. So um I don't know what your timeline is for this because maybe I could get it up to a certain point Uh, like where I want it and then you could start kind of hacking on it as well and submitting merge requests To it for stuff that you would need My goal would be to keep it like as ambiguous as possible Like from a charting perspective so that it so that it can kind of handle any sort of situation And then maybe you provide something on top of it that that customizes it. I don't know so So so jake, why don't Why don't we uh talk about a very specific deliverable and maybe then you can tell us that you know, um I think it'll be great if if front end team any front end team can contribute Right, I think I think you would agree there, right? So then then you could you know review the mr's or whatever Um, and so before we get to that I don't think there's anything from the back end perspective we have to talk about But I don't want to leave mech and mark out of the conversation. So that's how we are So I I assume we would have a dedicated back end engineer here because I think mark is kind of like the use case expert here And I think it's important that going forward the quality doesn't want to maintain charts anymore We want to be able to configure this inside git lab right all the stuff we wrote translate code into actions Instead and then our customers can use it too But I think we would need a back end engineer here because like merging data from to like there's a challenge that we've seen so far It's we implemented very bare bones v0 prototype and vc, right? It's coming from a project level But what do you want to do now is we want to do at a group level and merging the data back up at the group level is it's getting hard so Improving this right out of the bat on the git lab fashion I would say think a bit from the group level from from what victor said and I think we need some We need new tables because we are doing calculations in a separate database But everything is driven by risk api So mark can help with the strategy and the inputs and the use cases But I think we would need a dedicated back end engineer and I foresee is having new tables and migrations and all that stuff that That has to be flushed Yeah, I think um I actually think the back end there's um a lot of Parts that we can already reuse. Um, I haven't looked into it too much, but we do have The concept of finders And if we're if we're mapping out Data at a merge request And an issue level we do have Issue finders merge request finders that handle a lot of the heavy lifting right now and then Because the way that I foresee it is we would use some kind of Label Filter like we do for the issue list right now and then the the data that's derived from that would be used to present the chart and that um That bar with the filters with labels and milestones and things like That that already drives the um That's what drives the finders so um The information that we've been using mostly on the quality side is um is labels statuses And um dates so things like created dates closed dates merge dates and things like that um So really we'd be looking at picking that data out of the results of the finder that the finder comes up with um, so I think there is already a lot of back end Stuff that we can just reuse and then pass that off to the front end. But as um kuchel said there's um It's sometimes quite intense when you're working with a large data set So if you're working with 50 000 issues like there are in kitlab city then There's a lot of crunching there to present it in a way that's um Usable by the front end straight away So um I think there's going to be a bit of a layer between the finders and the api that's presented To the front end Thanks mark. So so why don't I? propose that we do the simplest thing that I can think of and then and then maybe mark And and jacob and kushel and andrew could could re Have that conversation with respect to to this this very specific thing. So I I can only guess that dashboarding should be a secondary thing because it doesn't Have as much value and you can create a dashboard, but if you don't have a chart then it's useless So we need to have a chart first. So I propose that the very first chart we create is this um, I think it should be at the grip level, but if it's like Totally a lot more actual work fine fine project level Um, but then it looks very like if you can squint your eyes here um You just have a something like this. Sorry. I keep It's exactly the same thing. I don't know what I did. Um, oh, here we go So you can just go to there'll be a search bar as usual And then you and it can't do anything except filter by like maybe one label I don't know what's the easiest thing, right? But we're definitely not going to support like random search Whenever you can't do all these options. You can only do label Right, and then we'll do one label or two labels, whatever is the easiest And then once you support that label or you hit enter Then it draws this graph here, right? And so it may like not even draw the graph when you hit this page You have to hit enter the label first whatever is easiest And then nothing will be configurable. It will be just like by weeks or by months or whatever Everything will be um hard-coded into the design as the first iteration Um, but we want to do everything correct using meltono using The the right back end thing. So if we do that Um, how does it look? I think that's um, so The the graphs that we've been building it. Well the charts that we've been building in um the quality dashboard um, the concept of that is uh, we use a one filter label or several filter labels Which will produce the label set So the issue set that we're working with and then we also use categorization labels which group the Issues that we find Uh into maybe a stack bar or something else like that So I I I immediately think that that would be useful because um for us And the engineering team we use that for um categorizing bugs by severity or priority Or by team and things like that. So that's immediately useful And um, it's using the native label functionality and we've got all the bars, uh, sorry the um The components to represent um filtering on labels and things like that and it's already familiar to the user Great. Thank you mark. So so so it sounds like this this would be useful immediately and then from a back end perspective is it buildable? I don't know if that's a word, but Like do you see a huge jump difficulty to build this or is this similar to what you already had in mind? I think it would be possible to utilize the finders that we have um to So say we were filtering on plan issues So we wanted everything that was planned and we then wanted to categorize those by feature proposal and bugs We would just get all of the plan issues and then The the chart would just split out the ones with a bug label and the ones with a feature proposal label and then visualize that data Right and so so I when I looked at your githlab insights thing The late there wasn't really labels because essentially everything was hard coded because it's specific to what you want obviously so I like we can even do that if we want I think that would be like not the best user experience But you are very first iteration could be like hard coded bug And then it would be useless to any githlab instance that didn't have a label called bug which is sort of dumb But to me it's still a super valid first iteration because most people would have the word bug um, so that's a possibility to make it even more like like MVC ish But I'm thinking like we might as well make a jump to allow you to enter any label Yeah, yeah, so so that's what I'm thinking from both front end and back end perspective like we might as well do that Um, that you want to so yes, so um, I want to say we really need somebody from back end because we're we're implementing it from From a black box perspective. So leveraging all the input like all the endpoints that we have I think you somebody in the back end can If we already have this data and we just need a new endpoint and it solves like 100 lines of code and githlab insights, which would probably involve a back end person Because we're kind of working around that limitation here. The other thing that I Uh, want to highlight here is the confidential issues. Like the way we implement it because of security concerns We don't include we use an a non Um user outside of githlab. So he only sees the public Metrics, right? We should do this for confidential issues as well because those are the stuff that we don't really count for But since we've already built inside githlab, we have access to that. You can sanitize security through data and names and you can just the data can be more More accurate that way so Yeah, so so for confidential issues mecca. I don't see a huge problem that we we can just ignore it or we can just do permissions So whatever is easiest we can do so I'm not worried about that So so are you saying that um, you don't want, you know, I know engineers will say that they can do any anything And I'll take two days to do but are you saying you don't want mark working on this specifically? um Or you do want mark working on Mark it's gonna help but then I don't think we have all the domain knowledge for back end and we need a back end person from plan to help out Well, what do you what do you mean like because Just from like a signing an issue to somebody to work on just really I'm just talking about project management Like we'll of course have planned folks ready to like review code and stuff like that But would you be comfortable? I know it sounds weird that I'm talking we're talking about mark with mark on the line So, um, I just want to get your take Meck as the engineering manager here Like would you have would you feel comfortable because the reason I'm asking is from a project management perspective? Um, do we need to have a plan back in engineer assigned to this task? To do the development. I think I think so we we don't know we don't want to mess up migrations Right. We don't we haven't like the quality never ridden a migration before for github.com. So Instead of having us like playing around and having to be back and forth I think it's it will be faster if if we assign a dedicated back end engineer to help out And I mean mark will be here to help and that's that's still one change Okay. Yep. Yep. Uh here, um, okay. I mean if anything the front end is probably more bottlenecked anyways, so um So given what you see on the screen Jacob is like meltono ready for that can like Somebody on the front ends. I just grab what you have and start developing or or do they need to contribute to meltono to even achieve what you see on the screen Well, we already have griffs Just like that. That's no problem. Um Yeah, we we've got plenty of griffs like that that's a pretty simple one because it doesn't have any um It's not a stacked bar graph even it's just a right, right? Yeah, so we have plenty of grips like that. Um, we have a bar chart component I believe Right now, uh, emily from data wanted all of our bar charts to be Um horizontal because she doesn't believe in vertical bar charts, but uh, I can make it so that's very opinion Yeah, yeah, but I can make it so that you can uh change it to Well, that's why we have emilia here. So emilia and emily will go at it and argue you guys can duke it out and I'll make it so you I mean making them be able to switch is not a big deal Uh, I'll put together. Let me see if I can make it get that. Um, that repo, uh A little cleaned up today and maybe I'll connect with andre and um But yeah, I just wanted to make sure that we're we're essentially I can say like ask andre like even though we have like In my opinion, like negative three front-end engineers that we need Like if we deem this really important like we can have a front-end engineer To to work on this they can work on you as a meltonal representative And then I will not be pissing off josh because you will piss off josh, man Because yeah, we don't want to annoy em. Is it like oh, no, no, jacob supposed to be working on meltona He shouldn't be supporting. I mean that's totally reasonable but so I What i'm hearing is that meltona is in a place where it's like if it's not hundred percent It's 99.9 percent where some a front-end engineer can take it run with it. You would of course still be reviewing code Um, but they would anything you want me putting now just the one thing I would tell you which I had some pushback on which is fine Just again, you don't have to use it. It's out there. Um Andre, which is that right now uh to get uh an mvp out we use chart j s. We did not use d3 uh, right Just because then I didn't have to it was really easy So I think my my my questions there. I think at this stage we at least On the front end are still in the questions phase. We don't know the answers what we're going to go for and with So right now we're going to gather We have been gathering feedback from our team and and like frustrations with the current implementation Or what do we want to clean up and what would be the right way forward? So I think right now in this Moment, this is the initial call. It would be great to have A way of exploring the current status of the non-standard code and see how we can be supporting our our way forward Um, how can we like find a way that it solves both our problems in the duplicated effort? So we can have definitely have a look at that and then also because team is not on the call and I would definitely uh feel more most comfortable with him like Being on board and everything so definitely best those As soon as it's ready for us to have a local Jacob just send us send me the link or something And I'll spread it around our our team to have a look and so that we can then have more Concrete feedback on on that whether that's a road ahead or if we because right now We're currently using d3 on our side Yeah, so we might want to evaluate that if a charge j s Is able to do everything we need to do it Or if we need a d3 can it also be living in the same mountain of repo We just switched from one frame of the other depending on the kind of framework on the kind of chart So all those are questions that right now we have It's definitely useful to have this disability on the roadmap victor so so that we can like look at it and see especially the vsm graphs How we would do that on charge as how we do that on d3 that that sort of thing and then we can kind of advise a strategy That will be best for both of us even if just like jacob said is to have two separate roads just like We're definitely going to have to to have a look at that So as soon as it's ready for us to have a little jacob if you want to clear it up It's fine, but if you want us to have a look right now It's we can like fill in the gaps and to where it's headed But it's definitely we can only start evaluating that once we have visibility on that And we have a little bit of a more internal discussion which you want to have over the past couple of the next couple Days weeks. Um, so I think the first step is for us to have visibility on that Yeah, I'll get it together and I'll send you a link. So yeah, so is it Any Is it too much to ask so andre jacob like can we have like a just a plan in a week to say that That We will be using maltano and then this will be like the technical Ideas like it doesn't have to be like a really formal plan But so so that we can move forward with this A week sounds a little bit tight because then team comes back on wednesday. We're gonna have So maybe two weeks would be better So I will I'll remind you next week or something. Let's say two weeks for So, so let me let me make it clear and then I'll slack everybody at the end like the deliverables for our front end which is in two weeks and then like Like don't commit to two weeks andre if you can't right so and then if in a week like you need to delay it then Yeah, I wasn't I wasn't committing in particular. I'm just saying that in a week. I'm definitely sure that we won't have an answer for you Okay, well, that's that's my only can can you can can I ask you commit to In two weeks deliver something and then let's talk about what that is right now Or do you oh, okay, let me I should not ask you for timeline before I ask you the scope so I think what what I want to know is is pretty much, you know from a project manager perspective is, you know, like Um, you know, I don't you know at the end of the day. I don't care if this is meltono, right? But I think there was a lot of I think josh And you know jakeb keeps saying he doesn't care But I think josh we cared a lot and then I think jakeb cared a lot So that we do want have meltono being like the technology from a charting perspective Insight get lab and I'd love for us to be like the first team to do it and do a good job of it because I think that's exciting and So so I want that to be a solid decision um In two weeks, so so so okay, so I mean I want a decision to that and I'm you can tell me what the timeline is but I want a decision to say that Front and as an organization is saying that we're going to work together closely with the meltono team To use that technology to do charting inside get lab And that's that's going to be like a technology decision that the front end team owns overall And so I want a commitment to that because the reason my own commitment to that so that we can unblock the planting to do to do these things So right is that I think I think it's it's reasonable It's reasonable to have that sort of an answer but in the meantime jakeb I think we should have a more like technical Call between like the front end and and meltono just to sort out the What would a reality where we were working that way would look like In technical terms and what would be the process? Well, who would be the maintainers of that repo that sort of thing so we can like have a concrete process in place but So How long do you need andria? Like it could be three weeks. So just tell me it's three weeks If you yeah, yeah, because I'm thinking I'm thinking I'm going to do like a debriefing session with tim this week We're going to set up technical technical meetings for the next week Um, so I yeah, three weeks is a bit more comfortable. I'm a second. Yeah. No, so let's say so I'm going to hold you to three weeks and you know, like I said in gilab. We change all the time So if I may victim before before we go on so the quality team wears wears two hats here one is use case driving this The implementation the other is the classic quality Drive is I think we should be ramming as well in this one when when it starts to come Come down and solidified. The other thing I want I want to see is um because charts is uh, very visual So I'm looking forward to see how we can leverage the visual diff that we already implemented in the front end infrastructure So anything that goes in in gilab.com. It has to be thoroughly tested So I know the front end team already has visual diff on components Let's make a requirement that any new component that goes into gilab.com And part of this initiative needs to go through that pipeline as well So, so sorry, did you say visual visual diff? Sorry. I was in here Yes, so I was talking with tim and I know we have some visual diff Bitmap comparison test already. I see levels and I I want to see how we can actually Incorporate that into this Is this effort as well because that solves the quality that early on in the pipeline. Let's do it You don't want that. You want to you don't want that, right? That's that idea. You don't you want to I hear you. Okay. Um Yeah, so that might make it four four weeks. Andre Yeah, I'm thinking that Because I we need to basically look at how gilab UI is set up to have that So that definitely Definitely might be a little longer. Um, but to do it right. We definitely should take our times so Even though we should have like interim Touchpoints or or I'm finding having a call in the meantime just to have like a status update But the commitment for the answer might might be more of a Four weeks to have a concrete process and how we're going to have this sorted, right? Thanks for that. Make that that's definitely valuable. I don't I don't want to over engineer either Andre and mech so I'm not asking for a plan. I'm not asking for like a Like a It sounds like we're going to go ahead with this but like thanks So so like what what? Maybe let me ask you this. Why would we not go with this plan of using maltado? Is our front? No, I'm saying we could use but lately as as part of that pipeline when we Montana components there has to be like there has to be some testing validation, right? My point is that maybe I'm asking Andre the wrong question Like I'm asking you Andre like in three weeks. I want to know answer to this But maybe the answer is already yes. And so within these three weeks, you're actually doing something else You're not coming up with the answer. You're coming up with a really good engineering plan, which is great, you know, but it doesn't Help me for for what I need in terms of next steps So so what I need maybe let me step back and say what I need in terms of next steps is You know when's the first When can we start building this? So I'll tell you like, you know already Andre Like how this will impact the plan side because we want to do that time analytics chart, right? So in light of this, maybe we don't do that now which sucks, but if we're going to wait If we're going to do this other thing instead So we had a time we had a so for everybody else to say we had a visualization We wanted to build which is more in the bsm use case And that's going to be a little bit harder to to query In terms of the back end stuff because that's all brand new things So we I was thinking we won't even do that first and we do whatever mech and mark once first anyways And because I don't force us doing both at the same time And so when can we do this? Can we do this in 10.5? Can we do it in 10.10? Can we do this in 11.5 or can we do this in 11.6? So that's that's what I want to know Andre so Maybe maybe Well, what should I ask you like should I ask you? um I think we I think 11.5 is I think there's nothing to ask you then right? So I think what to ask you is like will this make it for 11.6? Well the first iteration Because I think 11.5 is too early, right? If you're really telling me It's like it takes three to four weeks to just square up the engineering pieces That we get yeah, definitely that's a too soon, but for 11.6. That's the right question So so why don't we do this? Why don't we say that the right now the the working? Uh, the working plan is that for 11.6 plan wants to ship the first iteration of charts using this new technology integration and the working plan is the technology team is going to work together to figure out the plan and um Right now a plan team is going to Very likely try its best to commit both Front end and back end people to work on that first feature And they're going to work closely with jacob and of course testing quality side ramya is to support all those pieces But that we have we have the people committed. I mean like I'm not committing the people but i'm committing the priority of plan and therefore I hope andre and shan could commit people accordingly to support this effort and it's going to be a 11.6 effort For our very first chart and that that chart being what I showed you on the screen and then um Is that is that a good idea? So so andre so then I don't have to give you Any deadline but why not I am giving you a deadline saying like you have to like You have to tell me if this is not like if this is not possible for 11.6 Andre has to look at my stuff first think find out if it's legit or not, right? And mech has to look at my stuff and find out if it's legit or not I could be totally bluffing and not have written any charts at all No one's seen it. So I think the first step is for people to look at The charts that I wrote and then probably make uh determination of like how long There's words on it. There's code. I don't know if it's Totally fake. It's all baloney I think I think you you you It's like that's the uncertainty Now we have a difficulty of committing right now But once we have that out of the way, then it will be clear for us to get a schedule down On the paper. Yeah. Yeah. No, no, I totally understand I I know you there's uncertainty and then and then product managers want to tie people down because they want to plan So I totally understand both both aspects and then um For Amelia, I know we've been ignoring you. Um, so Um, what we don't want what I don't want to do is I don't want this to be a reason that you put this You know in the back burner and the reason why is that at git lab Um, things could change in a heartbeat meaning that we could if you have this awesome design Like what I showed you looks ugly as hell Um, and we're also trying to work like we've talked like product has talked with sierra And saying like ux actually comes in with too nice of design. So take what I'm saying with a grain of salt. Um, because Like how nicer design should be and how you work. So we'll talk about that in a second Maybe you talk about that offline and what I wanted to say is that We shouldn't slow down because things could change in a heartbeat because we could come up with something really awesome As and that's why I keep saying I want to plan. I want to plan. I want to plan So I'm going to do my best to have a plan and then I'm going to show this to my boss and then You know, other people are going to show this to their respective bosses as well And then if sid says like we're going to do this because it's super awesome Then he's going to make it happen So but if we don't have that as an option for our senior leadership Then they don't have it as an option. Then we can action on it. Then we become like a crappy old company But we don't want that we want to be an awesome fast company where You know suddenly somebody says I want to do this and then all our plans change and then everybody I get lab curses that person who suggested that change But we're all better for it as a company because we made the change that makes sense from a, you know, like the market at demand perspective so We want to be ready for that. So that's why For product and design side of the house if we can provide These ideas awesome fun ideas to to to our respective bosses and you know, share them across the company Then people will get excited and we'll do it right away So I guess what I'm asking for Amelia from you is just to have maybe just one visual And maybe it's just a couple words saying like Um, how you would design this so if you feel very strongly that a horizontal bar chart is Superior to a vertical bar chart. Please design that um But that's what I'm asking of you and then What I'll do is maybe sync up with you and sarah And josh and ask How that work should be managed Because I don't know how your work is managed right now and I don't want to presume Because especially you're not in the plan team as well So but to me, it'll be great if you can have that one visual You know in the next couple of days just like this but like like and people look at it and understand how it will work as I get left Um, but does that does that make sense Amelia? Yeah, it makes sense, but I I feel like I also need to understand a little bit more about like mal Altano and kind of what we get what we get for free Because I don't think I understand that yet And that will help me understand what we would need to add on or and all of that stuff So there's definitely some some research I need to do on my side too to make sure that I understand all of those It's what I'll do Let me put together the the repo and then I'll make a call with andre, Amelia and kushall and show you what I got Right and then you can decide what to do and you can go from there. Is that sound good? Right, so so I mean I So so so I'll leave it at this and I won't push you further Like I don't want you to slow down and wait till you know what malatano can do because we're literally asking for for a bar chart um Which jacob said we can do but at the same time I You should be doing all those things that you just said like you should be understanding what the technology does go The line so all that makes sense um So so go ahead and use your judgment and make a good good decision But I'll follow with you offline I'll pull in sarah and maybe I'll jump in the monitor channel whatever and figure out what like how you can work with us uh specifically so that The like in terms of work assignment and expectations all that so that's super clear Yeah, I don't want to screw up a new person because that's the worst thing in the world so um, I want to make sure that that you are equipped with the Work you need to do and you're doing the right thing because um, I'm sure sarah has a strong opinion Any other questions? Yeah, I just want to throw One is that yeah, I agree that Amelia's work is going to depend heavily on the decision that we end up like making So yes, jacob, that's the first step and the second thing is that since we're doing this and we want to do this properly Just like mech said One aspect that I would love to see considered Once we start designing and thinking of your eyes and everything is the mobile view of graphs Because I think that might be part of the reason why Emily from from native team this prefers it vertically. I'm not sure but Um, but I want to think I'm like an error screens. How does it how does it work? Turn your phone turn your phone Sorry, you can scroll sideways on the phone right late. That's not a problem. Just Yeah, that's why being left. Have a message that says go to your computer to look at this That's not a terrible that that that is actually a pretty uh, pretty okay, whatever I just want to raise that point of awareness, but I thank you. Thank you. You know, you're totally right. Um, Jeremy has been pulling up stats saying like 10 percent of our Traffic is coming from mobile now. I'm like, you really come on. Yeah, so, um, You're totally right. You're totally right. We should do this correctly, especially if we're Yeah, the point with statistics is of that is that Maybe it's it's that's a low number because we haven't given a lot of love to the mobile view Once we give love to the mobile view and start even getting larger numbers. So That's why I don't ever like there's could be amazing innovation there Right like like you can go to mobile view and now I'm talking serious like you could like put like show five numbers instead of a chart Right, you can like think of a yeah, I could it could like if it's too small like the whatever view part whatever it's called Instead of showing bars you show numbers you show a table view of numbers, right? There's a million ways to to innovate there. So you're totally right that we should um spend some time at least consider that Yeah, yeah, right. So I think we're set on the first on the next steps, right? So Jacob just being me and I'll pull in whoever so preferably after Wednesday. So that team is already here And then we can get that going Awesome. Thank you. And then so last thing I'll just say just everybody just um A descent on the f underscore chart channel. I think singular or charts. I don't know but We can sync up there and use that as like a sort of a cross collaborate crossing collaboration channel Since this is exactly what it is All right. Um, that's all I had. I will put this on youtube unless somebody said something terrible that they don't want to Show to the world anything you can think about it. No, okay Um, that's your chance to just say something horrible We don't really like pie charts that people would know We secretly hate pie charts at git lab, right? Well, I Yeah, we can have a separate discussion on that All right. So, uh, we might be we might be hating vertical bar charts So, uh, I don't know what the labs line is on that one But all right. Thank you everybody for the call. This was very helpful for me personally I will sync up with uh, Amelia on next steps Uh, but for everybody else I will look for your, uh, great conversations in the future Cool. All right. Talk to you. Thank you. I'll say bye Bye