GitLab Monitor:APM Team, 30 Oct 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Monitor:APM Weekly Meeting

Description

Weekly meeting:
- Getting "logging" to viable
- How should handle large issues that could be broken down or have multiple assignees?
- Review new issues since last week

A

Okay, welcome everyone, hello: this is the weekly monitor a p.m. meeting yeah. So, let's get started. The first thing I had on the agenda was just to talk a little bit about the meeting time again. I know daylight. Savings time is affecting people differently across the world. Now in the United. States ends this weekend and then, since I set up this meeting I think it's probably the times we're gonna change for everyone, who's, not on the same daylight savings time schedule.

A

So I just wanted to make sure or talk about see if this time still works. If it's going to be.

A

If we need to adjust it starting next week, wanted to see if anyone had any opinions, what do you mean it's? What's that.

B

C

It's gonna be an hour later right, yeah.

B

We had our daylight saving last week, so only this week meeting shift a bit, but for me it's even better, but next week it will be back to the original time we can for.

D

Me it's the same. It shifted this week, but next week it's gonna be back to to the regular time sound. At the same time, all right good.

A

Just Oh go on the record and say I hate, daylight savings time and I. Think it's ridiculous. So.

A

Maybe that's just because I've had to deal with weird computer software glitches that have to do with daylight savings time.

E

I mean if anybody, if anybody tries to run our test suite just unit tests locally many.

F

Of the problems are.

E

F

Thought savings.

E

Time problems or where their time zone problems right.

A

Yeah and even in the United States not everywhere follows the same daylight savings time. I met.

E

Some friends last evening and they said we're not running our test suite coupled you know, for the day after day. Let's say this time just because we know all the time we're gonna have a blanky test break.

A

Okay, so we'll leave it that's fine, and if, if we need to adjust it, if it doesn't work for people, we can always change it again. All right is: oh, don't thank Josh, oh yeah, your house. You want to talk about the monitor sandbox project.

F

Yeah yeah yesterday I was able to create the project on staging that bit live.com as well, so I also have a ready cluster connected and everything is ready. I just need to clean up few things and then I'll make an announcement on a slack chalice and if you can garden, hopefully the link there. The clusters that they're using for staging can you can you provide some context around with.

B

F

In the previous meetings, so the idea was to have a project on each lap, calm and staging target lap comm that people can use to demo test new features and things like that. It would be like a continuous integration machine will say so. People can just go there and text instead of everybody creating their own projects and having transferred capacity.

F

So this would be that one source code, hopefully so that's what I've been trying to do for the last of the weeks and finally, I was able to create a project and connected to kubernetes and see the dashboard tracks on it.

F

E

That thing have prometheus Prometheus metrics in point on garage.

F

Prometheus met, I I think I need to verify it all right. Only this is a question anything yeah.

E

I'll, send you I'm gonna, send you one? The good does have okay.

B

B

This is like a shell, we can all use yeah.

F

So I created it under the monitor group, so it should be accessible for everybody and same thing for staging that get lab back. Thomas.

B

And if we see like some things that amidst customers read, thank you for doing that, I think it will be beneficial for all of us, I mean if we will see things that we think are missing.

B

Do we have some sort of way to make sure we'll be and we need to process? How should we handle this? So.

B

We think that something, maybe we need to add additional configuration because functionality, how can we make sure we could be scalable I, don't think I think you would be the one that you need to keep saying.

B

So tell about this in some way, so.

F

If, if we want to make some changes, for example, if you want to add a new dashboard and test, add a custom dashboard and test certain features, you can create a merge request and make changes and I can be version. You can test it, but if you find that something is missing or something is broken, if I answer your question correctly, then hopefully should be able to see that and then create an assurance.

E

So super useful to have that had that test Apple, because I had to make a test app last week to do to get a chart change PR through the through the charts change to audit about about app. So you know those things are handy handy to have, so you can include them in test projects because they didn't have any. There were no test song for the OtterBox app.

A

