VMware Carvel Community Meetings, 27 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Carvel Office Hours - May 27, 2021

Description

Carvel Office Hours - May 27, 2021
We meet every 2nd and 4th Thursday of the month at 11:30am PT and would love to have you join us live!

This week's office hours focused on discussion surrounding issue triage processes and best practices. If you have any feedback you wish to share after viewing, please reach out to us on slack: https://kubernetes.slack.com/archives/CH8KCCKA5

Notes + agenda from this meeting can be found here: https://hackmd.io/5Bh2IXwTShSrA0YdBY4AGg#May-27-2021

A

All right, hi everyone welcome to this week's edition of the carnival office hours. These are held every second and fourth thursday of the month at 11, 30 a.m. Pacific time, 2, 30, pm eastern time. It's an opportunity for users to come and get help from the maintainers anything. They have need more in-depth help, in-depth help on or any pending, questions that you have about a cargo tool suite or if you just want to come and listen in whatever the maintainers are working on or have. Discussions on. This is a really good opportunity for that.

A

Just a reminder that we are recording this and it's uploaded to our our youtube playlist, and we ask that everyone that attends these meetings read and abide by our code of conduct which can be found here in the agenda.

A

If you aren't able to attend the office hours, we also meet every monday for our community meetings at 11. 30 am pacific time and that's just um where the maintainers will go over some of the items they are working on based on the project roadmap, and you can also listen in and ask for any help. You may have in that meeting as well. We are not meeting next monday for that community meeting, so the next opportunity for you would be on monday june. 7Th, I believe, is the date for that when you attend the meetings.

A

We also ask that you put in your name and the organization that you represent. If there is one that you are representing all the time these meetings, it's just a way for us to keep track of folks from the community that engage with us in this way and we can keep the conversations going outside of the meeting and other opportunities you have to engage with us include the kubernetes slack workspace and the cargo channel and then on twitter at carville underscore dev, that's dev!

A

Today we have uh just one item on our discussion topics area, but if you have anything that you wish to discuss, uh please add that to the discussion topics here, if there's any open questions or help, you may need add it to the section just below that and with that I'm going to kick it on over to john to go over the discussion topic.

B

Cool thanks nancy all right. So this the first topic here is I'm going to share my screen. Have the doc up.

C

There we go, you see that one moment trying to get. Oh hello.

C

There we go, you can see that that tab, yep.

B

Okay cool, so at one point we had a uh we're really trying to get ourselves organized about. How do we deal with um and give uh respectful attention to community input through github issues, and when we first created this, so we wanted to propose how we would approach that.

B

So when this document first came into being, it was some many many months ago, and it was about trying to get to rally around a particular approach and within that there was a whole lot of conversation about just overall workflow and then possible ways in which we can automate that workflow and all of it was geared toward trying to having a consistent way to handle that work so that community members had the same experience, regardless of which of the karbal teams they were interacting with or which boards they were in with which github repos.

B

They were looking at that. It was um consistent in a helpful way and we made a lot of progress. We made a lot of progress. There are a bunch of stuff in that proposal around how to automate things and uh making our backlogs more public and we've done a lot of that work, um and then we were looking to evolve it to the next step.

B

So uh within uh one of the carvel teams, the the uh kubernetes lifecycle team, um there's there's like a particular significant amount of stuff that we know that we haven't been able to get to, um and part of it is, is that it's hard to know what items need attention and what kind of attention and what kind of uh context somebody would need to have and able to like move an issue forward.

B

um It's not just some ideas, it's hard to make heads or tails of whether or not they are relevant for the project or if they are, are they timely and uh is it something we want to commit to? We want to be really careful. We want to try and be clear about what what can the maintainers work on what work?

B

Even if the maintainers can't work on would be great to work on and we would accept those contributions and what items are either too fuzzy or or out of the scope for what the projects are trying to accomplish, and that's not always obvious um from the outside, so trying to help make that more clear, that's sort of the overall, it's been our overall goal.

B

