Kubernetes API Machinery Special Interest Group, 12 Mar 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SIG Chair/TL Meeting: API Machinery Triage 20200312

Description

SIG Chair/TL Meeting: API Machinery Triage 20200312

A

They want to capture in notes, I know, hon I did not get your first question. um So if you want to put that in there, that would be awesome. Oh.

B

Yeah and AHA I know you pinged me. We were chatting a little bit about this. Please please, please put your comments on it because it it sounds like you're all, yellow hurt.

C

Yeah yeah: well, we track our stuff wolf Oh today's gonna go into it. We're done all.

A

Right and then next up and I'm by the way, if we have, if anybody has any more questions, concerns comments. Let's just park that for the discussion, but right now, let's go into fede. Fede is gonna share briefly what API Machinery's been up to I.

D

Can share too, if you can, if you've got issues.

E

D

E

Screen presentation just.

A

See black yeah, we see black you're, probably using a dual screens right, yeah.

E

And you come on, thank you. Yeah.

A

E

It's very simple: you know I just put together a couple of slides I, don't think we have a perfect process, but our biggest value is that we've been doing this for the last two years and I think it is valuable. We have some lessons learned. Some things to share, so a little bit of history, 2018 internally at Google, would realize that you know there was a large amount of pool requests and issues coming and labeling capi machinery, and we needed something to keep up to them. You know.

A

If we, when we were not doing these, what.

E

We get, is you know, random people pinging, you eight and you review multiple requests. A you know. I opened this issue two months ago, nobody's paying attention or can we discuss in the next sick meeting, etc?

E

Sometimes it bubbled up into the Sigma things which is okay, but usually the Sigma things are happen every two weeks and and also they are not the right place to get into you know if you have 40 or 80 as we have some weeks pull requests. You cannot go through in those meetings, so we started with a simple idea of getting together twice a week.

E

Yes, I can give access later to the deck twice a week. 30 minutes. Sometimes you need more, but we don't go over time, but sometimes you need less. We started doing that internally and we realized that this was a huge value for Google and last year we opened it. So basically, what we do is I cannot share my screen, so I cannot do it learn. You know we had to very and the please don't laugh and I think having the cap and having a process.

E

It's going to be great because I will tell you what we do. So we have a very simple query like you can open. One of those like the beers varies. If you want so everything that is an issue and it's open. Sorry, it's not open I will explain right there and labeling API machinery. So we track. Let's say that last week or last meeting we were able to go up to I, don't know one of the ones that are at the bottom, eight, eight nine six six.

E

So we tracked that number and then we go through all the ones that are new since last meeting. Okay, can we go back to the slide? Thank you. So we go through every single one of the pull requests on the list since last meeting and also through every single one of the issues we read through the details.

E

Sometimes it requires more attention like we need to see what files are changing. What is the change? You will get and I'm sure everybody here is familiar depending on you know. If the person is somebody new or everybody has a different style, some people put more details. It's super clear what they are trying to do. Sometimes you need to decipher what they are trying to do.

E

So this is what David was saying. First of all, I think we determine if that is a PA machinery or not. Sometimes it is IPM actually, and it's also other six, so we might label all the six to hoping that that will bring it to their attention. Sometimes we because APA machinery is saying it's in a special place in difficult three set of files that you know are in our folders, but are not necessarily APA machinery, so sometimes we are tell in to pull requests that are not necessarily as so.

E

We might untag ourselves to make it clear that we are not paying attention to that, and you know, because this is a community. If anybody feels that it's wrong.

A

E

A

Conversation is open.

E

Come back, we will take a look.

E

Usually one of the two tails of the see is present in these meetings. So Tuesday's we have David Thursday, we have Daniel and then there is a lot of other random people from the sea, not only from Google. You know from different companies and from the open source in general that participate.

E

What we have developed I think it's a little bit informal, but.

E

Everybody has kind of a sense of who is a good person to look at something you know depending on the area. So what, in the end, we want to make sure that you know we either CC people to make them aware or assign it to people, so they can take care of the issue. I want to say the last two things and three and four. We use this opportunity to tag some issues as help needed or a good first issue as a quorum, but we do that. Do retail is whiskey. Cherry Peaks.

E

We skip the ones that are closed. We get a lot of traffic, usually an ATM machine, so we you know we try to optimize. For that and number four is, since you know, I've been more involving API machinery and I become the chair. Some people come and say you know a what can I do to participate more on the C work and I start I always suggest you know. Come join these meetings. Just you know, sit there, listen learn if you feel like there is something an issue or a peer. That sounds interesting to you.

E

You know speak up or send me a message. I will assist, see you on that one, you, you can see the progress you can use it another opportunity to learn and the last slide yeah. What else so, I think the biggest lesson learned and I hope that it would agree is that we make it regularly and consistently.

E

There are weeks when we are getting closer to code freeze when it gets crazy. We get like you know two full pages of code request which is like you know: 100 pull requests into lace or something like that. There is no way that we can have a large. You know three hour meeting to go through that every week would be great, so consistency and regularity, I think pays off. That's great and those are our numbers we could be doing better. I suspect. A lot of those issues are issues that you know are there.

E

It seems before we started this this entire process two years ago, so yeah. This is one of the things that I am interesting into learning.

A

E

