GitLab Plan Stage, 2 Aug 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Plan retrospective on recent slipped issues

Description

https://docs.google.com/document/d/1-bqakAlRW_7zIWSLlv_EhtkkHx_fwo2i-4foblHksdM/edit

Epic tree view: https://gitlab.com/gitlab-org/gitlab-ee/issues/9367

Manual backlog grooming: https://gitlab.com/gitlab-org/gitlab-ce/issues/62178

A

Right recording again so yeah I, put together a doc for this I didn't really flesh it out much, but I just wanted to talk about two specific issues that we had lately, because what happened with those is that they missed more than one release.

A

So you know we emphasize velocity over predictability, we're normally okay with something missing a release, but if something misses are released twice that says that we missed, we presumably like you know, did some form of like our es tomato checking back in on, like you know what we thought the scope was, and then that went wrong again. So you know the point of this isn't to assign blame like and the reason I kept. The number of attendees small was just because I think we can have a more focused conversation that way.

A

I will record it and I'll post it somewhere in the probably in the plan, retrospective issue and stuff, as well. Just to talk about that. So the two issues are the dragging and dropping issues in the epic tree and the manual backlog, grooming and prioritization. So I don't know if anybody has one that they wanted to talk about first and so. Gabe, obviously like you, you've joined recently, like you weren't here for like when these issues were started. So.

A

Do either of these like jump out at you.

B

Yeah I spent some time actually looking through these yesterday and I. Think there's a couple things that I found like interesting and I guess this would just be like you know, looking at the the weights on them is my first thing that I looked at of you know: I think the dragging dropping is three which I guess: I'm still figuring our wait tables and how we do that. But that's you know fairly straightforward, pretty straightforward.

B

You know to implement there's, not a ton of gaps, you know and the requirements but and reading through some of the issues and the complexities of like having epics and sub epics jump from one another like that's, became a really complex thing, so I just I think it's interesting that we did that didn't come up until like it was too late or like right. When we got to it I guess but I, don't I, don't know the whole history and time lend of like where things actually got stopped up, which is so yeah.

A

Yeah, actually it's interesting that you mentioned that three wait because I just looked at that and I was like I'm, pretty sure I added that so I did at that, and then I did add a comment. I'm said like I, genuinely, don't know how to wait this issue because I don't know what backends require it from the front end to scope. It so I think we just sort of missed following up and updating the way there, but yeah I. Think that's a good point. Yeah.

B

I think generally, when that happens, and that's it's a good thing to call out and I think we should do that. I just I generally not proceeded like with implementation until there's a researchers bike or something to answer that question, you know just to remove the ambiguity from it. I guess yeah.

A

So we do have a bit of discussion about that.

A

C

Is there a UX ready label on this issue? I, don't see it, no wonder why I'm looking at the rate issue.

C

Nine three six, seven right, yes, yeah.

A

So yeah this is the drag and drop that pick tree. I think that's probably the more interesting one to talk about first and they it's still ongoing as well so it'll be fresher in our mind. Doesn't.

D

Have UX ready because it was originally part of it. The issue was to sort of implement all of it at once, and then we split out, drag and drop and I. Just someone or myself I probably forgot to add that label gotcha yeah.

C

D

The original issue- yes.

A

I wonder if that should be a workflow label. I know someone made a comment about like changing the existing with it. You Cape, who made a comment, or somebody create an issue about changing the workflow labels to like fed of it, because we have the the products workflow labels and we have the engineering workflow labels, and should they all just be one set yeah.

B

I did bring that up and I think that's something that that guy is somebody new coming into the process. That exists is really confusing for me just because they can everything needs proper, UX treatment and proper validation. Everything needs proper engineering and it cut an easy go through a certain stages and there's like an overlap of UX identity, ring to a certain degree and part of that, but yeah like having all these different labels is confusing.

B

There's not a given workflow that everybody follows which makes it easy for things to break right so like before an issue can go from UX ready to end EV. It needs wait provided by the people that are gonna, implement, usually or something and that's why I, like it yeah I, think improving the workflow would be a huge first step.

C

B

C