So um so this proposal got reused just and it's starting to turn into more of like a process, definition document. So there's a lot of stuff that was describing it. So we sort of just repurposed it for that.

B

So I thought it'd be useful if we kind of went over this together, um synchronously to kind of have a shared idea of what's being described here, and we can talk about um where to go from there.

B

um So I I don't think we haven't updated the goals and anti-goals here. I think this is in in this data. It's a sort of kind of a remnant of it being a proposal we'll probably end up uh reworking that into something that reads more like this is how we're doing it. So it becomes a more of an authoritative talk rather than just a proposal, so we'll skip over that. For now the first section was about labels. It's handy to just sort of have these loaded up.

B

As we talk about the issue states and the workflow steps, you can kind of see where we're going in the outline over here. If you want to cheat and look ahead, but so from from from the top there's sort of three different kind of categories of labels, there are the types of issues that there are.

B

There are different states that an issue would go through or a condition that can be attributed to an issue and then, whether or not they're sort of like an additional adjective about the issue, for example, if this is a a great issue for someone who's new to the project, wants to contribute.

B

Is this something where it's sufficiently valuable yet not requiring a ton of context to work on, for example,.

B

So as you're looking over those any any comments or ideas pop up.

C

D

Will ready for dev be a subset of recommended.

B

That's a good question. I think that so the meaning of these are different. The ready for dev says that it had that it's sufficiently precise, like it, has a definition of done so it could be precisely specified, but it's not targeted to be prioritized into the maintainers backlog.

D

Okay, yeah, that's sort of what I was getting at. It's like ready for deaf is just something that if I was somebody wanting to contribute and wasn't looking for like good first issue or something like that, like I had contributed before, I could look for ready for death, like that's the go-to one for maybe more experienced contributors or something that aren't following our backlog or something yeah. That's perfect!.

B

Yeah, I think daniel identified asynchronously some potential overlap here on can be replicated. So the intention of this label was to note when a bug wasn't just recognized as hey yeah. That looks like a potential problem, but we actually did the work to verify. Yeah I've actually seen this myself. I can replicate it. um There's a proposal on the table of like that. Might just well be what carville accepted means for a bug like you couldn't carvel accept it.

B

We would make that a definition of carbo accepted for a bug it's like well you'd have to have replicated it in order to accept it.

C

So that was one that seems like that made a lot of sense.

D

Do we expect that life cycle, um assuming for now it can be replicated, is kept like whether or not that gets folded into carnival accepted? I don't think matters for this question, but would we expect it to be like carbo-triage we work on it, replicate it see that it can be replicated, then. Would it go to like ready for dev once we sort of outline what the solution or what we want the thing to look like and then recommended from there or would we expect people to just pick up something that can be replicated.

B

I see I see so it's not just that the defect was identified. There's this additional step of that's great, but what would the solution be and yeah.

D

And okay, I see- and maybe that's obvious for most bugs, which is maybe true like. If you see a panic, the solution is, don't panic or like find a way to make it better, but right just curious. If we want to sort of bake that potential scenario of like it's a bug, but how do we want to fix it into the life cycle of a bug issue.

B

Yeah yeah. That makes a lot of sense. The way that you described that sequence of events. What also occurs to me is part of what we're also trying to do here, and I forgot about this and that sort of preamble part of what prompted us to like, really take a hard. Second look at this and come back to this proposal and make a process definition was that we wanted to be able to break down the work required to move a story along so that um we could do little chunks to at least kick it forward.

B

So it'd be nice to be able to like hey. If I see that there's a new bug and it needs to get replicated, I could like do that replication put in my research notes, mark it as replicated and now whoever comes back to that, can just at a glance. No, oh, I don't see a definition of done here, but it's been replicated. I could probably take the next 20 30 minutes, maybe and like add that piece. So it's a way of kind of.

B

Minimizing the getting started to get ready to get going time on a particular issue, so that is one one possibility that might like help like I'd say. You know what I mean: let's just sort of hang on to that label, so to make that clearer.