Great yeah, yeah, okay, good I, think it's pretty good and I. Think yeah after we get to Dov's point I think if we have changes, we need to make I think this is a good way to kind of think about. Even dare I, say dog food, some of our own product here and we can as they come up. If there's configuration, changes or something we can kind of work through it at that point, but yeah there's custom dashboard things we can always create merge, request great new dashboards. Just like we expect our customers do right.

A

F

Yeah, a new is a new chart. Thanks hundred then obviously the merge request and include that here, so you can see what the capabilities of this that yeah.

A

Great okay thanks! So next I just wanted to talk about 12.6 a little bit. I know I feel like we're just getting our handle on 12.5.

A

What we want so usually so this is what we have in our handbook. I have it on my screen, but we want to start prioritizing 12.6 backlog in the next few days. Here, I, don't know if that's the door, if you have thoughts around that, but.

B

Do the planning properly after the last two iteration just join the second I was yeah and I do plan to start going over those in tomorrow and on Sunday, and hopefully we have something that we can start looking at next week, yeah.

A

That sounds great yeah I, just like like youdo. The last couple have been feel like we're, always a little bit behind so yeah push that up a little bit. I would be great trying to get on the on a regular schedule, so yeah I just wanted to bring that up just because it's kind of the end of October now so 12.7.

A

We should start planning in the next yeah by the next week, or so we should kind of have that more firmed up, mm-hmm, okay, so one of the things that we talked about last week is starting to review any new issues. That was the next thing, but I don't know. If there's other stuff, we want to talk about before that.

A

B

I have few comments. Yeah go ahead, so one of them is so that we had melt the magic words about using weights, so I don't think we use them in the last iteration, maybe just just a little bit. So if it's possible to start putting on weights on the issues as documented in the handbook, if you didn't start, then start counting down so I'll be able to prioritize the issues as we move from one iteration to another.

B

It would be very helpful for me for the planning and yeah. So this is this is number one and any any comments on that concern moderate. What to.

A

Do what weights on every issue that yeah I think that so.

B

Here's the thing as I mentioned weights are important for me. It is this we are doing this test when we are moving from one iteration to another. I need to understand if we should keep the issues that we start walking on the.

B

Because if I'll see that there is an issue that is in the weight of one which mean the 20% of the already- and it is moved- maybe it's not high priority is would be I would still keep it on. So we can finalize the feature and.

B

Move to the next installation and it's not as elegant high poverty, then I would like you to move it to the next iteration. So this will be the only the only way for me to see how we can handle those, because, usually it happen right as we move from one iteration to another, so maybe I have like a day or so to plan it accordingly and I.

B

Don't want to think everyone and say hey what about this issue on that issue, so helping me working remotely and helping me not giving you in different weird times if we can assign issues weights to the issues so.

B

E

Anything is in dev needs to be assigned or have a somewhat up today. Weight on it, sourcing or or is anything I mean if it's not a Deb, it's by definition, 100% right.

B

I, don't know I mean it's again. It's up to us to decide if the work we're doing before is also considered to be a weight. I, don't mind, saying: okay, if it's, if it's in there then needs to heaven wait. If it's not in there, then we don't have to put weight, but by default. It's then.

F

Also I was under the assumption that this was only for deliverables. Is that still accurate, or are we adding Raytheon for bugs I.

B

Think also for for bucks because again think about me what what? How will it help me if there is a bug when it's in p3, maybe someone has already put most of the work on it and I'll keep it. So we can finalize the walk, although it's not as.

G

Though it sounds like it's something that we may want to add to like our async weekly update, where we just kind of when we're updating the workflow label, we can just update the weight you know for that week and then that way at most, you know we're adding weights or having to deal with it once a week, and we can kind of do it as part of our async weekly uh issue updates and then be done.

G

Maybe that's a good approach and then it's kind of always up to date anyway, and then, when we realize oh, this is gonna. Go to the next release, it's already on there, or are you saying that all you need it for dough is just at the beginning during planning and then basically when we need to switch them over to the next milestone. So.

B

Yes, this is where I need them, but in reality I think that if you won't add them on a weekly basis, we end up not having them. Some of them won't be there. So I do need in that time, but you know sometimes people probably forget or won't do that or you know we'll be on vacation, so I think putting them on the weekly.