Break up the other ticket into this ticket, was it 1200 or 12:1. So you you.

A

Mean that we we had the epic tree issue, and then we had this one is that right, yeah.

D

We also had the road map. Tab was a part of the entire design, and then we split that and then we added the tree under the feature flag, and now we have the dragon drop. So at least three issues I think it click on the ad break. You should be able to.

A

Yeah I think I mean link to the epic.

A

So, like I think I'm gonna, try and validate this now, but I. Think part of the initial slippage was that the dependent, the blocking issue didn't ship in the release. We thought it would but I don't remember if that's right, selecting the actual tree view itself.

A

Does anybody remember that sound right or am I just making that up that.

B

Sounds right, I think that's I, remember, reading that yeah.

A

So so, like you know, this comes after the tree. The tree view is read only this comes after the tree view, bring it I, guess piracy with what we have now, except it's more than piracy, because you can change the nesting of things at the same time as by dragging and dropping them through the tree, but until we have the read-only tree view, we can't do this because there's nothing to drag and drop within so yeah. So that's one reason, so this was originally in.

A

So I made a comment in the 29th of May, which means we would have started working on it in May, June June, then July and we're still working on it in August. So this is 12. So that's 12 once that's closed zero, so yeah it's been. It's been at least three issues and late.

A

You know the other day charlie, like out of the comment which was very valuable but, like also machines, like you know, a huge risk to shipping it or like a change of scope like later on so yeah I mean Donald from your perspective, from like the front-end side like. Is there anything that sort of comes out to you as, like? You know something we can improve here.

C

Yeah I mean I mean the first thing and we've already mentioned it, but it's just really a ting that that wait just to start off with we yeah we uh not so much. Maybe the wait was fine in the beginning, but we didn't go in and change that which we should of us. I was amiss there.

C

This one because there was also I, think some confusion over.

C

Should this be part of the the read-only. So the read-only is what was behind a feature flag and that we turned on and then it's back off again right yeah, we got a bunch of.

A

Feedback we're addressing it, but this is this is a blocker to us like making the treeview available again right, yeah.

C

A

C

Yeah so I think there was also some confusion as far as so when we turned on the when we turned on the read-only and we got feedback I don't know if, on the front end, we knew if we should be addressing the feedback first or if we should be doing and I know Kershaw had listed. Oh maybe I was on the other issue, the other related issue, but just kind of a list of priorities that he should take on. I think this. This issue was linked to that. Let me see if I can find it.

C

D

Feedback, sorry going no.

C

D

Feedback we're looking a new issue for that. It should be in the epic I hope, where I proposed a new layout that addressed the major points that we received, like the hit entry and the word tree being confusing and another thing. So hopefully, those on the front end should be really small fixes. It's just rearranging things: I linked I posted a new proposal before I went on vacation, but I'm not actually sure. If it's all out no.

C

D

I haven't checked on it. Actually, so I should go back and see, but um hopefully that should be small, but the current implementation or the current blocker is that front-end related or is it? Is it more back-end I.

C

Don't think there's a blocker anymore. Is it.

A

Can become an issue that Charlie's raised is a back-end issue, but that might increase the front-end so like.

D

A

A trade off right because, like at the moment we're saying we can interleave issues and epics, which is complicated on the backend, because everything we use for ordering is ordering items of the same type, and here we're not and I think there was some discussion earlier where Charlie and Brett discussed there and figured out a solution, but then that didn't account for another problem. It's always that the ordering works which we didn't know about until we got further down that line.

A

So my suggestion there was, can we cut the scope- and you know from this iteration not allow that interleaving so always have ethics at the top, then issues below if they're at the same level. So you can reorder issues within the issues, lists and epics within the epics list, but you can't put an epoch in between two issues or vice-versa, but the problem is that might increase the scope on the front ends. So it's not and I can say it's an obvious win from the back end.

A

I can't say it's an obvious win overall, as is the problem there. So that's the current question that.

D