D

And it could also, I mean if the fix is obvious, it could just jump straight to like ready for dev or something right.

B

B

Yeah, so maybe if we look through some of the this is the the issue states, this sort of implies a workflow too. So if you look at the outline here, uh hopefully you recognize these these names. These words these actually match well to the zen hub. They call them pipelines. That's the the columns in the zenhub board. That's what we're using to track our backlog.

B

um It is available to anybody. You have to install the xenom plugin. So that's when later question about like what do we what's sort of the the front door for somebody who would want to contribute um today would be if you please install this in-home plug-in and then you can sort of see that, but maybe we want to do something even more low-tech anyway. So these are those different states. So ideally these these help describe.

B

If you look in zenhub, you would see an issue um in one of those swim lanes, um then the issues in there, ideally they would be- um would meet that definition.

E

uh Are you showing us something, john.

B

uh You know what I did. I shared a tab as opposed to a window. I think yeah, sorry about that. That's all right! Let's.

C

B

C

On the dock, then.

B

All right, thank you, joao. So the first issue is the first state is new issues, and so the way this intended to be read is like the name of the state, quick description.

B

What labels get it added or removed coming into this state, so add carbo, triage and also whether it's a bug or enhancement, and then what happens here so what happens here depends on the role and where this is, where we're trying to like divide up the the work so we're working on um making this more public.

B

But we have like a contributor model that we're that revolving that basically has three roles: a contributor, uh a reviewer and an approver, and with each of those um roles, there's an ever-increasing amount of required context um like understanding and expertise and a commitment to uh doing more, more work, more proactively, doing work with within uh that particular tool.

B

So, each tool we have in our portfolio in the carnival suite uh we have folks who've made commitments based off of like their ability to do so and their desire to do so, um and so that's what this reviewer and approver mean those are someone who has enough context to understand, what's the scope of the tool and um and has confidence that they can make decisions about yeah. This is in scope or and sometimes even be able to have a sense of yeah. Actually, this is a priority.

B

We can actually like pull this into the maintainers backlog. That's what I mean by priority, then the other role is the community pair, so this is meant to be really kind of almost anybody um within our teams. We have a practice of dedicating time during the week to servicing um community sourced issues and uh and interrupts like that's why we have responsive times on on slack in part because of the community pair.

B

So these are these two roles, so, if you're playing community pair for that day, then one of the things you can do is look in the new issues, column and triage a bug. This is a link down into another section of the document that describes that process, but the tldr is. You got three possible outcomes for a particular issue.

B

If you don't know if this is undesired, behavior or not like it's not obvious that this is actually a defect as a community pair, you just skip it. That's fine like if you don't know, that's cool.

B

um If, uh if it is clear that it's undesirable and it often is, then if you can reproduce it, then you record the work that you did you record what someone would need to do in order to reproduce it and you drop that label on there um and if it's not re reproducible, then maybe there's you it's obvious to you like.

B

Oh, if we just knew this or if we could ask the user to provide more information that could help us reproduce it, and so this way, like a community pair, goes through and they're looking for something in new issues that it hasn't yet been replicated.

B

So that's one thing that they can do and then the reviewer approver they can also triage uh bugs um and ideally because this person has that context and their that focus they'd be able to actually know whether or not this is actually an undesired behavior and so give the rationale and close the issue at that point, that doesn't mean we like shut the door on the conversation, but this is like a determination like actually we wouldn't fix this because of this reason- and hopefully we understood- if not like- let's keep the conversation going but to keep things clear.

B

We close the issue.

B

If whether or not it's not clear whether or not it's relevant, that is there's not enough information to make that determination. Then we can describe that and we turn this into we're starting a discussion. Like not sure I understand exactly.

B

I can't tell that it's in or out, but let's talk about that and here here's a couple questions that I have so that's a bug. If it's a feature, it's a very there's, similar steps that you take here, um but then there's these other parts where, when we know that it's relevant- and we don't know- but we don't know, um we don't yet have a clear definition of done. At least we know it's relevant, so we can say: okay, we're going to accept this. It's a preliminary like yeah.