B

We can force us to follow these bosses.

G

G

And it's not I mean airing.

B

G

Alright, well, we can start there and just add it to our weekly async updates, and then you know, if that's not working, for whatever reason we can yep mix that up, but at least that way you don't have to think so much about it. It's just you're already touching the issue already providing an update. It's just you know one extra step. There.

B

Okay, good next issue, yeah next one and show.

B

Where are my links yeah? So, according to the maturity plan that we have listed on the handbook and login.

B

Some logging in the moto stage.

B

Secure, please yeah, so it's playing to minimum to Bible and to do so I've created. So we have some issues. I had found some time to work on the epics and and what I've done I'm trying to they won't know that the project is pretty significant, pretty large. There are multiple issues so I'm trying to put some order linking into things just to so we'll have that more control and more visibility on walking toward this goal.

B

So there is a happy moving log into viable where basically, the proposal I'm saying that we have multiple approach or multiple ways that we are working, one is the deploy. Elasticsearch automatically collect application logs then create the UI with them, and then we also have some on the existing UI that we have today, and what I've done is that I've broken it down into three different epochs.

B

So I'm walking down to three major epochs and what I think, which is this one, which is related to all the elasticsearch issues, the other one. They love Explorer related to all the UI, the front-end issues.

B

But you want to make sure we have a tab and in the tab of the lot and the third one is basically the work that we already done. What it did on getting the.

B

Issues and we have take one mode- support multiple containers, so basically what I'm? What I'm asking you is whenever this project is, whenever we are opening an issue around this project, let's be aware of those the epics elasticsearch, basically, the top two or the elastic search related, one and vy1 make sure to associate them to those epics. If you don't know just that, mention me and I'll put them this way. We can see exactly how we need to finalize.

B

Basically, those three number two just because we spent somewhere for there and I think it's important to have. It I think that the majority will focus on number one on the tree on the UI and.

B

So yeah, that's that's the update that I have that any questions, thoughts.

A

Are we hoping to get all of this down in the next couple milestone, so it's in yeah? Well, that's quarter, then yeah.

B

Needs to be in the school to narrow by the end of January, so in the clean white stones it needs to be complete, and this is why it's important to have them on the epics on Kiwis, Alesi and style.

B

Assigning the right milestones. I accept extend to the next milestone load, heavy loading, heavy. The focus will be more on drugs, so we can achieve this milestone. But you know whenever you open.

B

Concern about the time about the timeline, the time.

A

No I think that's good I. Just we haven't been focused on I'm logging. Quite as much. Although we've been doing, it's consistently been doing a little bit at a time so but yeah I think we can get there. I think it'll just mean a more of a focus on logging. The metrics, which.

B

Is which is fine, I mean this is what this is. What.

A

Yeah I'm fine with it I just I, was more just making sure I was understanding the time line correctly.

B

Okay, but one more thing, maybe just when you notice the placing is also scheduled, but this is something that will change. We would probably push this further down to you. We have. Some investigation needs to be done in order to see how we can move this today when we want it to be.

A

H

Miguel, hello, everyone.

H

It's it's okay, I missed you guys, yeah, so I noticed so I wanted to mention. I noticed a few issues that are relatively big and big in the sense that involve several team members in different areas and then I wanted to discuss with you.

H

If you think that we should have more well first, we should have a process to split it into smaller tasks and who should be the responsible person for this and second, if we, if you guys, if you all agree that we should try to keep a single as I name most of the time, because these means that we know who is in charge of of these of these tasks, I see that it could be confusing.

H

If, for example, Amelia me and Adrian are Agenor are getting assigned to the same task and then everybody is kind of waiting on each other or it's not clear. Exactly who is taking. Who is driving this so I think it should is good if we don't make the rules more clear.

D

Yeah I agree. That is confusing, that you have to have many people on one issue. Even we should try to split them so that one person is responsible responsible for one issue at all times,.

H

Does anybody want to does anybody's here a case for having several team members assigned to the same thing, I.