Also adds a little bit of UX to because it's gonna be weird. If you just can't drop something, it's gonna be a little concise. They're gonna want to know why you know I'm wondering too, if you expand an epoch and there are sub epics and issues in there. It's it's gonna, be all so weird that you can't reorder that sub. Like I, don't know you we're going to put like a big X or something over the part where you can't drag when you try and drop it, not an X. That's that's horrible!

D

They come about to figure out some kind of interaction there I'm wondering if, in the future we could have, we should have maybe discussed this, or would there have been a way to find out that this was a blocker beforehand like when it was suggested.

A

D

A

So the thing is I actually like when I wrote. My comment yesterday, I looked through the description and the comments and I didn't see this list.

A

It doesn't explicit like this is a new thing, we're allowing you to do it, we're just kind of like an assumption which is valid or something like it's in the designs and stuff, but like what I mean is because they're in the same list, we assume that you can reorder them with each other, but we didn't actually say: oh, we are suddenly allowing you to reorder them within that with you know, we just didn't sort of like flag that apply as a explicit thing, and it turns out that, like from our back-end perspective, that is quite complicated with the way we do ordering.

A

Now it's not something. We can't do it's just something that does increase the scope of issue and, given that we've been working on this issue for quite a while, we probably should have noticed that sooner as like a major flag, rather than sort of a thing that we'll just try and deal with you know, I think I think from a back-end perspective like I, definitely have had a conversation with Charlie, not on the issue, I, don't think, but somewhere like either on slack or and I wanted one or somewhere else.

A

Where we mentioned this as, like, you know, I think that we were introducing, but we didn't go back to the issue and say like hey we're introducing this. Should we reintroduced in this can with like you know, it will significantly cut scope for the back end. If we, if we don't do this so yeah I, think that's definitely a thing. We can improve as well as like to make sure that happens in the issue where people are actually following and can contribute yeah.

D

Maybe next time on, whereas proposing these designs, like months ago with the original designs, we could have highlighted the huge changes a little bit more or even had it. Kickoff call for big features like this, so that everyone's on the same page and understands how big the changes are, instead of just you know that point being buried in an issue description by the way the ordering is changing drastically yeah.

A

I think even mentioning an issue description is fine as well like I do expect people to like fully read the issue description, if not necessarily the entire comment thread before they start working on something so I think if it's in the description somewhere like it, doesn't need to be like the most prominent thing. I just think it it should be in there.

A

Is it there's a star anyway, yeah.

C

And I'm wondering if some of this will be solved with the new product workflow to like if we would have been able to catch up catch some of these things more earlier, especially I. Don't know if we explicitly call out in the prod new product workflow like when technical feasibility, testing occurs or experimentation occurs, but it would be nice to and Gabe.

C

You could probably talk to that a little bit, but would be nice to have either a slotted, workflow or some dedicated time for us to for engineers to go in there and just test out some of the some of the concepts that we've been talking about.

A

So that I mean the products are doing a book club on them. What's it called inspired.

C

A

Gay yeah, which is big on purchase, typing right.

C

Yeah prototyping and experimenting, and it a.

D

C

Of the workflow I think that Scott wrote up came from a lot of the ideas in that book. I think at least it seems pretty uh pretty closely related to it. Yeah.

B

I think one of the things that I guess like I just noticed too in terms of looking at this specific issue and like process improvements as a whole is like there's another issue about making an epic tree on the road map view. And then we also have the road map tab in this, like in the epic detail view, and then we have.

B

This drag drop interface and it's almost like if we had taken time to go through some more those like interactive, prototyping and iterating, and getting customer feedback and doing some of these like kind of experiments, which is the forward-looking process, has some of that like problem validation, solution, validation and planning phase phases in there, but keep it lightweight. So we don't spend like months doing it, but like weeks, I think it would have helped ease out a lot of these issues ahead of time.

B

But I want us to get towards doing that, because I think we'll eventually place.

C

Would that be in.

B

That would probably be in the solution: validation phase, because what we're talking about right now is like I want to be able to see their.

B

