Kubernetes SIG Release, 13 Dec 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubernetes Release Team 1.26 Retro Part 2

Description

Kubernetes Release Team 1.26 Retro Part 2

A

Hey everyone welcome to part two of the kubernetes 126 release retro. uh My name is Jeremy I'm going to be the facilitator today.

A

uh I think James is going to take notes, but I'll also help take notes, so James can feel free to jump in on any conversation, since he's gonna be the EA for the 127 release, uh looks like we've got a pretty good set of things to go through for um almost all of the categories, so we'll uh we'll try to time box things just to make sure that we have enough time to discuss things and if we need to, we will have part three of this tomorrow.

A

uh Hopefully we can get through things today. Some give people some time back, but if not, then we will go through things. um Just a quick reminder before we get going. This meeting is covered by the kubernetes code of conduct or the cncf code of conduct. So uh please be mindful of the things you say uh in this meeting is being recorded, so it will be uploaded to YouTube at some point today.

A

All right, um this meeting should be uh respectful. We should focus on Solutions in our Communications. um This isn't really a place for this isn't a place for blaming um it's about trying to find things. We can do better next time um and recognizing the great things that happened during 126.. uh So with that started, um we will kick off with what went well uh and it looks like there's two things that weren't covered in the previous ratio: Fred from comms and Leo uh Fred. Do you want to go first.

B

uh Yeah sure um so this is actually linked with the previous Point around boards, which I think influenced them. The the result here for the feature blocks but um I think that this ability to have a cross view of the enhancements and how they relate with the opt-in feature blogs and how the feature blocks then relate with the publishing publication.

B

That's Etc really helps in a situation that we're in right now, I think that the feature Blocks part went well because we we have almost everything merged at the moment, for the feature Block series, which is composed of 16 different feature blocks running through January, so I think that for the next release, for example, this can can mean that we can, if compress, even more the the the blog release cycle, for example, if if the the the team wants it.

B

So that's just a note on the I think indirect results of using the the feature block with the feature aboard sorry.

A

Awesome uh any follow-ups to that one in another related uh boards are awesome comments.

A

All right, thanks for that, one uh Leo uh looks like you want to piggyback um on blogs.

C

Right yeah, this is this is just a quote. From slack so Tim bennissa wrote in release com said uh this: release was by far the Slick is released from the Block side of the side of things, so I just want to Echo back to that.

A

Awesome, it's great to hear all those shout outs around the blogs, I think there's those will always seem like they. They they uh are hard to get folks to commit to and get through. So it's great to see the progress there all right, uh any other things that folks would like to add or acknowledge about what went well in 126.

A

All right, let's jump into what could have gone better in Roy 26 and it looks like we left off uh with one from Divia I. Don't know if Divya is on the call, um but I'll go ahead and we have it looks like we have a few from Divya all on behalf to save docs uh I, see a Sig docs Zoom account on call. uh Does the sick, docs wanna jump in and mention anything about these.

D

I think that's actually me, but.

A

D

Login um but I was out sick for a good portion of last half of the release uh cycle, so I'm not too familiar with this haven't caught up with my slack messages: okay,.

A

Yeah no worries, let's just walk through them. um The first one is the pr for the API deprecation page was delayed. um The questions are, who should do it? When should it be done by? There are currently no timelines or deadlines set around this and who will ensure and stuff by the guideline.

D

So historically, uh various folks have updated this API dedication, page um I, see Jordan ligates uh created this PR at Jordan's done a lot of work on well for this API duplication page, including creating it I've, I've added a few entries as well, um don't, and it should be done by the enhancement owner or uh the folks working on the enhancement that might be deprecating an API. That's part of the release, that's just my opinion. uh It should be. We should clarify it more and the docs handbook about this page.

D

It's just like the feature Gates page that the enhancement owners are folks working on it on the enhancements should also update the feature Gates page- and we should add this in there as well.

A

Do we have anybody from the docs? Oh Mark go ahead, I.

E

Was just going to ask, is this something that we should add another column to the enhancements board for, like is? Is there any API deprecations as part of this, maybe to remember and aggregate it.

D

Yeah I think that's a good point, and it's uh now we should add that that's a column if there's any. uh This is also that. Would that also be useful for the API for the duplications blog as well, and it comes in mid-cycle.

A

So it sounds like maybe two actions out of that one one. We should update the docs handbook to be a little bit more crisp on on the uh responsibility and the actions to take there, uh but two sounds like: maybe we should also update the enhancements tracking board. um Does anybody want to be the owner for those.