F

Am working on an issue that also has a front-end, Urich's and back-end assigned to the issue, but to me personally personally, it felt like it was okay, because you it's really needed to get involved because VX was not completely ready and fronting inviting. You have conversation on that, so we we're all you know in actively or / actively working on it, so we were directly responsible for getting this already ready state. So to me personally, it felt like it was okay, but the ICR is your concern as well, and especially most of these issues.

F

There's a lot of discussion when if somebody joins the discussion at a later stage, it can get a little confusing as well to understand the current status of the issue and who's the next one. You know if they take step but I, don't.

H

Have an answer: I would say if someone, if, if we know that several people have to contribute to an issue, I think there should be your main person responsible like a ones like one single assignee. That is, if you have hey, the UX, need some help and then we assign the person and then, when that work is done, it can be going to the other.

H

But I, just if I look at your issue, I don't know who to ask about about where it is or or what. What is the next step? But that's that's what I think the three of you maybe agree, maybe without so pity one for the rest of the team.

F

So in my issue, yeah, so one thing years has been- the UX has been good at this. If something changes in terms of design or in terms of direction, there's just a bit the description. So every time I, look at this door. I hope that the description is I. Didn't ask me if I feel like it's not out there, I just usually go to the issue and paint your eggs first, otherwise p.m. or front, and then back and just I had all it's a lot of noise.

F

But adding any comment on the issue or tagging that actually helped me get the status of the issue. But again I can see that it can be a bit confusing. There's still some there's some improvements. We can do.

H

Okay and and then the second part of my question is if, if we want to designate some people to display issues, I spent today sometimes planning issues and and I'm happy to do that. But it is not entirely clear that that's that's something we want to keep doing and and I just want to define that process. So if anybody would like to or if you guys, if you don't think that that the issue sizes are okay right now, then it's also fine for me, I think.

B

Every time when I start an issue, sometimes I, don't know how big it is so I expect that whoever opened the issue probably should be the one you open another issue on this I, something that meets if it's more natural for the person would start normally when I'm opening an issue issue. Okay, this is the this. Is the plan.

B

Okay, this is where I want it to be broken down, and then maybe maybe someone started walking an issue and realize that we need to do more so I don't mind if you mention mean, for instance, or the person that open the issue say: hey we need another issue, maybe open it and I also don't mind in terms to make sure things are working smoothly.

B

If you think that it's clear enough- or maybe it's the technical level, if the details are so so low and you think okay I can open up an issue, and maybe just you know it mentioned the person that opened the issue. If you open another issue, so we please you B will probably be makes no sense, because, probably usually when I'm trying to assign a to Kim epic, maybe few opening epic so I've mentioned me. If you do, that mentioned the person I.

H

Think you'd be good I. Think, though, shouldn't be the person splitting the issues, I think it should be on the engineering side.

H

So I I would like so I like doing that personally, but I think it should be a little bit more on Matt and add reals sides, because they have a bit more overview of of where we need things or that that would be. That would be my understanding.

G

Is to clarify: are you saying mostly that the issues that need split are the ones that are already assigned or are the ones that are not assigned like? Are you looking ahead to like twelve six and wanting to see them split more or are you looking at your current issues and saying I can on a moment, because I have.

H

Only seen the current issues then I, then I, I'm talking about those and I would I would want so I would want the process to be. Dolph has a let's say a big feature he has in mind and then he passes that to Matt and agile to to split it up and to see if how this job can be can be spread across the team, and it should not spend too long being so huge.

G

Yeah I mean I think.

G

It's a tricky decision right because sometimes because issues to me are still somewhat superficial, like what really matters are Mrs and that's where we want everything to be as small as possible and an issue can be either encapsulating multiple Amar's or maybe it's a one-to-one ratio, sometimes I, don't know, I. Think.

G

I think it makes sense for us to try and split down. You know issues as we're planning them. If we see like okay, this is actually gonna take. You know this piece and this piece and then that's a good thing, sometimes I think those implementation details. I may not have this, like. You may look at an issue once it gets assigned and realized. Oh, this actually is complicated because of you know, XY and Z right and I I think I'd be inclined to say in those situations.