You know the epic relationships within an epic view, but looking back at the solution, we had a similar like situation or problem, but across different areas of the product, and so we designed a hyper focused solution when we could have maybe just like design a more kind of general primitive for how this would work or work well across both like experiences and just thinking through it, but then also doing some of the prototyping to tease it out like that will happen in the future when I do the problem and solution, validation and then getting into the planning stage, which is where there's a lot of cross functional overlap between people talking about how come brings down.

B

How is this going to work? You know asking questions back and forth. So that's my two cents at least.

A

Yeah I think that makes sense and just to be clear like this- is the scope of conversation. I was looking for I'm, not so much like interested in. Like you know. What should we do with this issue? As, like you know, what do we do going forward? I think that's the more I'm the more relevant thing here. So I think these are all great ideas. Anybody else that's got anything they want to talk about on that issue. The treeview one.

B

Just one other thing: antibody I'm, not sure, if you've like heard of the idea of doing like sea-doos, but I've used them with my team to really effectively and it's more or less like sort of like a user flow diagram. But it's really lightweight it's just what user sees and what they do, and you kind of map out the happy and sad past and I think like we've used those at a conversational level, even before you get into interface design, just to talk through like what what is being built.

B

What is the what are the expectations from a user, and that is surface? Usually 95 percent of these weird use cases where oh I didn't think about this particular thing, because you you're more or less like looking at a 2d diagram of like things that the user can do and then what happens after they do those things to take those actions, and maybe we could look towards something super loaf. I like that is like a starting point. Do but I'll leave that up to the the UX designers, yeah.

D

We recently just got access to mural to do these sort of user journey. Mappings and we've been well. I haven't actually had a chance to yet, but we have been doing these sort of these flows where you know this is what the user is expected to do. Here's what can happen if they don't do a certain step in the right direction and that kind of stuff so for for the upcoming issues, that's something we'll the homie be doing.

A

Cool move on to the next issue. Actually, looking at this I'm gonna, just sort of Donald and Annabel feel free to jump in here, but I think that this one is actually more straightforward and therefore we will learn less from it. But it looks to me like what happened here was like we worked in a I think the actual way we worked on this was pretty good like it was pretty decoupled. Like you know, Brett backends Ruggiero front end.

A

They were mostly separate, like you know, they were mostly decoupled from each other and able to work on things independently, which is what we want. We don't want people to be too tightly coupled we got things behind a feature flag, which is great so, like you know, we can turn on if it's ready. There is a comment which I'm going to link to where we say it's.

A

You know it's gonna be closed for 12.1, but I think it's just gonna slip because the front end is not going to be ready, which is fine, so that's the first time it slipped and then the second time it slipped.

A

Is not actually in the issue, but what happened was basically. We ended up like with a lot of wasted time in the process and I'm, not 100% sure why that was but like we verified it on staging, we turned on the feature file stating River fighter there and we realized that actually like this sort doesn't perform except ibly.

A

So you know it was a pretty straightforward fix we needed to add a database index, but by the time we realized that we didn't have much time to do that before 12.1 was finished and you know we weren't able to get it reviewed by a database reviewer in time. There's.

C

A

Item in the overall retrospective about making that easier, so, like you know, hopefully the issues with reviews, there won't happen, but as far as I can tell from most of 12.1, we just weren't working.

C

A

Yeah, if we had found it sooner, we would've been able to work on it sooner.

A

C

A

C

But there wasn't note about the performance, but yeah I'm, going through it right now and I can't I can't see that that's known in there, but there was also a delay on the front end because in 12, oh I believe when we were when we first started working on this one, we were going through a little bit different prioritization of what engineers were working on so I think it was bugs like that features, mm-hmm and remember us having a lot of bugs and tech debt in that issue.

C

So we actually didn't start working on this feature until close to the end on the front end at least I'm close to the end of 12. Oh, so that that's one reason and we've adjusted it a little bit where we do a little bit more front loading of the planning of features to make sure at least there are eyes on these features from the beginning of a release. I'm sorry I think that that's one reason why it why it got a move like that pushed from 1202 twelve one I can't find this performance.

A

