GitLab Progressive Delivery, 1 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: ENG/UX Progressive Delivery Meeting 2020-09-01

Description

Meeting to improve alignment between Engineering and UX for progressive Delivery

A

All right cheers uh thanks for joining the ux engineering meeting, where we try to fetch and catch all the gaps in process, but also help each other out with blockers and those kind of things. So in that sense, um are there any direct blockers where I am blocking engineering with a certain issue? If so, this is the right moment to bring it up, otherwise, I'll get to them later.

A

Are there any? If not, then we're gonna go through the next point, all right, three, two one all right on to the next point, um so I was looking at this merch quest from you, andrew, and um your comment was super valid. So I thought like hey, let's bring it up here um in the mr, which was partly reviewed by ayanna, and this kind of thing right like in in the issue.

A

We set up the acceptance criteria of a of an issue and then, of course, the merch quest review process only makes sense if we actually check the acceptance criteria like do we actually do the thing we set out to do right, and that is of course based on the quality of those acceptance criteria.

A

Those skins, I think, there's always a point of improvement, but um the comments you create, let me see, did I uh that was the other link here and I'll share my screen. So there's some few, some visuals here um here you can see like hey uh the one alert uh seems to be missing. This was also missing from initial mockup super. True, um I was I answered to this. Like hey, the mock-ups did not represent every outcome of the design's concept. That is not like you know. I don't want to do the work.

A

I do want to do the work, but sometimes it doesn't make sense or it is quicker to be done. In writing. I was having a discussion with hayanna about this, because I met up with her uh friday in real life at rotterdam, and I was discussing how she does certain things and she says, like I, don't create any visuals if I don't have to like like any like they just they just have to read, and I was like all right that works, um but, on the other hand like sometimes visuals, are needed, etc.

A

But I think the main point I got out of that is like all right. um She does that to decrease wasteful energy spent on creating mockups, but.

B

A

Other hand it highlights the importance of the text of the concept right like if I wouldn't have put the image there, then there wasn't an image to look at and then the only thing highlighted there was the text. um So my basic question would be like hey. How would you like to see developer handoff be done like do you like the visuals, or is it only exceptionally necessary when something is unclear and otherwise keep your text or like?

A

How could I've done better or how can we help each other better out in these kind of situations.

C

I am personally a big fan of mockups, I think they're, a good way of catching um as we've seen this uh thread kind of spiral out and they're a good way of catching things that end up being a little weird earlier in the process than then later on.

A

uh How would I summarize that good way of catching.

A

Was it was a good word? Give me a good word.

D

Like inconsistencies or something.

A

Inconsistencies.

C

Yeah, that's a good one.

A

And strange behavior yeah yeah. It's really that and to be honest, like I like mockups as well like it, I think it you know, translates certain things so much better.

A

My main point, though, is- and that is mostly for the design person I don't want to create, like you know, like 10 iteration markups, with small visual changes, so what I've done in the like the last, I know so many issues. I've worked on if there's only a small change towards the design. For example, I've been in talks with marcel on technical writing, and you know like hey.

A

This copy needs to be changed in this slightly different sentence structure like yes, I'm not going to create a new visual for that, because that is just wasted energy right, but I do want to make it clear like for those cases that, like the mock-up will not always represent the latest and the greatest like it, it will be indicative um if so, like I don't know if you've already seen like. I sometimes like put a note like no this. This mock-up is indicative.

A

Please use the copy described above her below, but I wonder if that was as clear as it could have been.

C

Yeah I mean, I think, a part of it was just my my rush to get something up before vacation as well like.

C

um But I I do find I tend to look at the the images first and then and then the description later on.

A

Time that I look all right, so here's a a quick, quick idea. What, if I put my images in like the collapsible sections, you have to open the images sure all right, I'm a guy just like an idea, I'm gonna, I'm gonna experiment with that.

C

It might also just be like a transition thing you know like mike was very uh mock-up first mock-up forward, I I'd say so it could. It could also just be like a.

C