G

If you need help splitting it down, please ping me I'm happy to help with that, but also feel empowered to do it yourself. If you see like hey I, know that this and this needs to happen. I, don't you know, I, don't think you should have to wait around for who's the DRI on this issue. All of us are I mean in that sense. I think you know.

G

Kind of the gitlab way is just be biased for action and if you see something that you want to split out, go ahead and do it and if we decide hey that, wasn't the right decision who cares we'll fix it? You know we'll close the issues that we don't need and go back to the original I. Don't know I guess that's.

G

Maybe that's may I I. Don't that's not to be dismissive of the concern. If, if there is a legitimate planning issue, then then maybe we need to put our heads together and and figure out what the best approach is. My.

H

Case for splitting the issues is these one is that it makes clear this my it makes more clear who can be responsible for it and second, but it makes more care which my milestone is gonna land into. If we have an issue, that's that survives several milestones. I think is probably because this issue is too large and and then it's just like we did maybe half of that.

H

Yes you're right, it came in an amar and then that amar had a correct milestone and it got merged, but then it says missed and then it goes to the next milestone, and then we have another little amar and it just carries over with defined scope. So I think that that's one if the issue, of course, if the issue is stays within the milestone, I think it's the right size, but if it starts dragging and I think it becomes hard to prioritize hey how much of this is done? We didn't do the right splitting.

G

Yeah I really don't like those miss deliverable labels. I'm sorry I know that that's irrelevant to this discussion, I just really don't like what they communicate but anyway. um That's that separate, I'm, not gonna, get on that now. Right now, I, let's I.

G

Think for now, if you have an issue that is not properly split down, then yeah, let's make let's make let's make me and math the dris on that, so to speak. So just ping me on an issue. If you see that hey this needs further broken down and then and then we'll start there and go from there.

H

It also sounds like it's: it's not a concern of the team. It's only like mine, so like you're, actually saying.

H

Nobody else is speaking up so I think maybe I.

I

Think I understand your point. We go I. Just don't feel like I have enough inside sure valuable point of view on this in terms of the workflow in the club. I could relate to my previous experience that we have. We had similar issues that we have like the one major issue to track. The progress is like whole feature and it stays up for multiple iterations because of what you say so and also we kind of during the process. Take this approach to split it down to have one assignee or their issue so like.

I

If some feature requires works and like multiple experience, preferably from beautiful aspects of full of status, it was like there's one issue containing I, don't know back-end part of the work and the other contains the front-end part of the work, and there was like the one issue which, like has was connected to the others right XIV this issue. This issue, for the whole feature, is blocked by the two issues the front end and the back end. So when the back end and the front was completed, the the master issues of college was moved.

I

So I think that is the case and that could be in problem in terms of software development and project planning and I totally agree that probably having single assignee is easier to track or easier to even ask like hey. What's the deal with this? Is it gonna be delivered in this milestone on another milestone?

I

So we have like more control worth two point, but also could see point of view. That's giving a single. She brings us the space to properly discuss some across expertise, topics so yeah, that's kind of my point of view. It's.

G

Really helpful I think like as you're talking I think what I realize is. That's the that's. What epics are I mean what you just described like the master.

I

Issue is an epoch right.

G

I

E

G

You know if we're properly dogfooding our product and it does sound like we should be. If there's an issue that needs broken down further, we should just promote it into an epoch and then have that's where all the conversation happens. That's where all the collaboration happens, and then we have, even if an epoch just contains a back end piece and a front end piece, it's more than one issue or more than one effort represented to get us there.

G

So the prop the only the only downside that I see to that, and maybe there's others, but the only downside, I see, is that epics aren't tracked on issue boards, which is kind of annoying. Oh.

I

No so like this was the same case with the JIRA, so we had the issue board.

J

I

Expose in drag so use the issues because of that, and we make like workarounds to make it work. But maybe this is also the case which we should rise up, awareness that maybe epics should be trackable, since it's apparently required and needed by many teams to have some ability to do so. So maybe just aside topic, but maybe we should just like know, create an issue. We should be a part. I mean.