B

This looks like this is in scope and then you, then it gets moved into that swim lane or that uh that column the pipeline, and so these are just links into the within the same document here that just says: okay, we'll go to that step, and that's literally the next one. So either.

E

Sorry yeah, um I don't think you're showing us what you're pointing to I'm, not no, we. The last thing I can see is triage a feature with a link.

D

I don't see your cursor anywhere.

B

Yeah so like something.

D

B

I didn't I didn't share. Well, let me just share my desktop. I'm not sure why that's not working right. I tried to share that my browser.

B

Can you see my mouse moving around now? Okay, thanks for saying something yeah, so I was talk. I was talking about this section here and was pointing out that that, in these last three possible outcomes, we're actually pointing to like where, where would you move the issue after you've done, whatever work was needed.

B

So I'm just gonna pause here. That was really a lot to say, comments, questions it's just useful. This is.

C

What could make it more useful.

D

C

D

F

Okay, one thing that I noticed is like you could go straight into the unprioritized or prioritized backlog, um but that insinuates that you would be like applying the labels from the previous swim lanes, because there's not like you're going to remove the carville triage label if you go into the unprioritized backlog. I remember from that section.

B

Yeah, that's a great point that, like what's not detailed here clearly excuse me, is that when you've made that determination like a clear definition of done, that, uh that you add the ready for dev uh label there and they.

E

B

The carville accepted right, yeah yeah, that's a great point, okay, so what would we want to do? Would we want to just make sure that hey when you do that, just make you apply all those labels and or just say well what you care about is like what labels are relevant for that particular pipeline.

F

I think I wouldn't want to see a cargo triage and a ready for dev on the same issue. Yeah yeah, that's the most I can ask for. I feel like, but going beyond that, making a stop at carl accepted. Do the labels. You know what, if you can just go straight down prioritize then do the labels of carbo accepted and unprioritized.

C

A little extra work.

C

C

Eli, look like you had a thought.

D

Yeah, it's sort of related.

D

um How do we see these ideas of zenhub swim lanes, interacting with issue labels, in the sense that if we make a contribution doc that says you know search for issues that are ready for dev or something like that? But I assume some of the prioritized backlog where things have been talked about. There's sort of existing context isn't something that we would want people to just jump in and pick up on their own without at least building up. Some of that context.

D

So like is there some interaction between where an issue is and it's column, first, what its labels are and what those labels mean.

B

Yeah, let's see, there's a lot of good stuff in there. So one thing that I heard in there was as an outside contributor: how could I make heads or tails between what labels I see on an issue? If I'm just looking at a list of issues, let's say I'm just search for ready for dev.

B

How do I know from that list? The things that are available for um that have already been kind of marked as like? Oh the maintainers are going to work on this versus stuff. That isn't.

D

Yeah yeah or like is that something we want to consider of like there's potentially built up context and all issues that are ready for dev may not be able to may not be able to be picked up without some of that shared context. Being.

B

Disseminated yeah: that's a that's! A great idea like there's some way to indicate that.

B

Yeah, because that is like one of ultimately be great if we could just support that scenario with without like just automatically like, if we can get to a point where the way we manage our work just makes it obvious what the disjoint that is available uh for others to contribute.

B

Yeah, so I like that as a refinement in terms of, like maybe another label here, that describes like significant context or something.

D

Yeah, just something that like distinguishes further and ready for.

D

C

Available on the issue right now, um conversation with a maintainer would be needed to uh start complete. This issue successfully. Does that capture? You know what you're thinking about there.

C

A

C

A

Have you seen this the document that aaron was working on and it's it's in progress in the repo, the cargo dash community, repo.

C

I have not seen this.

C

A

It sounds like he was also working on something similar. This would, it hasn't touched it in a while, but.

B

Yeah this looks like I think this is what we're doing today.

A

B