E

I can add a column to the board.

A

Okay, that'll be super awesome. Anybody from the docs team want to take the um handbook update.

D

I give you the handbook, update.

A

All right, thank you, sick Docs, uh Grace,.

F

Yeah, instead of um adding a column, is it possible um what if we change the status column to at one like more field, so we have like graduating net new um major change and deprecation, maybe like API deprecation, can be one of that, instead of an entire column, because I'm aware that, like the board, is getting very big, very fast.

E

Yeah sometimes I think that, like especially as going to stable, they can deprecate Alpha API. So sometimes those aren't mutually exclusive or, like you can be graduating part of the API and deprecating other parts of the API, um but I think maybe we can have. We can have a follow-up discussion on slack about that and maybe get some of the API folks too, about the best way to track that.

E

That is a good point, though. There's a lot of columns on the board.

A

Okay, so going back a little bit, uh is it better to have an offline discussion about whether it's better to add a column or update the existing statuses? Or do we just want to focus on having the uh updated statuses instead of the column.

E

A

E

A quick offline discussion, okay.

A

Sounds like a good good idea.

A

All right uh any more discussion on that one before we move on.

A

Okay, cool um next one is also from Divya. Currently, the navify access is granted to the release team docs lead for the Royal handbook. um The concern is that there are a lot of moving Parts into netlify and a risk associated with delegating the club or later access proposal. Is the Sig docs Tech lead or co-chair helping with the release should be the one creating the new site on netlify, or this should be extensively documented in the handbook, and only the minimum amount of privileges need to be assigned from the network side documentation.

A

This seems to correspond to the collaborator role, we'll need to ascertain scope, whether it's all Sites or only the kubernetes main. A note needs to be made to document the cleanup of roles after the release is done. All right, I, don't know much about the notify access um Ray. Do you want to.

D

Yeah, so um so in this release, uh it's a Nutley Phi. We was granted access to the docs lead and you could do many things once you once you have certain permissions to it. You could take down commits.io, you could take down uh kubernetes six uh doc sites as well um and there's concern.

D

That is just too much permission that is uh that's granted, um and the proposal here is just is to not have the access granted to the docs uh to release doxally, but to have a sigdox tech, lead or or co-chair help with the release uh that has happened in the past I remember when I was doxied. I did not get now.

D

If I access I had a docs uh co-chair, helped me with uh create um creating, what's what's needed in netlify, which is just the the next uh doc site for if 126 was released, when uh was the action is to create a release, 125 doc, site and and at least five um that's not just the background of it um and I believe. The other proposal is to have the just minimum amount of privileges as assigned to the really stocks lead.

D

So there's two options that propose one having the uh docs calculator co-chair, helping with the lease some release Dame, um but uh this case since the release date changed. There's some there's some conflicts of schedules of that um and also I, was out as well for a good portion of the latter. Half of the latter half of the release and also the second proposal, is to have more minimal permissions granted to their winning stocks, lead so.

G

I would I would um I would suggest to start at least with um only delegating or or you know, tagging in uh the uh a docs Tech lead.

G

um If anyone has been and I I saw, Nate maybe went off mute um if anyone has uh has worked on another cncf project or something um and is familiar with kind of like how netlify is structured like if you're on another cncf project I effectively have access to delete any CC anything on on a site for um cncf, so I think so. I think one the fact that we've moved to a more scoped, kubernetes, specific doc site is a good move.

G

I still think that, because of how extensive collaborator access like the the destructive the capabilities of collaborator access, I would suggest until there is a well-documented process and a Shepherd for the docs lead to feed into Sig docs that you keep it, um you keep it pretty locked down. Yeah.

H

I I would I would second, that uh and I think that this fits into some of the ongoing discussion of the netlify cleanup that is already going on, and I would um think that this discussion should be pulled out of the release, retro and and be a part of the of that work.

H

I think that uh it's its own project, it should uh nullify, should be cleaned up and permissions for folks um uh removed, if not necessary, and um get to a baseline, where we're comfortable with how netlify is set up and then um sort of bring that back to the release team, say: okay, here's here's, how we recommend um things get get built up, moving forward, yeah.

G

I would I would flag um the specific Sig release need, but I know that there have been a few emails recently um about cleaning up netlify um access. um So so that's I believe that's already in Flight yeah.

A

All right any other comments on this one.