G

Even if they were like on calendars, you know like all-day events that span across the top of multiple boards or something I.

J

G

Know I don't know we should we should find something, but okay, I think it's a very good.

H

Point I think I think I haven't looked into using epics much, but it's something that maybe we can learn a little bit more about and see and ask more often hey. Can these be promoted to an epoch and then yeah I think.

G

I think the one thing I think my point in all that is just to if we do go ahead and promote an issue to an epoch, we'll just have to be careful that we are actually adding the sub issues under there and making sure that they land within the planned milestone right. Cuz dole has taken the time to schedule it and prioritize it based on the issue board. So we need to make sure if we're creating an epoch and splitting those pieces out, but those pieces land you know within the prioritization.

G

We expect to see them on the issue board, so we're not creating too much confusion. And ideally you know maybe having the same title and then just putting a bracketed, front-end or back-end piece or part. One part two. You know something so that the titles don't disappear because I know that's a pretty big point of reference for us when we look at it on the entry board. No.

I

We did exactly what you say, so we put just a B and F in the round brackets at the very beginning of the issue to emphasis with which side which team should take over it, and it works pretty well.

I

G

Think I'm willing to try that I mean I. We can give it a shot and- and if we don't like it, we'll iterate on that, you know.

B

B

Know where this issue.

A

One one thing we've run into before I will have to as we're going through this process. To think about is if we promote an issue to an epic, and that issue was a release post item, there's some there, because epics don't get treated the same way for release posts and so I, don't know how we wanna do one.

B

More thing to think about.

A

The labels, the release post item labels automatically generate content on the handbook or the website. If I understand that right, yeah.

B

K

Maybe it's the directional evil that could be actually.

J

Part of the problem was that epics don't show up on the issued boards, so I think visibility is lost a bit right.

J

If using an epic doesn't work, we can look at using sort of meta issues. Have one issue as like just linking to other issues for that unit of work. I.

G

Think in most cases, if we're dividing an issue up, what we're really saying is there's a couple of iterations here to get to where we want to be so whatever the last issue in that like merge, train is so here. The last step in the process would become kind of the one that has the release book right, because until that feature is complete, it really shouldn't be in our release post item.

G

So if we have to break an issue down, then maybe whoever's doing that it will just have to be mindful that you know making sure all those product vision, labels, release post item labels, get added to the like the last step in the process, so to speak, and that way we know. Okay, when this issue is complete now this feature is like ready to be delivered.

B

Just said the problem, you sometimes you don't know what, which issue is the last? Let's say with the key issues, you don't know which one is the last one.

B

But I mean we are here to solve all the ocean. Let's try something. This is always my practice. Let's try you can change. So, let's go with breaking things to a minimum state. Two issues you know use me.

B

So if something failed.

B

E

Discussion is typically I'll, be having this discussion in a retro, so maybe we can move some of this to our sprint retro document to to the mid offices. We do it once and what's a relief.

A

Okay, I think we could move on then I this. This is helpful. I think we need some more of this process and thinking about how we handle some of this stuff, so I'd like these discussions. Thank you.

A

Okay, so then we wanted to review issues new issues that were created since last week. We have about 10 minutes, so I can share my screen.

A

A

So it looks like there's about 12, so.

B

A

B

This is just I'm scared, basically, based on similar to discussion. We just said okay I, remember what to go and ask me to show based on this issue. Okay,.

B

A

Miguel, you had a couple here.

H

Yeah yeah, so I I meant to split, so we have a kind of a big, a big ish issue, which is we want to get the user to edit dashboards directly from the dashboard page instead of going through the repository file else and or at least helping them to get there. So there are different kind of variants of this. One is if the file is already created. So then it should be easy for to guide them to take them straight to repository. So that's what this issue is about, and the other issue is.

H

If they are looking at common metrics added the default dashboard, then there should be a way for them to kind of copy. The common metrics, dashboard and.

H

And add it to their project so kind of independently from the default.

H