A part of a transition.

D

And if they, you know, you talked before about like the uh some ways they're like do. They need to be high fidelity mock-ups. I wonder if you can get away with something else, that's um less time-consuming right and maybe it's.

A

Yeah, I I I see exactly what you mean um and it is, it is um I'll I'll tell you from my site, yes low, fi prototypes or mock-ups. However, you want to call them should be easier to create.

A

On the other hand, we have this amazing design system that has full fidelity, easy things to play around and throw in your screen, um and unless you go outside of that, like it's quite easy to to create them. But it's more like uh it's more like the.

A

If we have this screen that you click that, then what happens, then click click click and before you know, you have to like design four or five different views, and that is the thing which is time consuming, which is, I would say about the same just because we have the design system to kind of design a lot of things like here's.

A

This thing you can just copy and paste, um because otherwise it would just be lines and wireframes, which is fine, but I don't like the wireframe balsamic like I'm, not that fast and, like I'm, faster.

B

A

My sketch than I'm in balsamic yeah and I'm not a big sketcher on paper, because then I need to take a picture of it and I cannot write my read my handwriting and I see some designers do that and I just like. I don't know how you do that like I can try it out, but I I can assure you it's not gonna be a success, or at least I think so, but yeah.

A

um I think the collapsible section is a good thing and just like the general call out of that, the visuals do not always describe the full. The full image um I'll try to remind uh if need be,.

A

um Then, on to the next thing, unless there's another comment.

C

Oh, I just, I think I think in this particular case, because the copy is so uh dynamic there could have been like it makes more sense. In my mind, this isn't just a sentence. Change like if we look at what the copy is, it's, it's literally all dynamically generated, except for a couple separators.

C

A

I think yeah exactly.

C

In this particular instance, due to its dynamic nature, just like having having the full thing, there could have maybe saved us this um now ongoing ux iteration that we're we've got going on in the middle of this m.r.

A

Yeah yeah, that's it's certainly something I would like to avoid.

A

um Yeah all right learning point I think we're pretty clear in this uh always good to have the uh perspective from the other side then on to the next. Let me see so step one of bros, so I want to thank chase and everyone involved, um but mostly chase on, like creating this ad mention handle.

A

We now have at our disposal- let's not use the spam, but I think it's super nice that if you are gonna close an issue uh please use the mention handle, so you don't have to mention, like you know like who am I going to mention, just use this mansion handle and it is now defined in the handbook as well. So that's nice, so we can see here in the verification process like hey.

A

If all cycles are to be informed, just use this pension handle, if you do add, progressive delivery, will immediately pop up click in hey. This thing has been merged. It's looking good as far as I'm concerned, and then I would say like if we go off this this this copy here, uh the owner of the epic, mostly the pm, will ensure the issue fits the context of solution.

A

Blah blah, so I think they are about to close right. Is that correct? Do I assume that correct that the product manager should close the issue.

D

No, I mean I typically issue closing happens. Well, it seems to happen right um by the engineer. I I would think right if all things have gone up to verification stuff's on in the right place right. Is that not the case or are we suggesting that we need to like follow back through with with some with with the pm.

A

Yeah, so the thing is today later on is the progressive delivery weekly, because I was originally intending to bring this up in the weekly meeting, but uh I think orit and I are both not joining because it's outside of our time zone right um but yeah. I would love to have a less check on that by ored and kind of lying on, like hey from a product perspective, I would like product to close the issue, because if that is the case, then we can also do a functional, verify and mostly concerned with.

A

Like hey: did we have any follow-ups? Do we need to create any new follow-ups? If so, let's do that? Let's mention it in the issue and then actually close the issue. Then it's really close because then we know what the follow-up actions are. Those kind of things I think currently, that process is a little bit muddy, like the engineer closes it, but you know the exact requirements or timing when it's not super clear, at least that's how I view it. I was wondering what your thoughts are.

C

There I wouldn't mind not closing it doesn't.

D

Like it, doesn't you don't get a sense of closure.