A

Okay, next one also is Sig. Docs related uh guidelines are on generation and cross-checking of reference documentation and the role handbook needs to be improved. This could include the following points: how to do it? What needs to be checked if regeneration, where how does it need to be checked?

A

um So is this generally just a a handbook update to reflect reality as of 126 127 later um any any gaps there? Anybody from the docs team have any better kind of clarity on this. This topic.

H

There's been I, think Ray and I have had this discussion a couple of times.

H

um It I think needs to be made easier if we want um somebody who is just coming in, who may not have um uh programming, sort of uh uh or or environment setup shops right, um and so we can either make the documentation uh better, but it's gonna be somewhat complex as is or or we could like.

H

Container container refine the whole whole thing um and say: okay, here's the button, um but that would take some coding um expertise as well, um so I'm, I'm sort of with two minds on that one I'm I'm happy to have the the process get updated in the documentation to be clearer, but even if it were made clearer I'm, not sure that it would be made any easier.

H

Necessarily if you know what I mean um and there's enough moving parts that I think that that we should, as a team, go through the process of making it a let's. Let's treat it like a project and and say: okay, we want to clean up this process so that anybody can do it um and there's a couple ways to do that.

H

I

C

D

So we've so for several releases. You've had issues generating the reference talks. um There are instructions, there's a whole web, there's a page on kubernetes that I own how to generate on how to generate the reference stocks. But it's not it's not com uh for some time. I, don't know when, during the release cycle it broke, and uh only certain folks know how to generate the reference stocks, and they both happen to be uh they both are Sig doc. Tech leads. uh So what we in my opinion. Well, we need to.

D

We need to extract that information out uh document it so that the process does not rely on uh two people, um then eventually I believe we need to to containerize it. um There was some efforts uh from a previously stocks lead to to containerize it in the past, but there was there were some gaps in the knowledge foreign.

A

So as a follow-up action to this, what specifically do you think that we could do better in 127.

C

J

Love this oh go ahead.

J

Sorry uh with this one thing that was brought up that I thought was would be really helpful, um is potentially going through kind of like almost like a game day exercise or really just kind of, like you know, doing a a smoke test or just like a dry run through the process um prior to the release was one thing that was brought up and I think that would be helpful, just kind of like go through it emulate the steps that we need to take either you know directly or have like a fake site.

J

You know developed at those steps um such that that would increase confidence with folks as they go through uh the steps on the actual release day, as as one option, I I heard that I really liked that.

H

Foreign too I think I think uh the more you can get sorted before the day of the better off we're all uh gonna, be.

J

Agreed not not that I advocate like doing your taxes as a dry run before you know, that's not as fun, but uh kubernetes release. Definitely.

A

Sounds like a good idea, it looks like people have consensus that it's a good idea. Does somebody want to take an action to Clan what that looks like and identify? You know where we want to put this into the handbooks, so we make sure that it happens. Kind of a script or.

H

This is something that would go into the and maybe there's a question for for Rey uh or any of the other talk about folk on the line.

H

um Is this something that we would want to bring up uh with the tech talks uh team and our our bi-weekly meeting and see if we um like I, said I think I think in order to get this done sort of correctly? We need to elevate this to the level of like a project like uh like I think this is a fairly big thing um me and so I think I think one person opening one issue isn't necessarily going to get it done.

J

Yeah definitely agree on that front, happy to kind of raise this up at the next Sig docs meeting and then and then push on it, where it makes sense. I think there are a lot of to Do's around updating the release uh handbook in in the context of Sig docs and so more than happy to kind of push on that and and be listed as the the owner for that, at least that umbrella issue. For all the the things need to be done more than happy to help.

A

Thanks Taylor.

J

Absolutely I'll be playing that Umbrella by Rihanna as I. Do it too Ella Ella a.

A

Nice all right any other topics or any actions. We want to record for this one.

A

All right, let's move on to the next one, uh be mindful of time um again. Another sick, docs one uh tag in release was an area that we mildly struggled with, along with the reference stocks generation, probably possible need for an update of the release team, Doc's role, handbook foreign.

A

Does anybody have any more context on this um specify what we need to specifically update in the handbook, so we can assign an action out, or should we follow up with Divya, applying to kind of identify that.

D

I think this might might be um about an issue where there are some docs that do Target the dev, the 126 Branch for.

H

D

But it's not related to specific enhancements, um I'm, not 100 sure on this, but yeah.

H

