GitLab Create Editor Group, 28 Jul 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Create:Editor Product/UX Weekly - 2021-07-28

Description

Weekly Editor group sync between Product and Design

A

All right, good morning, good evening, everyone, this is the uh editor group product and design sink for july. 28, 2021 and um yeah michael I'll hand it over to you for your agenda item.

B

Yeah cool, um so this week's uh bit light, I'm just gonna talk about just bringing attention to one of the comments I had around the commit flow, so I I started looking at the commit flow, because I was taking a look at this idea of following up on the issue about creating patches and after talking about this with uh paul, we decided that, like yeah, it doesn't really make too much sense to lump um patch creation and patch download with commit actions where, from a developer's standpoint, a patch is kind of almost at this level, where you're viewing the changes in one giant file.

B

um So that's what that's the direction that issue is going, but as part of that I was looking at this block here and thinking about how would I make this more pajamas and then I kind of got into this kind of flow and then broke down the different states that, like this commit area, could have um so this is taking examples throughout the different areas within our within gitlab and seeing can we standardize this bit.

C

B

So here's one with like the commit message: here's where you have a new branch.

C

B

Some of the stuff here is to like expand on the buttons amy. I haven't adopted your um label suggestions yet, but I will get to that later this week, but in theory I feel like we could do some cleanup from the web ide level or- and this could like be kind of like a stepping stone towards standardizing the commit flow so, for example, within the single file editor. You have a commit message like this, but if we were going to update this to be aligned with uh pajamas, we normally have labels on top anyways.

B

So if we go like that, we could then leverage that same widget or component that we created in the web id world over here, and I feel like this is a clear way of handling branch selection when you're um uh making changes, because at the moment here is just free text. But if you change it then, like a magical text box appears that says oh you're, creating a new branch which is like different from everywhere else.

B

So I would say that the web id has a cleaner flow like a more structured flow of creating a branch or having actions like that.

B

So here's how like the wiki kind of works right now, the wiki doesn't have branch selection. It's just like one branch, one branch only so you wouldn't have any brand selection yet, but thinking of it from a component kind of standpoint, it's the same component, but these things these actions are hidden.

B

So thinking about that, we almost could approach standardizing the commit flow from two to two areas. One is um the commit actions itself like this widget and this thing here being standard across all areas within gitlab, where you commit something and then the other thing that is to be determined is where like? How do we invoke this view? Like do we have the button in the top right and like how would that look um with a pop-up? Something like this is a model.

B

Is it a drawer? And that's um that's up for debate and discussion within the issue. We don't really have a clear direction on this, um but yeah yeah, just that's where I'm at with thinking of the commit flow.

B

What is might be interesting here is is this: this is what I had in mind when we were talking about.

C

B

The commit flows throughout vietnam is this: what you had in mind too eric, or were you thinking something much better.

A

uh No, this is exactly what I was thinking. um I really like the consistency and seeing it applied in these three different places um makes me really happy.

A

I I really like seeing it uh consistent across experiences, and um this is what we, what we were kind of talking about, which is like the ability to extend the experience in context of the the type of commit that you're making. So, for example, on the wiki, you don't have branch selection, so you don't need that area of it, but it doesn't feel unnatural. It doesn't feel like something's missing, so I I think, that's a great approach and then I think this is a great.

A

A great example of where we can iterate so we can get the commit flow as a sort of structured and componentized.

A

Module that, then, can you know we can extend it as we need to in different ui and presentations so that, whether it's a panel or a modal, we can explore those and validate those and see if um the same ui can be displayed in different ways, but in ways that could make it even more useful or more relevant, given the context of what you're doing, but I feel like once we once we kind of abstract it away into this.

A

This component, this building block that we can put on a page and keep consistent with pajamas and keep consistent experience. Then we have the freedom to explore that.

A

A

So I mean, I think, the immediate next steps would be to try and create a commit component that follows these guidelines in the ui and uses the pajamas style and then start applying it. There's probably three three issues there and like apply it in web id apply it in single file, editor or pilot apply it in wiki, and so I mean that's, that's a pretty solid approach right.

A

B

I think starting within the web id might be a good spot for this, either the web id or the wiki itself. uh The reason I say that is because the web id kind of has this layout now and a green commit button which is like out of pajamas anyway, like it's, not falling pajamas, so that could be a candidate.

B

um The other approach would be build it from brand new um within the wiki area, but yeah.

C

B

Can look into that uh like look into like breaking this down or creating the issue for um approach like creating a component for this.

D

Extracting it for the web, id, I think, makes the most sense.

D

Okay, uh I could be wrong, but if most of the functionality is there, as well as it's probably the most coupled and entangled to like the data and the existing logic, so trying to extract it from there would force us to uh design it in a way that it's, the most reusable given all of the functionality that we want.

B

Cool yeah and the other- that's a great point. So thanks for that chad, um the other reason that this came out was within the design team.

B

um A lot of people were asking about the behavior of this button and thanks for chiming in on this chat about like how this button turns into discard draft um once you type stuff in here and all it does- is clear this box. So so the collapse button like hide, shows and does funny stuff. So yeah, that's just something that we probably could, I would say, remove because there's really no need for it, but yeah.

C

Where does the help text link go currently.

B

Not sure, I'm not sure, oh it's not uh so it's a pop-up that tells you that you need to write a commit message. That's in 50 characters so that it's formatted nicely in git and then it starts highlighting things in orange and yellow to show where rapping may appear. If you can get into the like the 75 uh character zone.

C

Would it be helpful for new users if we structured that into the example message the placeholder.

B

Yeah we can explore that. I think that's a good, a good idea.