So cool yeah, in terms of like, like a canonical definition for these things, is that what you mean or just like hey? Are you aware that this other effort is happening.

A

A little bit of both so um he had put this in the governance stock, but um when jonas and I had taken a look at it, we felt that it should be in contributing, which is, I think, is also what you're thinking yep and I to help with the the checklist to make sure um the repo is healthy. uh I've been working on some of these documents so to alleviate the team, and one of the things I was going to work on was the contributing duck.

A

So it sounds like what we're discussing right now is going to lead towards the information. That's going to be added to that contributing doc so I'll table that until more discussion is add on on these labels,.

B

Okay, that's good to know just that, like that's happening as well,.

D

B

Okay, cool. Thank you.

E

For sure, uh so the change that you linked there. It was part of an initial uh initial goal that we made on adding like this information on a more public way, and what we're discussing today is like an evolution from it. So aaron is not like actively working in parallel on something like this. So.

A

Okay, awesome. Thank you for that.

E

C

Appreciate it, it's like we're a distributed team or something.

B

Cool okay, anything else about like the new issues stuff and how we're can you envision like how, as new things come in that, like folks, can kick it forward, regardless of if they have a lot of context or not a lot of context, they can help contribute to like at least bake the the.

E

Issue cool uh something that like about what we were talking before I. I hope that this is my hope that when an issue gets to uh the prioritized backlog, it has enough information that anybody can pick it up.

E

That's my expectation, it doesn't mean that everybody should pick it up, because, if, like the signal that we want to have between the end prioritize backlog and the prioritized backlog it it is more, this is going to be. The prioritized backlog is the work that us, the core team, is going to be working actively.

F

E

If you, if you are not a core member of the team- and you want to pick up one of these stories, it should be okay. But you need to be aware that there's an expectation that this would be done pretty quickly or in a very quick pace.

F

E

In the end, my expectation would be that having a sorting and then prioritize backlog or prioritize backlog should have exactly the same amount of.

E

Information on it.

B

Yeah- and so I'm part of what I'm hearing in that is that this label could be could become problematic, then because then, then it's a step back from that that like, if there is context, then you should put it in there.

E

Yeah, I think I think that I think that's what's that's what makes the the pipeline work right like if we have these steps and if you get things for ready to be developed, they should have like enough information for people to be able to develop it.

B

Do you mind, do you mind popping in the dock and dropping that comment on there? That? Because that's a really great point.

C

C

B

So then the then the next column is carval accepted, and this is where we know that it's viable it's product viable, um but it hasn't been prioritized. So what that means is it's relevant sufficiently, but whether or not this is something that the maintainer teams can get to is not known yet, and it may not have a great definition of done either, but at least we know enough.

B

That's like oh yeah. This sounds like you know it's within the scope of the project.

B

We think that kind of anybody can look through these and take a look and see whether or not well is there a definition of done, and if, if I can take a crack at that, then I can add the acceptance criteria and, if not, ask clarifying questions is one option as we're working our way through those items in that column, um if there already is a clear definition of done, um but we're not sure what the priority like and it's not clear whether or not this is something that we're already like.

B

Maybe it's in it's it's not in the set of things we're already working on. That might be one reason why somebody may just intuitively know like oh yeah. This would be something we would prioritize because we're already working on that specific feature or something.

B

But if it wasn't, then it would go into the unprioritized.

B

Backlog, I'm going to kind of roll through these and just interrupt me if you have thoughts so the the the there are two backlogs then there's a backlog that specifically has prioritization, which what we mean really is that it's prioritized for the maintainer teams.

B

So once you get once you get into carville accepted, that means that it's like legit, it's viable, so you can you can um we rest assured that I mean uh that the spirit of of that request or or defect would be like something we would want to accept.

B

So that gives you that little extra confidence and then unprioritized just means we haven't yet determined whether or not it's something we're going to do. Right now could be, could not be, and so this would be a great column for somebody who is looking to contribute to like focus their like focus their attention on if they're looking in zenhub.

A