And I think some of the um the terminology in the handbook is it's it's correct, but unclear um and I think that if we did a a pass on the handbook to sort of make um what is being referred to at any given step during that process, more clear I think that we would be um taking a big step to help solve what I think. But this is referring to from from my recollection of releasing.

A

Okay, uh so sounds like an action to update the handbook or just make a password review and then identify what needs to be updated. There um Ray you're, going to be doing a handbook update from a previous action item. Do you want to look at this as well? Yeah, okay,.

A

Awesome, thank you and ping ping away. If you need any other assistants that you can light up, somebody to help all right uh next up uh any other comments or actions on that one. Before we leave on.

A

All right: next, we have a couple from uh Fred and the comms team. Do you want to lead the first discussion here, Fred.

B

Yeah, absolutely that's just yeah. Did the agenda um am I yeah, so the first one? Maybe it's just me, but um I I I had some some issues with this. um It's not absolutely clear to me. Go when I when I started, collecting the major themes and the list of mid-cycle deprecations and removals Etc.

B

What exactly was I supposed to be talking about, because then one thing is the the enhancements that are tracked and some of them are marked as removal as the application Etc and if I only looked into that, we had one removal in this cycle, but in reality we had like 12 for 13, perhaps which I only found by other methods. Maybe this is the way to do it, but if it is um it's, it's actually not so well. Documented I and I always always half afraid that I was missing.

B

um Something to be honest, so um it would, if I'm correct in that this uh removals and deprecations, because the the other part, the enhancements, I, think it's pretty much one to one so the stuff that gets into the release. It's tracked it's identified and when it isn't it's it's it's a problem for everyone. So it's it's easily added the removals in the applications. There are some that I only found out they were being removed or deprecated because they were mentioned, for example, in the major teams discussion, so um I.

B

uh What am I suggesting it would be interesting if this kind of information about what is actually going to be removed and deprecated in this release had some I, don't know, tagging or or or there was some more automated way of like selecting and seeing it, because otherwise, one who ends up by collecting the API removals going through GitHub and searching Etc, and this is a bit error prone I think this is one. um The other is easier. It's essentially about the.

B

um Where am I? Yes, it's it's about the rag status that comes gives in terms of is everything is everything, okay with the with the feature blocks, for example.

B

uh Here, that's the problem that I felt is that uh one can go from red to from from green to Red in one day, because, due to the nature of the work in in comms, we have deadlines and 80 to 90 percent of the submissions get in in the last two days, including the day of the deadline, because it's seen by most teams, as this is the day where I need to submit it.

B

So the the risk here is that either comms is always on yellow just to be on the safe side and be able to to say something or um or it's in green until one day before the release and then suddenly it it's red. This is not a huge problem, uh except when justifying. Why are you green? Why are you Red I think that if we, when possible way around this, is to have like a soft deadline and a hard deadline?

B

I'm not sold on this idea myself, because maybe this adds complexity that isn't needed, but anyway the problem is the one that I've just described. We can. We can live with with it, but still it's. um It can be a problem specifically on the last deadline, which is like one week away from the release, because we only have one week to see if the the those that missed the publishing deadline are ready or not.

J

D

A

It great those are both great topics. um The first one looks like it's mostly around.

A

How do we really track things to identify major themes? I think that's been a topic that always is an issue. um How do you classify something? That's a major theme and they're like who who really has foreign for that I? Think it's an effort of working with the the enhancements team and I think it's working with the Sig leads to help identify those things.

A

Is this something that you think um a could be fixed by having another status or something on the tracking board? Or is this something that should be a back and forth conversation with with everybody a couple hands up, uh Leo you're first, you know go first,.

C

um So, as I understood this, um this topic, it's not so much about the major themes. It's.

K

E

B

C

Yeah, it's so I I think the idea is that no you, you said it I, think in in your in in your explanation, uh for example, one idea would be to add another uh label, so another label in GitHub which we can set um to the issue or to the cap um that it marks. Basically, this is deprecation, so we can filter it.

C

um I think this is like the most straightforward, ID forward idea: I, don't know if there's like anything else or any any other idea how to track it because yeah so, for example, we had now I think one cap was marked as a deprecation and then basically all the other ones were basically just pull requests and we kind of I mean yeah. It was a little messy a little bit messy to get this information in so.

C

Something we should improve for sure.

A

Do you have any concrete suggestions other than a new label um on how that could be improved.

E

There already is a kind deprecation label, I.