Of escape- or you know this discussion, which is how do we go back in time and do archaeology on things that you know are timing out three three years old or stuff, like that?

E

The other thing that I think the gap is great, because today is really hard to weigh and that's why we are keeping you know in a in a shared document, t number of the last one which we have shown the previous meeting. So we can, you know, follow through that. We meet twice a week, yeah that is our playlist at YouTube. We sometimes don't record it. My fault, I know: Perry Scott's been asking me to record it every time, but we recorded the last time last Thursday.

E

So if you are curious, you can take a look at that. It's, like you, know, 13 minutes.

E

C

Shared the the pointer doc that we use for API machinery, Thanks.

C

Is this it yeah.

E

Yeah how we keep track of the numbers, you also don't want to do it super sophisticated, and you know we look at github and the tools they provide.

E

We had somebody on my team some time ago, like two years ago, also build an application to see how much we were assigning to people to avoid overloading people. I, don't know, I think we want to keep it lightweight and simple if anybody is getting too much because you know the person that is running the meeting doesn't realize country, you know it's.

C

E

But it's consistent.

A

You brought up a great question and I am documenting right now, which is how do you deal with issues and key ours that are several years old old / stay all /, not stuff you're familiar with.

C

Yeah but that's that's a shortcoming of our system, because we only keep a pointer to the most recent things that we've swept through yeah. So does not allow us to sweep through the same thing twice, which is why I would love that functionality from the triage camp.

A

Steven, do you have your listening ears on on that one.

B

What yeah all right.

A

Questions concerns comments for either Fetty or API machinery triage.

E

Everybody welcome to come even just to listen and see if you like it, you want what's.

A

One thing you tried that didn't work.

E

I think trying too hard to keep track of. Who was supposed to do what you know, what was a sanctuary buddy and did they do what they said? They were going to it's impossible. It's too much I mean for the big initiatives it is. We are doing that, but you know with the amount of traffic that we get is impossible, so I realize a lot only people, basically quit is being responsible, and you know coming back to us if they feel that they can't do any more than.

A

B

I really like the idea of triage teams or having triage events, I think that I was kind of failing to see it until chatting on this call, but like release, has a set of different triage teams right, so bug triage the enhancements team. All these people that are doing I mean it's it's a lot of it as doing work so that the leads don't have to rate, and that has worked out pretty well for us at least I mean you know we have these.

B

We have it in place for essentially the quarter right. So every milestone gets a new set of people, so I'm trying to figure out how to better share that knowledge across milestones, because the like the body of I mean the body of understanding that you build up while learning how to do triage for for the enhancements are for, for bugs or for failing tests is, you know, I think, is globally useful right now, just a release, but everywhere I'm right. So this brown boy.

E

With that one, this is the space like you know, I would imagine a triage meeting is the space. Where will you get? You know failing tests and the things that you know come from the release team.

D

A

Good, that's something good to document to is like a value-add.

A

All right: well now we are at the discussion phase of our journey. We can stop reclined of don't want to stop. Recording, so do want to ask some poignant questions to y'all that I think others might take value in, but on the same topic of triage, you know same questions for you that I asked Fetty like what, if would have your groups tried that didn't work? What is what are some things that do work for your groups, anything that you want to share with your crew or maybe other open-ended questions like fetty's question: hey?

A

How do you deal with issues in PR that are several years old? Does anybody want to go? First.

F

I guess I was gonna. Ask the question: maybe it's an open-ended question like how do you? How do you come to consensus on won't fix?

F

We're like this is just too old to be relevant now or we just don't have you know we're not we're not going to get to it versus the maybe the I feel like there may be a lot of issues that remain open because we often use a much softer like yeah I mean I, guess that would be cool if you want to do it, but the amount of people who swing by and pick things up is a little low.

G

C

G

No I would say: I have.

F

Something to say, but I will not say it on the recording, okay, we we can maybe go off recording for this, but just one other example, I'll give is I feel like there are often issues I, see that periodically age into your life cycle, stale and then get refreshed perpetually and so I.

F

Take that as a signal that, like somebody, cares that it stay open, but nobody cares enough to actually do anything about it and I feel like eventually that begins to accumulate a lot of cruft and I'm, not like, like fatty I'm, not entirely sure what to do with it, because maybe sometimes these document, like known deficiencies that would be nice to fix, but they're, just there's so low priority that the history speaks for itself, that nobody has decided. It's high priority enough to do anything about.

B

Now you give her.

E

I was just going to say: I, don't have a silver bullet for that I am fortunate to be surrounded in the seek with very good people. They are very practical and I think we don't keep things open.

E

We can still be nice and have a discussion in the sig meeting about a proposal, and you know decider, says see if we want to move forward or not and see, you know give people the opportunity. We had a lot of those you know. Sometimes in the triage meetings there is an issue that is a little bit progressive or you know it's divided the opinions, so maybe that one is worse to us. The author, to you know, put a slot in the agenda of the sig meeting.

E

Coming, let's discuss it and let's see what we can do you know. That's that's my take there. I I would not just keep things open. We still have the labels, you know low priority long term.

E

C

Yeah also, this concern really pertains mostly to two issues and not PRS, and the vast majority of the things that we do in our bug. Scrub is triage PRS, let that tends to be numerically the most significant part of our triage process. I.

E

C

This might not be the same for all SIG's, but for API machinery it tends to be very PR heavy.