C

No, I don't have, uh I don't, have a stake in uh being the one typing, slash clothes.

A

uh Discuss in next yeah I'll discuss in the next weekly meeting and then uh get uh or it's or it's eye on it for the last time, and then let's create the handbook update.

C

I do think we should put maybe an emphasis on closing the issue and opening follow-ups, though perhaps if that's the case.

A

Yeah yeah, uh I am mostly concerned with follow-ups.

C

A

Emphasis on it.

C

Yeah, I am a little concerned that, if we're not the ones closing the issue, the these things may linger with more follow-ups or something right.

A

What do you mean like they will linger with follow-ups.

C

Yeah so like, instead of creating a follow-up issue and closing the original one and scheduling the follow-up, the the verification finds some reason or other that blocks the closing of the issue and.

A

Because, like just for my information, if the issue is not closed, why would you care just like wondering.

C

uh Because I I think I think, if we work, I think if we, if we try to get the follow-ups in in the original issue, instead of trying to schedule them through the process, it's it's a less iterative or it's it's.

A

Less visibly iterative.

C

A

So yeah, so I think, um like my intention here, is fully on the issue- is to be closed after follow-up issues are created, not including anything into the current scope. That is, that is like the wrong way to go like. I would not not advise. That would be horrible.

C

I think I think it's worth calling out, though,.

A

The creating out follow issues not including scope into the current issue.

A

A

Yeah totally agree um I'll put this up in the uh the agenda cool thanks for the input here uh next step.

A

So this is the important part where I wanted to get to um so I was discussing with nadia on the merge process, so this is like the the thing we just discussed is just the first step and things that I saw like hey, we're we're missing out here or we're not following the process as we have defined, or you know those kind of things and one of more of those things is where I've brought up in the past.

A

It's like hey, um I'm not sure about this merch quest like I'm not included or I'm not aware or somebody else is not aware or there's inconsistency on, like the process that's being followed- and I was discussing this with with with uh with the nadia- and she says, like the best stage, troops that she sees the example of do not enforce approvals, which I'm a big proponent of. I think that's amazing.

A

On the other hand, they do have a habit of over communication and including all stakeholders as necessary, and this is, I think, where we can do better, like, for example, me making it aware that hey, I saw this merch quest being merged. I didn't even know what it was, or I saw things being merged with your exchanges or whatever, and I was not aware that this was a thing like it's not about me approving the merch quest.

A

That is the problem, not at all it's more about like me, not knowing that this thing even existed and is now changing the process for our end users. I think that is the thing that we need to to solve, and um I think that is not only for me, but also for it. That is for technical writing, which I, by the way, I see often included, which is amazing, um but those kind of things.

A

So my question here would be: how do you normally see the life cycle of a merch quest, and where do you include which people.

A

A

Jason, what about you.

D

B

um I guess if you're talking about ux, I actually almost never seem to do anything that affects ux. So um if I do, then I would usually just ping ux whenever I like, as soon as that. Mr goes up.

A

Uh-Huh and then in terms of like, let's I want to, I want to open up this discussion to beyond ux like, of course, I'm ux, but it doesn't mean that I do not care for anything else or only ux like it's like in general. Like let's say it's a back-end only merge quest, but it has an effect on performance or it. It enables this new thing through the api, which is in a way ux, but that is for for later.

A

um You know like hey, who do you include who like when it? When does orig know this thing it becomes live like those kind of things.

B

um I basically just ping the reviewers I need, and then I'm imagining async updates or how ms or anybody else who's interested would want to know about it.

B

Yeah, that's great color.

A

So async updates, and with that you mean like what like what is an async update.

B

The async updates that we're putting on um issues as we're working on them.

A

Updates yeah, that makes sense. uh I love those async updates. The main. The main thing I have. um What I would like to see for those async updates is a notification like I don't know about you, but I work with to-do's personally and I seen multiple other people do that.

A