G

E

Was just checking that.

B

Lots of sex I, don't think it's it. It's applied consistently. uh I I ended up doing a free text, search on GitHub and only around 10 of the stuff that ended up in the blog was marked as deprecated, so that would be ideal kind, deprecation, Milestone, V1 26, something like this. This will be trivial, so yeah.

G

Yeah- and this is this- is exactly the reason that the kind deprecation label was created. So if people are not leveraging it to the point where things are bubbling up as they need to, then we need to I. Think part of it needs to be communication about using the label.

C

Yeah perhaps I can, or somebody could also check the issue, template or the template. When you create a PR, maybe it's not mentioned there or it would.

G

C

To okay, yeah and.

B

What about removals.

B

Because they get automatically removed, one Cycle One release after that's clear to everyone, so maybe like the handbook, the world book or something to say, search for removals from the previous version and project it into this one I'm. Just thinking of how can I update the the role book to actually provide? Even if you don't make a lot of changes, if we have information on the on the rulebook, it helps the those coming next.

A

Do we want to try to include um reminders or uh some some more communication around using the kind deprecation label, as we start off the the release to get people to better use? It.

B

I think that would be yes.

E

If we want, maybe we can include that in the mail that the enhancements team goes out and say: if you're, you know, net new work, here's the enhancements project, removal work, please make sure all PRS are tagged with kind or peers, or issues of tags with kind deprecation.

A

Okay, that sounds like a good action item for you, 127 enhancement, sleeve, take.

E

Which is me so yeah I'll make sure that that gets added to the um to the role book too, if that's or the role handbook. If that's what we've decide.

A

Okay, that sounds good uh Rodolfo. You have your hand done yeah.

I

Also, we can add that suggestion into the GitHub template at creating the issue or the pull request. I think it's. It could be a good reminder.

A

E

And I'll also I'm, sorry, no I'll, say I'll also um remind all of or like change it so that when we do the Sig Outreach to for the cup collection for enhancements, that we also mentioned that to the Sig leads in slack too forward for it to please help us collect deprecations and removals.

A

Yeah, we could also add it to the next uh chairs and tech leads meeting, as just as a quick topic to include it's, probably not till January, so it'll be aligned really well, like it'll, be fresh in people's heads.

E

Yeah, that's a good idea: okay,.

A

I can add that as uh I'll take an action for that one.

A

All right uh any other discussion on that one before we move on we've got about uh 23 minutes left.

E

A

Cool, so we didn't discuss Fred's second one, uh which is around soft deadline, hard deadline, rolling window I think we always have difficulties with people getting things done by especially docs and stuff around deadlines. It's always a hard one.

A

Do we have any suggestions about improving this so that we don't have another? What didn't go so well? We're 127.

A

F

Not related to the dock size of things, um just from enhancement, I, haven't really seen soft deadlines working, it's just confusing for everyone involved, and it doesn't do what we want it to do.

G

Good great um I have said this on a few of these Retros um soft deadlines don't exist um at all uh and the deadlines that we that we state are listen. The release dates are aspirational. The deadlines that we state are are true hopes. I think it is very hard to own a date when the deliverables are the the responsible parties for the deliverables are not on your team, um so I I would say anything that exists as a soft deadline. Today should go away.

A

I see a plus one from Xander in the chat uh and then Ray, oh and a thumbs up from Nate and then Ray and Leo have their hands up and looks like Ray was first so go ahead. Raise all.

D

Right, yeah I was going to reiterate the uh there's, no such thing as a soft deadline. um As far as the docs is concerned, to get the pr placeholder uh in the past. What I've noticed uh when releases go well and getting those placeholder PR deadlines. There's been a lot of communication uh early on uh early and frequent, and that should be done in order to get those any uh placeholder PRS in.

D

That's it for me.

C

um Right so for me, I actually like this. The last point in this list is about the docs ready for reviewers deadline, which Ray also mentioned where we have actually like sort of like a soft deadline. I mean we don't really enforce it and it does not work very well. So I think introducing Microsoft deadline does not make sense um yeah.

C

A

So do we want to take an action to scrub all references to soft headlines and turn them into hard deadlines.

C

Yeah so I mean then it depends how we want to enforce it. um So this is like the next question, so probably for comms and dogs. It's always actually a little bit different.

C

um So yeah, probably we need to discussion around this and yeah.

A

A

Who was gonna who's.

L