Now, would that mean that those issues just remain open.

A

While they're they're hanging out in the unprioritized yeah, I think.

B

I think at some point somewhere we were talking about and have some stalin do do we do have our stale bot working. We had one point. We were looking at that.

E

So we have this tail bot working, but only for carbon triage labels, okay, not for anything else, and the idea would be for the unprioritized backlog to keep the the issues open, because it's something that we think it makes sense for the tool.

E

But we as a core team haven't got around, can handle like possibility to go around and implement it. So it is something that should be viable, but we need. We need help.

A

Okay, I'm wondering if we can put a label because there's is it? Would there be a clear label when someone's going through the issues and they can automatically see that it's unprioritized, I'm curious, if, like? If you, if there's like someone who wants to contribute, you can just say hey. Actually, we need help. Here's some check out these then prioritized and see if anything interests you.

B

Yeah, that's that's exactly the kind of question um I feel like we're going to get to, like that's the kind of scenario that I would love to just like. Have that just fall out so today we could say well, if you look in the unprioritized backlog like anything after carville accepted uh these. Ideally this is not the state. This is not the case right now. We're we're talking about evolving, not the evolved process, but ideally everything in here would be marked as ready for dev, for example, and then.

B

So yeah, so so so that's close, I think we're getting with the k. You know we're starting to get there now now. If everything in here actually had ready for dev, then we could say: oh you want to contribute, go, take a look at the zen hub, look in the unprioritized backlog uh pipeline and find something that you're interested in like and that actually is not bad.

A

B

At that point, because.

A

You have the confidence that.

B

You've come through those other two swim lanes: yeah it'd, be even better if it's clear that something's hanging out an unprioritized backlog only because we just haven't made a commitment as a maintainer team like oh, it's probably a strong consideration, but we don't know yet uh or if it's like yeah, not it. It is not going to happen right now for like in terms of priority.

B

um That is a potentially good segue to talk about the recommended label here. So if an issue is in that pipeline and someone sees it and says, actually I I I don't think that those who are like officially kind of like setting the priorities like either see or understand the prior. The priority of this particular issue you could drop. The a lightweight thing would just be to leave a comment and drop a flag drop, the label, the recommended label on there, and that means hey the next time you go to review the backlog.

B

Please look for the recommended, see if there's any recommended um issues in the um prioritize and consider those. So that's one very lightweight way of asynchronously signaling. We think this should be a priority now that could also be a way for signaling. This is like this is a candidate for maybe being prioritized to the maintainers backlog.

B

So, if you're not wanting to start on something that could get started on the maintainers, like avoid avoid that, while that label is on that.

B

B

And then, like I was saying like these these headings, these are the different roles, so the group that's like doing that. Prioritization. We call that the balanced leadership, team or blt for short and what they'll be doing is looking to see um either they're they're, just straight up plucking issues out of the unprioritized backlog, because they already know they're like okay, we're going to pull these in now. These are these are ready to to work, and we need to make sure that they're sufficient for pointing and shovel ready and also if there are specifically recommendations.

B

So these are these kind of two steps that they could.

B

Take- and this could be a way of like communicating back here what you said- here's some additional context that maybe is not clear or available or known, and this is why we think it may not be a priority right now. Remove remove recommended label.

B

Cool all right and then the prioritize backlog is like the backlog for the maintainer teams, and so, if anything is in is in that column.

B

um Well, these are the epic, so we're really talking about the the individual items here. These are things that the team is either is about to pick up is slated to pick up soon, and this is like across the projects. I just have it filtered right now, but.

C

It's all of the carnival stuff all the cover we buzz.

B

Cool so then, as a maintainer, you work a story here. Here's something that we don't do consistently today is like assigning ourselves to the story to make it clear, like who's working on what that'd be great. If we can sort of get to that, um and if we're pairing at our pair just kind of keep that up to date um and move it into progress.

B

um Somebody who's working it you're working it do the do the stuff. This is the meat of the sandwich.

B