I don't know if that's within professor delivery, but I do not see when an issue is updated unless I'm not mentioned um so when I see an async update, sometimes like oh, this was from four days ago, or this was last week and I, like I, don't know what the current status is like. I think the key and the feedback I got from nadia was like there should be some kind of form of continuously updating each other or keeping each other informed at the very least like the async updates kind of do that.

A

But I wonder if they are as effective as we would like them to be like. How do you see that chase.

D

So when we talked about this, you know months a few months ago, when we adopted this sort of process the one of the things I think the key primary concerns of other people were how not to spam a bunch of people with what might be considered. You know something uh you know just sort of like here's, an incremental update, here's, a thing that is, I'm not asking for any action on for you, but this is like for your information. This is helpful for a wider group of people right.

D

So so we haven't done that in those async issue updates to ping the group or to uh to um directly alert somebody if, unless it's like, unless it's necessary, so I mean I would want to like make sure we're doing that correctly or well, or you know something before we just jump in and start pinging the entire group every single time.

D

I see all of them, because I subscribe to the.

D

The you know the internal get lab to do this oriented, so it has good benefits. For me.

C

I don't I don't personally need pings from the uh new tag, every time that, like amy or etienne or jason, do something is working on something you know.

D

Yeah, I think, but it's a nice async thing if it's there, if.

B

D

A

Yeah, I I I see, I see what you mean andrew, like it was not. My at least was not my intention to intend for that mansion attack to be used all over the place, um like the use case I had for the attention tag was purely for the verification process. Hey we are like this is in the product right now like this is this is done. We are now aligned that this is done right from an engineering perspective.

A

I assume that if they have done all the work, it is super duper clear, uh but from my perspective and or its perspective as well, uh it is often where, like I don't know like if something works yeah. If I see it on gitlab.com, I know, but if it's not I'm unaware, unless I specifically jump into the issue after I got pinned on something or something like that,.

C

So would this would this concern kind of be covered by the above discussion that we had earlier or are you? Are you looking specifically for just tracking stuff, that's kind of like in flight.

A

So yeah, I think this is a very different, um a very different stage of the process, and you know like the uh keeping or the like informing stakeholders at the end is like all right. We at least catch everything instead of dropping some of it.

A

Now it's focus on the rest and see how we can um we can fix that in in a way that makes sense. So I I wouldn't want to notify all engineers in like when you post a merch quest, update or something like that. That is not. That is not the idea, but I do think it is important that the stakeholders who are involved with that specific issue are updated when you post an update, because let me let me phrase it the other way around you were creating async updates.

A

If nobody reads them, why would you care writing them right and um to kind of make the other point where chase where you were describing hey, we were mostly you know, aligned with. We don't want to create spam for everyone.

A

On the other hand, you say I am subscribed to everything like I get all the information.

B

A

You get all of it.

B

Like I get nothing yeah.

A

So, where, where do we like, we need to meet somewhere in the middle which works in in in a good way, and um with that in mind I would say I mean if I would speak from my personal perspective. I would love to be like if there's an async mr update ping me on it, like just ping me that is, that is awesome, um but that is hard to describe as a process.

A

um I think, or it would be, welcoming such information. um I don't know about marcel, but you know which other stakeholders are there to be included. Perhaps there needs to be created, something for that as well.

A

I don't know like what would you propose for um you know for such things to happen, because my next step in this case would be like all right I'll invite, for example, an engineer from a different team where that process is active and a designer from that team, where that process is active and ask them like all right, how are things going, your team, what works? Well?

A

How did you decide on these things and kind of for us to take inspiration from there, but perhaps we have some intermediate solutions which works for us with our own creativity.

D

Yeah, um I mean, I think, if there's, if we're I'm wondering uh the first thing I I think about when I think about you just making this as easy as possible right, I want to be lazy, so.

A

D

Like if we're using a tool like tall tall to to do those acing updates, I think there's like a way that that there's, like a um you, know, there's some kind of template there. That's like it, builds out right and maybe there's a way that we can um use that use that template that it provides for the update itself to also include, like the you know, to cc.