Gonna speak right. um I was just going to ask for the soft deadlines. Does the um oh God the enhancements prr review deadline, that's kind of like a soft deadline? Does that count, or is that not count as a soft deadline for this purpose of this discussion?.

A

I think that one's owned by the prrr team- and they generally are going to review things after the soft deadline if they can like it's going to be up to bandwidth available, I think that it should be treated awesome, which my personal opinion should be treated as a hard deadline too.

A

Mark, you have your hand up.

E

Yeah I was going to say with a soft deadline for the the P or the enhancements soft deadline of the PRI deadline. I never felt like it was very clear, like what state the enhancement needed to be in before the soft deadline and what the repercussions for not being in that state were so um plus one for kind of removing the soft deadlines um like I'm, not sure if it means that you know all of the participating.

E

The cap approvers need to be signed off by it or if it just needs to be in a review, ready state or what um so I'd. Like some clarification on that too,.

A

Grace first and then Leo.

F

um I, this is an action item from the last retro I've gone ahead and removed the word soft and any reference to soft deadlines from release documentations.

F

So as far as I'm concerned going forward, prr soft deadlines do not exist anymore.

E

I think that there's still the the prr freeze and I just I, don't know if it's clear to everybody what state the tips should need to be in by that time. In order to be opted into the release like with the enhancements freeze, we have a strict set of criteria that gets that we like list people, it's like you, must have the kept at yaml, be updated with the current Milestone. You must have the latest template.

E

You must have the implementable um and and all of that, but for the the prr freeze, it's I just feel like there's, not the there's, not like a checklist to go off of.

F

um I think I added this to the documentation. Essentially, the only is that if you submit it, post prr freeze, um but you are at risk of it not being reviewed by the pr team.

A

Yeah, that's a pretty small team with like a finite amount of bandwidth and I, think there's definitely a risk of it not being reviewed, Leo and then James.

C

Maybe, like a general comment about the soft deadlines, so I think in the handbooks it does not. It makes sense to have like some sort of orientation Mark. So you should like almost have, for example, all the PRS like reviewed or something, but transporting this information to the community and saying this is now a deadline and at the end it's a soft deadline that this does not make sense. So maybe we can leave like some orientation Mark, so people maybe like in the team reach out uh again or something make sense, but yeah.

L

um I was gonna, say, I think I muddy the waters there with a bit of a PR thing. I think my comment, but what I actually wanted to point out was that the prr stuff is like different and if we're going through removing all deadlines, we shouldn't remove the pro on without first talking to the prr team. That was why should I get out I think I just confused everyone. Sorry.

E

I was actually thinking that we should make it more strict, not remove the soft deadline, but make it a hard deadline with potentially that criteria. But um if Grace said that they've done that answers need to follow up.

B

So, for my part, I I just say that I think that one easy fix for this main concern that I raised is to update the comms handbook, just mentioning that. um Well, the situation tends to be like this. A lot of uh the the the opt-ins happen uh very close to the to the deadline, and uh it's it is what it is and, and that's fine so and I agree that just adding more deadlines only makes things worse and doesn't solve anything.

B

Also for comms I would say that most of even the hard deadlines can be seen as a bit on the soft side seems to be. Ultimately, they are a bit on the it's the criteria of the consulate, the if the thing goes in or not, we have one blog. That uh was not ready at the placeholder time and we are now are now publishing it. So it's not like other processes in here which are really um hard, so I think it's it's fine.

A

Okay, in the interest of time, uh let's move on to the next one and if there's any more follow-up on this, um we can handle it in the next retro James. Do you want to say anything real quickly before we move on? You have your hand up.

L

Stuff, no sorry I forgot to lower it. Okay, cool.

A

uh Next one was Leo uh I feel like the bug. Triage team is a bit light on work. At the same time, other teams are quite busy. Maybe we can distribute the work better.

A

um Do you want to discuss that.

C

Yes, um so probably like from sex to cycle. This is a little bit different. um Obviously maybe they're like some like crazy issues, and then one team is very busy and then the next cycle. It's not the case but I think like overall I observed more or less right. The patriarch team said it little light on work and especially the Cs signal team um is not at least at the end, so probably like. There is like some option to collaborate between the teams or maybe also distribute the work better.

C

So basically, the idea is if CS signal opens up an issue. uh Battery could follow up this issue. So if there's like a like a failing job or something, um the back triage team could add it to their tracking and follow up on that and ping people and make sure this is getting resolved. So there's like some overlap, maybe but.