Issue I mention it briefly in the second comment: I linked to, but I didn't actually follow up and say, like Oh. This didn't get like you know, merge. So maybe I mentioned it like in the mr or somewhere else like where I ping Derek but like I, can't find it in the issue itself, which I think is a is it as another improvement like not maybe a major improvement. Sorry later in 12.0? That was what you said.

A

It was just gonna, go there yeah and then the second one I think, because maybe because we didn't have the front end like available to text, maybe that was it, but we should have still been able to well I guess there wouldn't be much point hmm I, don't.

D

A

Very very uncertain on my you know what we can learn from that one, except that we ended up wasting not wasting. But, like you know, if we had have tested that sooner, we would have been able to find the performance issue sooner, but also, if we've been able to get the database, we you know we'd have been able to get it in sooner as well. So yeah sorry I picked that one but I think it's less interesting. Gabe I, don't know, she's, disagree better or.

B

No I, don't I, don't have a lot I think. That's all I mean to me. Yeah.

A

C

Thing to learn from that is just if we can limit and we've already been kind of talking about it. But if we can limit our team wide work-in-progress issues or features I don't know, maybe that would that.

A

Would help with that yeah Gabe? You mentioned this the other day, I think didn't you mmm-hmm yeah.

B

It's it's it will. It will be like I've gone through this with several team before and we we've implemented something like this. It breaks everything briefly because everybody's, like I'm super I, can't work on this and blocked. You know, which is, is the right thing to have happen because we're enforcing a constraint on a system to like isolate where the weak link in the process is so we can go fix it and then there's gonna be another weak link somewhere and another weak link somewhere.

B

But then, eventually, when you go through the process of fixing each of those things, you end up being able to go a lot faster in the long run. And then you end up increasing your throughput dramatically Oh for, like the course of time doing these, like micro, retrospectives, there's a whole idea to of like stopping the line, which is what Toyota introduced were like anybody in the and the plant can Cole on a chain. Stop the entire assembly line.

B

If there's quality problems, which is another cool concept and I, think they do that, like 3,000 times a day now still, which is crazy but there's a lot of things, I think to learn from that, and that we can experiment with.

A

Cool Annabelle I, don't I, don't think there was actually any you exchanged to this issue any poisons, but is there anything like you wanted to add about this? One.

D

Nope I, don't think so. It looks like I missed. A response about Erik was saying I'm trying to comment.

D

Erik was a little apprehensive about users, updating the order without realizing that they're going to change the order throughout get lab.

A

Sorry gone, no, no, no go on so. Shane mentioned this in another issue, which I'm really having a hard time, remembering which issue was maybe Gabe or remember so Shane mentioned something about how get lab doesn't actually use the term backlog anywhere or like grooming. It doesn't use agile terminology within itself and, like we have a blog post describing this, but we don't have like you, use a story. Documentation like in our Docs about how to use get life. Agile, like you know how this could be like there could be a bite backlog.

A

This would be like a separate view at some point where, like this could be like you know, your backlog grooming view like in JIRA, where you have your yeah I think it might just be called the grooming view. It's been so long since I used here for this stuff. I can't remember, but you know where you order stuff I, don't know if you've used it more recently Gabe. It's.

B

Been a while too, but yeah I think well, there's there's a lot of things that I want to explore, especially our scale and how many issues we have that make it really difficult to to interact with in a meaningful way.

B

So yeah I think there's a lot that we can do there and I it's just hard to to look at like what is the most common primitive. We can do that is applicable to the most amount of people, but there is like a pretty big divide between people who do scrum, which is the backlog approach and the people who do Kanban, which is like the board type approach and I, think we need to continue to improve and look at how we can like satisfy those two groups. Yeah.

A

That's a bit of a tangent but I do think it's interesting as well.

A

Yeah I think I'm I'm gonna, try and find that comment and I'll send it to you on slack or something Annabelle where Shane mentioned. Oh, it's in the board list capacity line issue there you go. So if you look at that, one which I think Alexis has been mostly working on I think you mentioned about like how we don't have agile concepts like native India lab, and this could be a good candidate for one of those. It's.

B

Even on our eye, there is another issue up in yesterday that it's on our marketing site that we have backlog is feature but there's like nothing. There.

A

