GitLab Package Registry Group, 9 Feb 2023

►

From YouTube: 2023-02-09 Package Registry Weekly Team Sync

Description

Package Registry group's weekly meeting for announcements and team discussion.

0:00 Intro
0:27 Announcements
1:24 Current milestone, 15.9 discussion
7:40 Refinement process for upcoming milestones
17:03 Meeting attendance optional topic
21:10 End - nothing else to see

************************************
Links:
- Last week's async team retrospective via issue comments: https://gitlab.com/gitlab-org/ci-cd/package-stage/package-registry-group/package-registry/-/issues/15#note_1264002558
- Current Team Weekly Update: https://gitlab.com/gitlab-org/ci-cd/package-stage/package-registry-group/package-registry/-/issues/17
- Meeting attendance optional: https://about.gitlab.com/company/culture/all-remote/meetings/#1-make-meeting-attendance-optional
- Article written by another GitLab EM sharing his experience going async for a week: https://sam.beckham.io/wrote/all-meetings-are-optional

A

C

Just bought the health level 2 needs attention.

A

Awesome, thank you for the update and those things happen, but at least you caught it while testing and our users are not going to to see that. So, thanks for the update any other um thoughts about the current Milestone that might affect the deliverables.

B

Not about the deliverables but I have more general question remark: issue with the check on the Milestone issue. uh What does it mean? Is it like? uh We will be working on that or if it's like, the issue is finished or what this check is actually means, foreign.

C

Planning issues um the check was I, guess we can change the meaning, but it was. Someone is working on that so that when you need to pick another issue, you just check the Milestone issue and those with with checks. You, like you, don't have to open them, because there is already already someone working on that now.

C

This can be changed because it's it's all manual, so this can be changed, of course, and if an issue is done once you verify an issue, it should be closed and since now we are linking the the full title of the issue, you should be able to see the closed suffix at the end. So you know that that issue doesn't need to be worked on.

B

Thanks.

A

That's a great question and thank you David for the answer.

A

Any other questions about the current Milestone or our thoughts about our our process on how we document go ahead.

D

uh Carey uh in under quality for the first one test may even request forwarding uh Sophia has moved it to backlog this. This fall under the current Milestone still.

A

So if it has a deliverable label is what we're looking for and a package P1 label. Those are what we want to track. um I, don't think it has that. Does it.

D

Yeah, it doesn't happen. Okay,.

A

So then we we don't have to report that it was uh slipped but I, guess that's a good question in the future. We might want to Mark those QA items as deliverables I'll. Let you um think about that and we can iteratively change our processes as we go.

D

Yeah sure, thank you.

A

Cool, um so the next topic is the upcoming Milestone 15.10.

A

It will be kicking off, February 18th 17th, one of those days um we'll go with that and then, um as we want to prepare for the Milestone, we want to make sure that everything marked as a deliverable has a weight Associated to it and if it doesn't then I add the workflow refinement label and those are issues that we want to review before the Milestone kicks off. So there are two items currently marked with the refinement label: I I guess it would be good uh David.

A

Can you share your thoughts on how refinement usually goes in preparement for each Milestone? From your perspective,.

C

um Yeah so refinement from Engineers. um We are expected to uh check the issue and check if it has a clear description, a clear scope and a clear plan to move forward.

C

um That's the basic stuff. um We should ping counterparts if we need them. For example, let's say that uh it's a documentation update.

C

We should ping Clayton so that he's aware that there is work on on that milestone for him.

C

Once we have the scope, we need to evaluate the complexity of the issue, and that's that's that that is what the way it means so wait. One two three we.

E

Never.

C

Go above three: if we need to go above three, then usually it's a flag that the issue needs to be split into different issues. It is too big uh uh and, lastly, labels uh ones that everything is done. We can apply I, think it's Works already for development table.

C

um This whole thing happens without uh assigning the issue so that that's a discussion uh we are having with scary, which is, um as the team is growing. We don't want two Engineers working on refining the same issue. That would be a waste of time, so yeah we're thinking how to how to do this. How to signal that someone is refining an issue.

C

um Our ideas welcome so far. I think the best bet is perhaps using a new label to indicate that refining is ongoing, um but we are still open to 20 ideas.

A

And the important part about not wanting to assign anybody is that gives a signal that we're working on it to the larger community, and so if someone from the outside is looking at that issue, they might think. Oh, it's already prioritized and getting ready to get started, but we don't want to give that impression because uh we not might not have the capacity to get started on it anytime soon. We just want to see what the scope is and if it is possible to pull it in. Based on the analysis, that's done.

A

I think the label makes a lot of sense. I know that was a lot of information to process uh since we're a new newish team. So I'll just pause for a moment to see. If anybody has thoughts to add if they like the idea or if they maybe have another idea.