A

Do you think that it would be beneficial long-term to combine those teams rather than have separate bug, triage and CI signal teams, or is there enough distinct work between them that it makes sense to continue them.

C

So maybe Heba can also say something about this, how it was basically how much work it was before we had no, this Automation in place, and also the project board I feel like it's possible to combine both both teams, but at the end it it's also like an onboarding program in general. So there's like like a wider footprint of the release team, so I don't know if we want to shrinking shrinking the team in that sense, so this would be more question to the sick release leads I. Guess if that's the an option.

G

So I would I would suggest I mean if we're, if we're thinking about this, let's make a plan um kind of run through the handbooks and and see where the overlap is and see. If we can, um we can thin thin out some of the uh the responsible, we'll just spread them out.

G

um We have done this in the past. um The the test in for a role uh Catherine was a test in Philly for I. Don't remember what cycle at this point, but it was pre-120 and basically said, I'm going to delete this role and wrote enough automation, issues so like it's, it's not out of the realm of possibility. We've also moved the um this is many many moons ago at this point, um move the uh the patch release lead and the branch manager out of the release team and that that was basically the basis.

G

Those folks were the basis for the formation of the release engineering sub project right so where it's possible to optimize it. It's definitely something that we strive for. I. Do think that, because the automation is new because the responsibilities are kind of like reshuffling, I would give it at least a cycle, um and as long as we have a plan in place, I think I'd be fine. With with the leading role um it I, don't think the the value of having more people on the release team is not really realized.

G

If we're going to not have them do anything. That's.

A

True yeah, uh how about you have your hand up.

K

Yeah, just um just to follow up leave your suggestion. Thank you so much for that I've been about triage to two release ago and yes, the the work is getting really uh like. You know like nothing uh once once you have this uh my this automation for updating the uh the the GitHub project, so I I'd say we can, just you know like think about.

K

um Maybe the Urgent, um maybe the not the urgent, but the release. Blocker issues need someone to just follow up with with the owners or with the authors or the reviewers, but other than that, uh the the release the release lead can just see. These are these status for all the PRS. All the issues from the GitHub, so uh I, I, I, I, I, I, think it.

K

It will be like wiser to have the bacteria's team uh helping with other uh other rules as well, because I think you know like the beneficial from having this road right now is getting uh you know, like you know like it's getting. You know like not not what we are you know like uh seeking for to have. You know like more people, knowing the process and the being part of the release process.

A

Okay, to summarize, I think we just to keep us moving on time. um We can take a look at the overlap between the roles and identify, maybe after 127, if it makes sense to collapse them or change anything about what they're doing you don't want to have. uh It doesn't provide value for folks to be on the release team if they're not doing specific things of learning, so you don't want to have the role just to have the role so should make an action item to review both handbooks together.

A

Maybe with previous role, leads and identify what we want to do. Post 127. Does that sound like a good takeaway.

G

Yeah just to clarify, we want to be doing this during 127. yeah to make sure that we are ready to go again.

A

So that we can change in 128 if needed, yeah.

A

Okay, so does anybody want to take an action to own that one.

K

I can own this one.

A

All right uh next one and we've got just like seven minutes or so left, so we probably need to pick up things uh in the next retro for what we'll do differently, but the last one is the doc's ready. Excuse me. Excuse me, the doc's ready for reviewers deadline shortly after code freeze is not really a deadline right now, so this is another variation on the theme of deadlines. Should we enforce this deadline in some other way, uh Leo right.

C

So I mean we kind of discussed this already that we don't want to have soft deadlines and I think I mean I. Guess this or I expect I mean folks can can say something about it, but I think that's an important deadline, because otherwise I mean everybody's like super, um um it's it's very stressful to to chase chase the dogs, and we should enforce this like at some point, maybe a little later so.

C

um Perhaps it would be good to follow up on this on an issue, so I could open up an issue, so we can discuss it how to enforce it.

A

Okay, that sounds like a good uh next step for this one.

A

Okay, um any other questions on that one. Before we move on, we've got five minutes left. We can probably get to the first thing in uh and what we'll do differently and that one's gonna be mark.

A

If we don't have any more discussion on that last item, okay, so uh Leo will open a issue for the previous thing. um Mark, do you want to discuss uh track? Yes for enhancement issues.

E