Is the feature like for back like? Is it a list of issues like yeah.

B

Let me see if I can find it.

A

B

I found it it's on the feature, comparison thing, I think there's a backlog, management.

B

So it's listed there and then it's also a self managed thing, but product marketing or I think somewhere sales like they have no idea what it does.

A

Right yeah I mean like as someone who works on this area, I'd be hard-pressed to say like what the feature itself backlog is so more micromanagement like necessarily like, because we have a lot of primitives that you can do that with. But I don't know if we have one feature that I would say is that clock management necessarily well.

D

Especially if it's only available on silver and gold, when was this added? What is it the issues list, as it has you know, has been existent as existed since it was created.

A

In all editions, so yeah, that's a good point.

A

So we're over time, I've got time after, but I don't want to, like you know, go go too long. I assume everyone else has got time after because nobody's left I, don't actually think, there's anything that we need to do from this. That isn't already encapsulated in you know stuff we are already talking about or stuff has already engaged, merge requests that he's created about the so Gabe's created a merge request, Annabelle for so like. We have sorry that sentence at about three start, so we're just gonna start again.

A

We have like the back end plan team page and we have the front end plan team page and those describe how you work in those teams, but we don't have like a group y plan, page anywhere, so Gabe's, adding a page for that that describes sort of like stuff. That applies to the group and obviously, when we split into three stages, which will be soon team planning, portfolio management and certify.

A

Most of these things will be common, but we might vary them a bit so Gabe's doing that and putting together that, mr, you know: mapping it to the new product development flow that Scott created all that stuff, so I think a lot of these things, sort of fit with that or with future iterations of that I don't know if anybody feels like there's something we should take out of this beyond that. Maybe we should make a note about rewriting issues whenever they slip.

A

Anyway, well, I think we should I think we should re way up. I, don't I, don't really like re-weighting down like if an issue, that's three slips slightly and it turns into a one I. Don't really care about that I'm! More care about like this issue that we thought was a three has turned into a five and we need to reevaluate it.

B

A

B

Thing that I think is is like could be a process. Improvement is that you know you regularly go through and and like estimate something you know early to kind of rough size it and then the person who picks it up might have a different take on it and so I've. Also in the past, the teams that I've worked on we'll go through and we'll do that kind of rough estimating and then whoever is about to start.

B

It will look through it and then update the weight, because there are the ones who are going to be doing the work and they might have a slightly different interpretation experience that background tool set. Then you know the person who originally gave the weight, so that could just be one thing as like, as as you pick a new issue up to implement it just update the weight and make sure, like you agree with it. That's.

A

Interesting so for me like in previously I've said, I. Don't care about that, because I know that, like somebody, who's worked on this specific area before might find this or and someone else might find it three say but like I, don't I don't care about that. So much because I do want people to be able to take issues that are harder for them than they would be for other people, because otherwise you just have the same people working on like certain areas, but that doesn't mean I. Don't think we should do it.

A

That's just giving the historical, but you know what I've done in the past. With this question, yeah.

B

I, don't think we should. We should ever assign I, don't like the idea of assigning work to any person. I like you know, first-in first-out pull off the top, but it's just also like a good. It's been a good sanity check, especially if something's been sitting for a while and situation has changed to get like a I mean just an updated estimate, but we don't have to just. We found that it's worked well in the past so and I did.

C

Yeah I think, though, I like that, because it explicitly puts in kind of a check before we actually work on it to update weights. So even if we don't have it be the engineer that or the person that takes it on reweighed sit, we should explicitly call out that hey before we actually commit to something in a release or while we're evaluating.

C

What's in a release, we go through and check the weight for everything in there, because I've had situations where things have been like a weight had just been thrown on a year before we start working on it and then I don't even look at it because I see oh there's a weight in there.

C

I already assume that it's right and then we just go off of that weight as we as we build it, which is not good but I, think if we can figure out a way to explicitly ensure that we are always checking a weight before we get it into it before it really starts. However, we decide to do that. We should definitely do something.

A