B

I like this idea of having additional the separated label, maybe it also can be grouped to workflow like workflow refinement, then maybe it also can be used by other teams. I, don't know I.

A

Think the double colons on workflow means it can only be one of those. So if you have it as workflow refinement, actually I don't know if it uses the double colon or not. um Oh.

C

It is okay.

A

So it can only be if it's in workflow refinement, then it can't be another workflow status, um so we.

D

Would have to.

A

Pick something different.

B

But I I just saw that. Maybe um if issue has labeled workflow refinement, then it shouldn't have another label workflow.

B

And then we just I mean it's like prepare for development right.

A

Maybe there is another label already I'll have to look to see in refinement. Maybe that's one workflow refinement, I'll I'll check and we can take this offline. um That's a really good idea, though, um and I'll see what it takes to propose: a new workflow label as well.

A

And I'll just capture that real quick does anyone else, have any thoughts or ideas to add.

C

Yeah I wanted to add two things. First, the refinement on an issue should be time boxed uh in the sense that you don't want to spend like a full day to refine one issue. That's not the idea. uh It's just to get the feeling of the scope, the description and the complexity and the other thing.

C

Well, perhaps we could change that, but the idea was the engineer that does the refinement doesn't mean that it will get the implementation uh it's just. Okay, it's just confirming that the issue is is ready to be worked on and that's it, but that doesn't mean that it will be the same member that will be working on that issue.

A

That's great great points, thank you for adding those.

E

uh If we're not assigning an issue, how do we record, who is doing.

A

The.

E

Refining on the issue, and where do we record it.

A

I think that's the idea of this proposed label, but it isn't really clear who's doing it. So that is a good question. I guess you can see who added that label, um but is it important to know who's doing that? Would that be a good.

A

Maybe a comment on the issue: I'm not sure. That's a good question, though, um something to think about.

E

I guess it makes sense if we're trying to ensure that the refinement load is evenly distributed. But if, unless that is that an objective and immediate objective, then I guess just the label is good enough.

A

I appreciate y'all, letting me type and having the silence in the meeting. It's also a good time to process what we're talking about.

A

um I think we can iteratively work on this, so I'll pause here on this conversation, y'all presented a lot of good feedback and maybe I'll turn this into an issue, and we can continue the discussion async there um for the next steps.

A

Okay, so next topic is pain. Discussion, section um I wanted to kind of take an opportunity in our weekly team since to talk about maybe a value or a part of gitlab that we want to all incorporate, and so this week I wanted to talk about meeting attendance being optional.

A

I included a link and I'll link it in the video as well. But there is a part of our company. Culture is to make meeting attendance optional and I want to share some tips and tricks from my perspective and then open up the discussion to hear other people's ideas on what they think about our approach to meetings.

A

So from my perspective, all meetings uh should have an agenda with a purpose or the meeting should be canceled and I want to remind you that it is okay to not attend this meeting uh and all meetings in general.

A

um But if you aren't able to attend a meeting for this meeting, if you could add your name beforehand to the not attending list, if able and then contribute to the agenda asynchronous, that will allow your voice to be included in the conversation when we have the meeting as a group also look for the recording afterwards.

A

If you want to see the discussion at a later time- and we have a new package registry group uh playlist that will get included in on YouTube and then also if you are not getting value from the meeting, it is okay to leave at any time and I will not take offense if you just drop off I trust that you're making the best decision for you and the time that you have to do things. So this is definitely uh different than a lot of other places.

A

So I wanted to remind everybody that this is optional and async contributions are completely acceptable. I know we have some people here that are is quite late for them, um and so it's uh just a good topic.

A

I also found an article that was written by a another em here at gitlab and I'll put a link to that in the recording as well, but he shared his experience about going async for a week he had expressed in that article. He felt like he needed to play catch-up and had too much going on, so he posted uh for a week that he would be doing everything async and was able to catch up, and that is uh definitely allowed and if you ever feel like you want to do that feel free.

A

Just give us a you know, communication through slack to let us know that you'll be doing that and just wanted to to share that article I thought that was really interesting.

A

um Those are my thoughts about our meetings and the approach that gitlab takes to attendance. Does anybody else want to add any additional thoughts.

C

uh I would say that it is even okay, so at the end of the meeting and be working on something else, that's something I uh often.

A

See.

C

And like there is no offense from that, it is totally okay, so something to to have in mind.

A

I agree 100 and thank you for bringing that point up any other things that people want to add that are good to remember.

A

Cool well um without further Ado, we'll end it here and continue on with a little bit of a team building exercise um offline. So thanks all hold on just a second.