um If it needs to stop, then, ideally, I make sure that that a branch is up to date, try and serialize the context. You have and say I'm no longer working on this by pulling it um out of progress, because one thing that's not clear here is like: does it go back into the prioritized backlog? I guess, if it's the you would, you would need to know or something I don't know.

B

Would you um sorry if you're working on a story, if your maintainer, you know that if you're putting down a story that you would put it back into the prioritized backlog pipeline, but if you're contributing um and you got started on something it got hairier than you expected or life happens, and you need to step back from it.

B

It might be something that sits in the in progress zenhub lane, um but no longer has an in-progress label or something I don't.

B

B

Okay and then, um from time to time, the community pair can also come over to this lane and look to see whether or not work is stalled.

B

So this might be another situation where we've already got like sure I was saying: we've got um stalin automatic stealing happening for community triage uh carville. Triage may be also great to have a scaling for issues that are in progress where there's no activity.

B

So that could be identified. We could drop a carnival triage label on that.

C

Cool- and I don't think there was too much to find past this.

B

All right, and then the rest of this is describing like in more detail like each of these uh links here. Jumps down into a workflow definition is a bad example. um Some of these are better baked than others, but like what does it mean to recommend a feature? So the the verbiage is uh in in this section um that that's in this process step description.

B

So this is a great spot to kind of talk a little bit more, give a little more color about what we mean, because these things up here are so terse at the top intentionally to like help make it clear, like what's the actual workflow from state to state. What are the.

B

Transitions thoughts, comments, things you see, there'll be good. Next steps gaps, things you're liking,.

E

Things you want different, so, for example like that in progress, are we trying to mimic the.

E

The experience of zen hub using labels, because so okay, because like in the end, if so like we, we could be catering for people that don't want to. You, don't want to use zen hubs too. So they have like a way to see what things like. How things are happening? Is that something that that we're proposing here or or.

B

That's a good, that's a great question and that's it. You know that goes to like how accessible visible, legible our backlog is. So if we say we have to install a plug-in in order to see it, that's just that. I you know whether or not that is a barrier depends on the individual.

E

So, if that's, what we're trying to aim for? Wouldn't it make sense for us to add labels for the prioritized backlog as well.

B

um To like mark it as like slated for or just call, it prioritized, yeah.

E

I'm just asking like if that's.

B

E

If that's the idea that we're trying.

F

E

Achieve here, then, it would make sense if not, if, if we're not trying to do that, I feel like that adding a tag adding a label saying that is in progress, it's kinda. Do you really need it.

E

What do people.

D

D

I think, like that's, where I sort of struggle with this. The most is like this need for people to take the information and labels and also combine it with the information in zenhub. Instead of being able to just look at one thing and start from there, the in-progress one, I think to me, is kind of unique like if I come into our issues as somebody looking to contribute, and I want to find something contributable should I care that it is oh. I think this is the question to answer.

D

Should I care if it is in unprioritized, prioritized or accepted lanes, um because I do care if it's in progress like that's something that I don't think is questionable like if I'm looking for something to contribute, and it's already in progress, that's not something I should contribute.

D

But to me the question lies and should I care what lane it's in as well, and if the answer there is no, then I think the in-progress label is still useful. Even if we don't add these other three.

B

Yeah, I think I think, perhaps generally yeah, that okay, this is a great point, and I think this gets to joao's question generally, which is do we want? Are we trying to provide two views over the backlog, one through zenhub and one through labels, because they're they're, like you, wouldn't need a whole bunch of labels? If you just put stuff in tenhub.

A

So um backing up to the reason why we started using xenhub uh when I came on board, the team was using tracker. So there wasn't a lot of visibility publicly on how the team was working um on what was being prioritized and whatnot. So then, zinhub came about uh in order to alleviate that and talk to talk back to github so that um people could see it publicly being worked on.

A

um So if there's a way for.

A

Labels, that might be in zenhub like say, there's a label that says in progress or prior towards backlog and it, and it just talks back to to the github issues so that someone doesn't even have to install the plugin.