So for me, when you pick up implementation like again I'm not saying we shouldn't, do that, I, just care less about the weight and more about the understanding of the scope in general. So, like someone picking this up might say: oh hey, you know, I see this was wasted too, but like do. We also need to consider this. Like? Is this part of the scope? Or is this not like me at me? Oh, maybe that's not clear.

A

Like you know, this is this is a three but, like you know, we're adding this thing, which in itself might be a three or bigger, no, even ignoring the other part of this so yeah. For me, the the conversation is more valuable, but obviously the conversation is qualitative and you can't measure it. So that's the problem with that Anabella see you added a couple of things to the doc. Do you want to speak about any of those I.

D

Was just responding, some of the things I forgot to write down I was also going to mention Gabe. You mentioned roadmaps at some point and I just commented, I was trying to find my comment. One of the issues for 12.3 was going to be seeing child epics or child issues on the road map view, and we've got dozens of open road map issues, and we probably you me and maybe Alexis oh yeah I- definitely like this should probably just go through it.

D

Maybe we'll need a meeting and go through the ones that we actually want to continue doing and figure out what we want road maps to be in in the future, because there are so many little things that we have open, that are I, think already scheduled and they might not all play well with each other. We might not need them all.

D

Customers might not even want some of them, but we want to make sure that the road maps and the epics page are coherent and related in some way and right now, they're, not really so that issue that's planned for 12.3 I'm, not sure it's going to be UX only and I think that UX is going to be figuring out what what the next step is with road maps in general, rather than just implementing this feature. Yeah.

B

I think that's smart, I've, gotten I've been on a couple customer calls, and this weekend heard some read some emails from customers and there's a lot there. That I think is worth unpacking just so we have a go here, vision that we can communicate externally about what we're going so I fully support that.

A

Cool so I think that the kickoff Sanibel, in fact, I think for basically everything we've talked about here like I'm, okay, with trying this but I, don't think we necessarily need to make a handbook change in order to do it like we can just say like okay, like you know, if we want to suggest to people, they consider re-weighting issues when they pick them up. We can sort of do that like because we have to do it everywhere to like get value from it.

A

If we want to do kickoffs or some issues, we can do that, but I'll leave it up to the people who are working on that issue like Annabelle. If you were Alexis, feel like kicking off valuable and don't feel like a kick off would be valuable on an issue. Then please push for that ball, so I'll. Let the back-end team know that they can suggest that as well. Yeah.

D

I, don't think it's necessary. It's just that I've worked with something like almost always has a call with me before we started on an issue and I loved it. He has all these questions and we answer them and then he'll show me its progress throughout the they're out the way and then I just think it can be pretty valuable. Cuz I can spot things quickly and we used to do this on the plan team meetings too.

D

If Alexis and I it's been a while, but if we continue to present our designs- and you know, we've got a good mix of back and in front of developers on the call too, it's a it's a good time to spot. You know technical things that might come up or UX issues that might come up, then we're people that see it. You know the better yeah.

A

The other thing is we have this slightly related. We have this convention of like channels that begin with F on the school, which are four specific features, and they don't feel like we've created many of those lately like we've used existing ones. We haven't created those, but maybe we should feel like things like epic, trees and stuff, where we know it's going to spam.

A

I think if we're working on anything, that's an epic, we should probably consider creating a channel to match that right, because we know it's going to span a few releases and we might might want to have a place where we can discuss from that separate from the main plan channel, which has like 100 people in it, I think 127, yeah, so gets gets quite noisy, but again, I. Don't think we need to like necessarily make a documentation change. It's just a thing we can think about in general, so yeah I, guess I'll.

A

Just add these to the next plan weekly meeting. It's like things that we can consider doing like kickoff calls wasting issues feature channels. Was there something else I feel like I'm missing something else? Well, if I am at its that I'm related meetings, agenda and I'll put it on we'll talk about it on Wednesday but yeah anything anything else for anybody.

B

Thank you for a facilitating yeah.

A

Thank you no problem right well for all of you, folks, it's I guess almost Friday afternoon, but for me it's later a Friday afternoon. So this is my last call of the week. So have a good weekend and I'll speak to you all next week.

B