So that's the other topic that I think Sarah just just commented that we should be careful that there are some dynamic stuff in there, because the system, what also shows the custom, metrics and I don't know where those custom metrics are stored, I suppose you're in the database. So we should, but that's the general yeah those.

E

Custom metrics are in the database, so.

J

We should probably remove the milestone from those dishes unless they are actually planning on working on them and in 12.5.

H

Yeah I created all of them by default on 12.5, but of course we will have to see what we can handle.

A

H

Sorry I just say one last thing and the reason for that that the edits, the bigger issue that doth created is scheduled for 12.5, so that that's why all of this kind of mini issues are are in 4.5 as well. It's funny because we.

B

G

F

Or maybe we should just change the milestone poet right. All these prerequisites will be in 10.5 and then with the actual. Big task will be a lot 6.

J

I think the major the largest part of it is the ability to edit inbuilt dashboards so other than that I think it's achievable.

A

Okay, so yeah, let's on all of those, we can talk in the issue because that there's a lot of discussion that way. Well, we talked about it last week, and so let's continue that discussion since we're kind of running out of time, I want to get to kind of the rest of these issues too. So this is the next one, a dream cave this one is a follow up. Yes,.

D

It's a follow-up to the elasticsearch child work, so we didn't pay a lot of attention to the actual settings. We used the plastic search, so we have to look at them specifically number of replicas that I retain retention and stuff like that. So it's pretty basic for now and we haven't really looked at them. Okay,.

A

A

Different chart types and custom metrics, they drill yeah.

G

This was just basically to utilize our new chart types when we had custom metrics from the U I thought it'd be nice to have like a drop-down or something so. Customers can write those instead of just having to use custom dashboards right.

A

Okay, this one I created that's kind of just a placeholder for me to to look at that.

A

In the handbook, and also for this one, don't have created an issue to track the progress of the planning, so just want to consolidate that can review it. So I'll I just kind of made that placeholder for me, so I made sure that I didn't forget about it and then I can get some feedback on a few things as I'm working on it or looking at it all right. This one is a I think a customer bug I.

A

Don't know if anyone's taking a look at this.

A

K

The composition.

A

Well, this waiting created.

A

S2O is that okay, oh yeah, but I think.

B

A

If we need to, we can adjust the priorities, all right, that one there's a couple more Miguel. You open this one as well.

A

H

Was a comment from Paul one of the maintainer for kind of performance improvement on one of the charts?

H

A

Here's another one, and we just have a couple left after this.

H

Yeah same thing: there is a few line. There are a few lines of code where we ignore some non values and I have no idea why we do that. We pasted that from the other chat. So I would like to know why I can answer that. Well, we'll take that offline. Okay,.

A

So this is this comment: it out or put a comment in the code or something just to explain right, right, I'll, put it this. Okay, that sounds good.

A

This one Ron.

E

And I worked all night. Oh.

A

E

K

Lars was any.

E

More emerged already for it and I think we there's a additional bit of work that needs to happen to the Prometheus client and map to prevent us from making this mistake again. Okay, yeah.

A

Thanks for jumping in looking at that, that was helpful, we kind of knew or read suspected this. um What was gonna have or suspected what was the problem, so thanks for digging in and I did not expect that it was a data type problem. That was the change you made right. It was right, it's just yes,.

E

C

E

C

E

A

Okay and then the last one that I don't think we've talked about is just this APM planning issue. This is the one that don't create it just so well, mostly I think it's for mostly for douve and Adriel and I. You can make sure we're we're going through the process.

A

Yeah so I like that, so we can keep track of where we are okay,.

A

Yeah we could actually for that one. We could create a issue template even that has.

J

Everything in there so.

A

It could only be a couple clicks that we could have one for the next milestone like they do for Oh some things. Okay, that's it I, think we're out of time. So thank you. Everybody and I tried to take some notes in here, but if I miss stuff or if you have want to change what I wrote because I didn't characterize it correctly, please go in and update it or add additional comments in the agenda and then I'll also post the recording as soon as it's done processing.

A

So thank you. Everyone and we'll talk to you soon.