um This was something that got brought up the in the middle of the 126 release. I believe what had happened was um when, after the enhancements freeze when the enhancements were getting cut from the release that didn't meet all of the criteria, um the label tracked yes was switched to attract no kind of as per the usual, um how enhancements retract and then the enhancements were also removed from the Enhancement Board and then I. Think Jordan was just a little bit confused about what the process was.

E

So this um I think there's a slight discussion said: hey, let's add it to the release retro to see what to do um with that.

E

I think what we settled on for the 126 release was we left them on the Enhancement Board, but on the main view, we added a filter that you could either that you could remove, so that only the enhancements that were tracked um get that had tracked the label track, yes, would show up on the board, but you could remove that to see all of the enhancements that were opted into, and that was to not clutter The View for the enhancements team.

E

um I don't know if anybody has any suggestions about that. It seems like we're starting to get into kind of an interesting place where we're tracking more information about the enhancements on columns on the board. But um not everybody like that. That's not that the who has access to flip those uh those column Fields is a smaller set than who has access to set the labels, and all that um so I didn't put much thought into this past um past.

E

What was kind of disgusting slack, but I, don't know if anybody else has any thoughts on how the track yes and tracked No Labels or should be used moving forward. I know that's part of my well, that's. That was the next step for me for updating the whole handbook was to document that and figure that out, um but Leo.

C

I I think this is like a little bit. I mean we use this project board now for the first time this Cycles. So this is kind of I I guess expected that there's like some some hiccups or some like small problems or something like especially around this time, uh Jordan wrote this message. There was I think it was after code freeze, something we archived a lot of like action items by mistake. We archive them again so there's like some getting used to working with the project board.

C

I think how we did it now is fine I'm I'm. Okay with that, so.

E

I think that keeping them on the board, but adding filters to remove the ones that are not actively being tracked, is probably the best path forward here. uh Frederico.

B

Yes, uh very quickly about this I think the boards are amazing, but linked with this I think it would. It would be very interesting for everyone in every different team to actually look into the boards collectively and try to find a consistent way to actually drag and add the necessary information so that it works for for everyone. I know that for comms I I I we created something that inherited the tracking, then in enhancements and added more.

B

If we could then see how this works with, for example, passing the information to sigdocs or um or or others I think that's, we tried things the first time in this version in the next one. It perhaps would be a good idea to have a more um global view on the boards and on the needs of every specific team, so that we don't create things uh apart from, for example, identical fields that can be reused and make things more complex than they need to be.

E

Yeah I think when we started the 126 release, we had a very small amount of columns and then it just kind of grew organically to add all of the prrr columns and then the docs and comms columns um so I agree. We probably should reevaluate that and maybe make a little bit more of a to like intentional effort around what columns are on the board. At some point.

G

So I think we also have um that these are automated right and some way or shape or form, or is it strictly manual configuration.

E

uh For creating the columns or for the.

G

Board configuration itself.

E

um It's manual right now: I have an open issue in the GitHub project, board's feedback about having a way to automate this um with a couple of suggestions either having like a template or the the graphql queries. There's no mutations for adding columns right now, unfortunately, gotcha because.

G

What I was going to say is the you: have a configuration per team and have those munged to create the you know create each of the filters um for the board yeah and then you can and then you can delegate owners to those configurations too.

A

All right, so we have hit the top of the hour, which is our allotted time for today. um If we have any more discussion on this one, it seems like. We've got a couple of good uh things to follow up on revisiting.

A

Tuesday, oh man, Series going crazy on my watch um sounds like we. uh We have a couple of things to take a look at geez.

A

uh That was that was great. Yeah I have no idea how that just happened um started playing back. That's great, uh okay! So a couple things to take away from this one. We need to look at. What's the right thing to have on the board, um I think there was a follow-up item from Grace later on when's a good time to wipe the Enhancement Board. What signals do we need from that? So maybe we can take a look at that too, um as we we think about the life cycle of the boards.

A

um We can pick that up in uh part three of the Retro um I think we'll have to schedule that for tomorrow, there's a few things left here and then quite a few things in the parking lot. uh So we either have retro part three or we can take some of these things. Asynchronously I'll leave that to uh to James and nabaroon to kind of figure out for following up for the release uh with that said, I hope everybody has a great day a great rest of your evening day.

A

Whatever time it might be for you, and uh thanks so much for your feedback and participation in this retro, and we will stop the recording there and pick it up for part three. However, that's going to unfold um stay tuned, for some, uh of course become some comms and probably instead release uh on what what that'll look like all right. Thanks.

I