C

Oh, you see how useful.

B

That that whole message is um because it's it's like an essay within a pop-up if you ever yeah, so so, there's probably an opportunity here to like clean it up, um leverage like counters, you like, like the word counters um so yeah, maybe maybe we can rethink that whole little bit.

C

Extra complexity- sorry.

B

Simplicity, my friend simplicity,.

B

We do the hard work so that the users don't have to figure out what this magical question mark will review.

C

The reason I thought of that the docs team tends to get.

C

A decent percentage of commits from folks who don't normally contribute to gitlab otherwise and we've gotten pretty skilled at interactive rebases to deal with the terrible things that users do in their commits.

C

So anything we can do to put guardrails in place so that I don't have to remember how to do interactive rebases when I'm barely awake, that'd be super cool.

B

So would that be more on the merge request page versus this page, or would you say this page.

C

B

Is guardrails like hey make sure you do xyz for this thing.

C

The guardrails are here because, if your commit does not meet get labs expectations- and you only have the one commit and you don't know to check the squash commits box, you have a red pipeline forever and ever until somebody comes along and does an interactive, rebase and rewards your commit.

B

Yes, this is a good point. um For example, you know there could be a structure with a commit message, like a certain format that you need to follow. That could also result in broken pipelines as well.

B

um Yeah yeah having those guard rails is something that we'd like touch very lightly with the aesthetic side editor where we wanted you to like uh kind of fill up, this block of text and just block the text, and the idea was for us to like combine that all into your merge requests or like help you uh tick the necessary boxes before committing.

B

um I don't think it's for this iteration, but I think that's a really good, a good idea for the future about how we could display what rules are being followed here, because I I get burnt all day every day, doing anything for pajamas and I forget to use like uh formatting for the commit messages and everything is broken, and then it's like I fixed it. But then those three commits earlier that I didn't like update properly and it's.

C

Cool, what might be simpler for and then for a simple iteration would be planning on a line of help text and we let the help text carry the weight and I could come back in and supply changes to it later.

D

The thing to be aware of there is uh all of those, especially like the capitalization the period, the extra line, those are all just to get lab's internal standards, those aren't get wide standard and even the message length. I really never followed it before here when I was forced to many people, don't so it's not really something we could put in the product, okay, or at least not hard coded. We could make it.

B

Configurable yeah. Definitely I see it more configurable both thing, because you could have teams that say you need to prefix all your messages with um the issue number in a certain way or or yeah so yeah. That's why? I think it's a future thing about how we incorporate that that configuration seems the right way or.

C

B

Or you can set some.

C

Rules: okay, yeah, I'm again totally fine with iteration, but I'll just sit here and ask questions so carry on.

B

That's all I had.

A

Thanks, I was trying to keep up with notes. I didn't do a very good job, but this was great. I think, um on that last point about like customizing, the rules and um behavior of the commit flow, the commit message box. I think that's a really interesting way that we could extend extended in later.

A

Iterations, like you said, michael, but you know, we have an epic to capture things around the behavior of the editor and like get attributes and um what's the other, editor config, and things like that, so you can have the ide and single file editor behave. The way you want your editor to behave. We could.

A

I could see a future where we extend that into you're enforcing the commit patterns that you want, uh give the commit message patterns in the commit flow and then doing that consistently across the product, with one design pattern and one you know consistent, look that would be that'd, be really great if, if you could have, if you could do it once and and have it take effect on the pipeline editor the single file editor, um you know snippets and web ide and maybe even wiki. That would be amazing, so.

C

Stupid question time, because I don't know the answer about the product: where are those commit rules defined I'm kind of looking at chad and hoping it can bail me out here.

D

They're in the docks I think, yeah aren't they I'm pretty.

C

D

They're in the docs, in the section about like maybe merge, request review guidelines, I would have to search for it.

A

But do you mean the actual enforcement like in the pipeline so that.

D

A

You, where you build the rules right.

D

Oh they're yeah they're cops, maybe maybe it's robocop or some other linter stage. You know about lynchers.

C

I'm gonna roll my eyes at you, chad,.

D

C

How I first found out you.

E

Were so awesome when you were like coming along.

D

Can I help fix the linters on www and I was like yes? Yes, please, uh if you shoot me a dm, so I don't forget about it. I can try to dig through them.

C

Because what I was getting to was all right: if the rules change per installation, can we link to where the rules are.

D

A

I was hoping there was something in settings, but it does appear to be something more like a lint rule than an actual gitlab setting.

D

No, it yes, it's somewhere in our pipeline, I'm sure, and it's also enforced by the uh the left hook. Rules like the pre-k hooks you, if you configure those right, it'll tell you, which is great, but you can't count on contributors to do that.

A

B

A

Struggle with the interactive rebasing.

C

Chat, chad have messaged you, so I think we can carry on cool.

A

Well, uh I thought that was great. I will michael, I will follow up with those issues, um probably just create an epic to capture this discussion once and for all. I think this is great exploration you can put these designs or in whatever form you want on that epic. When I create it and then I think this is a great thing to pick up soon.

A

uh The one last thing I'll note is, um I think this is very timely because of the conversation we were having in slack uh recently or this morning, for you and um and potentially being able to shift our focus to the state management of the web ide and that file panel in general. So this is right there in line with that, and if we're in that area of code, hopefully state management file management commit flow. This is a great area of focus for us over the next probably quarter.

B

Exciting stuff, exciting stuff.

A

Cool well thanks for running us through it. I I think it looks great.

B

Awesome have a great rest of your day. Everyone.

A

Yeah, you too take care, cheers bye,.