D

You know a subset of people who might who you know want to be opted in all the time. Somehow um you know re, I'm fine to have it too. I mean I, I don't know how it's possible if I can get more email than I already do, but we can. We can try. um So um maybe.

B

That's what maybe that's one way.

A

D

I just want to make it as lightweight as possible.

A

Yeah because yeah, I agree there make this lightweight. I mean like just to start off with, like I'm speaking from product perspective here. Right, like I, don't speak for any other stakeholders. um For me, it would already be okay, like just include me, in order just say, for your information product product progress delivery.

A

I know that's too much mentioned tags, I'm I'm I'm unfamiliar with tools as telltale and how that applies to gitlab, but um just not mention of product. When you give an update would be more than welcome- and I know like you know- maybe I'm selfish here a little bit with you know relying on to-do's instead of emails, but I yeah, I know like it's a gitlab, supportive feature and, like I know, multiple people working with that.

A

Perhaps I'm unsure like I would love to see a notification for async updates, as that kind of continuously uh keeps us informed right.

C

Maybe maybe the async updates in the issues aren't the right move. Then.

D

They should should they be somewhere else or.

C

I mean, I think, they're the best place for them, but if you're looking at, if you're like, if, if dimitri is basically looking for a news, feed of.

A

C

A

C

We that maybe then maybe that's something.

A

C

Something I mean like for that.

A

The feedback that nadia gave from the other stage groups is basically this. They keep each other informed through issues slack and meetings and stand-ups. That's what I do. So it's not one single thing that fixes the problem of over communicating and being inclusive in the in the build process. It's like all right. Where are we today? What are we gonna do hey by the way. I need your help on this by the way, hey, I'm creating a new merch quest, because I'm scoping out this small feature subset hey by the way this might interest you.

A

This is going on. I decided on this this certain way of going forward, uh p.s think about including this other person. I don't know it's like it's it's this this thing of when you do something who can. I include to make more aware of this thing, I'm doing and might make sense. I think that mindset is the thing that like gives us um like the up the upside the like. That is what is going to give us the follow through.

D

I think what you're getting at there is what you've alluded to before, which is just this. This idea, and this this comfort with over communication right and just to like, hey, hey like and with the always assuming the best intent possible right, like dimitri, probably wants to know about this right. So go ahead and- and let him know like and just you know, um say hi, you know try and shift behavior that direction.

D

Maybe that's enough right if the other teams aren't really doing anything differently, then other than this, then maybe that's what we should steer ourselves towards.

A

How how would we do that? I know we're going a little bit over time, but if there's a little bit time left, I would like to at least have an actual point. There.

D

I mean we can update the handbook to you know, make that uh clear, and um uh you know a clear. You know, motivation for the team to to do so um uh and just and I we can just reinforce it right, be like hey and do and do the opposite.

D

When you see you know when there's something you would like to get feedback on earlier and you didn't same thing best intention possible, say next time it would be great if I could, if you could hit me up with this earlier right and maybe that's uh another, reinforcing mechanism that we can do.

D

um I don't know it's difficult to to to turn into a um a process. Type thing. I think this is more yeah. This is more just cultural than anything.

A

Yeah, it's something yeah! It's a mindset right.

D

A

Let's let let me let me set up like a handbook proposal. I think that's like the the clearest action we can do and we can discuss it in uh when I'm back. I saw the point on.

B

A

And ninja, I have a management issue, I'll link that here I'll also describe it extensively in slack channels and ayanna will be covering an ian from package, um so there will be coverage uh for sure and I'm trying to kind of neatly wrap up things this week as much as I can.

A

So that is the the plan for me going out of office, but yeah the handbook update I'll see if I can uh squeeze that somewhere in between and have everybody kind of, like iterate on it and um kind of acknowledge. If it's, okay or not, you know like this to some something actionable or not sounds like a good idea.

A

Thanks for all the input today, that was super valuable and um there was one point left to discuss, but we'll do it another time. So, thank you. So much bye, bye.