A

They can just see the label there that it's it's in progress or um all the other labels that you have laid out versus the need to go to zenhub. Does that am I making sense.

B

Yeah, so I mean I I'm messing with it. I haven't used this a lot but like there is a way to actually say things that don't have a label, for example, so there'd be a way to be able to describe at least the pile of issues that satisfy a cata category of like it's ready for dev and it's not in progress.

B

So if so, that's sort of leaning toward the direction of well yeah it'd be great. If we provided a means for making, I don't know, say necessarily the the the issue is legible without having to use zenhub.

B

If you just went with labels, and if you did that, if we're saying yeah, we want to do that, then we would do it, for example, which I was talking about. I think like continue on with like adding these label things to make to like make sure clear that, like oh, this is prioritized already. You wouldn't want to pick up a prioritized uh issue um because now you're in a race with the maintainers, like you know, and so then there's two views over our repos.

B

One view is just with labels and the other view is in zenhub.

B

And we do the work to make them congruent so that whatever sitting in unprioritized backlog, unlike today, everything in here would be ready for dev, and so all these things will move these back into carville accepted and then check that they have ready for dev and move them back into that prioritized backlog.

E

I I'm not a huge fan of that, because that will include that will add a lot of work that will need to happen just to move uh move issues around so like you'd have to go to zen hub. You need to move it to a particular place. You need to be sure to add particular tags, remove particular tags if you are in a specific backlog or something it feels like that. It's quite cumbersome just to maintain everything.

F

E

Right and yeah, I don't know.

B

So like, if, if, if all of that was automatic, like moving an item into a particular swim lane, we could say: oh anything, leaving new issues must have been carver triaged, so we'll remove that label and when it lands in certain um sorry, they're called pipelines when it lands in a certain pipeline. It attaches certain labels and so there's a whole bunch of that, like state type labels that just that get automatically managed and there might be additional things like um ready for dev. Maybe you need to do that.

B

That's more of a manual check, perhaps.

B

Yeah because I'm with you like that, sounds like a lot of work and it's just a recipe for now things being less honest or less clear and less trustworthy as an organizing system. If, if things are accurate, if you look at it zinhum but they're inaccurate, if you're just trying to use the labels.

C

So this is sort of one question I have like is that possible.

E

I saw there uh like some sort of like automation from zen hub, but it is the automation that I saw was related to workflows and workflows are not. It is to like. If you have two workspaces you can coordinate between the two uh like if you move, for example, to carvel accepted swim lane or to the to the pipeline. If you move something there you can, it will move in the other related workspaces to a different place.

E

So in the end, I think that was the automation that I could see from zenhub and unfortunately, zenhow doesn't use labels or anything to to tell where things are, because if it did, we could use something like pro to manage the labels on on the github side or.

B

E

B

Yeah some other stuff around.

B

Okay, well I'm looking at the clock. We we are at time here, but I appreciate like having the space be able to get together and talk about this kind of stuff. um There's a number of things we can follow up on here and make improvements on this process. No matter what um yeah and keep in mind like you're, saying schwa, um there's there's a practical limit to the the work the transactional cost of moving work around. So we need to figure out a way of trying to meet those needs.

C

Cool. Thank you.

A

Great all right thanks everyone that was um some really good discussion and, if you're watching this from home- and you know you have some ideas- that would be helpful for the team or if you want to contribute any of the experience that you've had with triaging issues. Please feel free to join us at our next meeting. We have a community meeting next on june 7th we meet every monday, but we're not meeting next monday due to a holiday.

A

We also have our office hours every second and for thursday of the month and both of those meetings at 11 30 am pacific time, 2 30 p.m, eastern time.

A

Otherwise, um please join us in the kubernetes black workspace in the carpal channel, and you know bring up your ideas there. We would love to hear from you and we welcome any and all feedback regarding anything and if you have need any help from the carnival team. You know we're also eager to do that as well and with that um enjoy the rest of your day and have a great weekend.

B