GitLab Working Group: Merge Request Report Widgets, 30 Sep 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2021-09-30 Working Group: Merge Request Report Widgets

Description

Sixth weekly meeting.

Agenda:
https://docs.google.com/document/d/1bcch8UUkwmgEHFolTWDrQFJtUiiXlv_yQFAGwSSDSUE/edit#

A

And we're live all right, hi everyone welcome to yet another weekly call for the merge request report, widgets working group, all right uh who's. First peyton peyton is the first on the agenda um he's not on the call so I'll read it out. uh I plan to send the first prefactor into review today, thanks peyton, um this is exciting. um Okay, again, you have something to say.

B

Yeah, so my question was: would these require? Are you extraordinary, because I know that this was a refactor and gina? That's also is not a call. uh I'm gonna read her comment here that um I voiced hyanna uh in previous meetings that we would like uh to be added as yeah ux review.

B

And peyton already added gina to this merge request. So there's a thread also in black in the testing team, and they are in contact about reviewing this.

A

Good uh yeah and uh peyton did mention that.

C

A

Even though a lot of the ux parts will be handled by the core, uh I think it can. I think it it couldn't hurt um to get a ux review. Out of that um I so phil is. It is peyton's work already using, for example, the icons that we have yep, oh good, so this is good news, then, because we already have two issues merged uh one is the level one um level one icons and something else phil. Do you remember what it was? The second like it's been.

C

The icons and there's all like little bits of design changes to match the framework a bit better.

A

Cool then, yes, then definitely could use a bit of ux review with that in mind um that there's still going to be a parts that are going to be addressed at the core and again it's not going to be enabled by everyone. So I'm not going to be enabled for for people to see it yet so we're pretty safe there, um but I like to get ux involvement everywhere.

A

We go so um right, good news- I I will play around with this just to see how it feels um definitely definitely exciting steps being taken thanks payton for the hard work any more any other thoughts on this point, or can we move on.

D

I do have a very quick question. um The last time we had quite a few updates behind one feature: flag was for the sidebar on the navigation work, and in that effort we enabled the feature flag for all members of that working group so that they can be continuous improvements and that they can also quickly see if there's anything, going wrong. Should we also discuss that for this one here.

A

Yes, let's discuss it. um I think, since this would replace the other widgets, I would potentially suggest having a project set up as a test project that we can play around with, um could be a fork of of gitlab or some smaller project like gitlab ui, or something like just to use it as a test, because that way we can test it.

A

But we won't have like every project that we visit be affected by any potential bugs or shortcomings, because we want to have one feature flight for all the widgets for now, and that would basically replace some widgets that are not refactored yet phil is that accurate.

C

I mean like enable it per user, because then, if there was bugs filing quicker after the test project or less likely to find the bugs, if we're using it every day, really.

A

So but then then, you'd replace the, for example, the rewritten widget for that user. Only only that widget and not the rest.

A

A

Can we make it up tin, like um those who want to have it can have it, because I I am afraid that this will cause disruptance and then, by the time, for example, somebody's finding a problem on the widget. They need that mr to get through and it could be disruptive of work. That's what I'm afraid of.

C

It would just be often, like normal feature, flags for projects to be.

A

Okay, so we'll uh we'll prepare a message on slack or something for people to just speak up and to opt in we'll enable those feature flags for them uh and then we'll keep chatting whenever you need to maintain that. Would that work for marcel.

D

Absolutely sounds great.

E

All right, the testing group has some sample projects for each merge, request, widget feature we could enable it for each of those sample projects. People can go and check them out.

A

Can you can you handle that scott cause? I don't we don't have the knowledge of which groups which projects those are.

E

Yeah yeah, I can handle it once the feature flag is merged I'll. I can add that.

C

Awesome it's just on that there I don't know if we can have a feature flag, enabled for a user and a project because you have to select an actor, is either a project, a group or a user. I don't know if you can have more than one.

A

I've never done that nope, we could try and then we'll know do you or you do know for a fact that does anybody know for a fact that it can't be done pushing to the limit? I love it right, we'll try it out and if it works it works. If it doesn't work we'll follow on with the just users, sounds good.

B

A

I see the thumbs up got it thanks. Marcel.

A

Right uh rihanna, you have your point.

B

Yeah just an announcement, I'm in conversation with gina during your one-on-ones and things testing owns most of the the widgets. uh I suggest that she add herself as a member, uh because she is already watching the recordings, but not joining the calls. um So uh she opened a verse request, adding herself as a member I already approved. But if anyone wants to say something, um I will merge this and we'll be seeing gina uh here in default as well.

B

I think it's very important that yeah also another ic, get the context of what we're doing this year uh in terms of the time.

A

B

Clicked, I don't know I just I just.

A

Clicked merge, okay,.

B

Sorry for stealing your thunder, it's okay! Let's pretend immersion.

A

Well, you know it's.

B

Live people saw it.

A

No, absolutely yeah the more the merrier and uh more paradise expertise bringing into this fold it's great, so everybody wins nice, so uh discussion items then um the I I was looking through the axis criteria, just to make sure that we keep on top of the things that we need to kick start and it seems like the first stage of things will have to be the engineering efforts.

A

um We've already talked to tim noah last week about the the process for adding uh new features uh is pretty well supported by the process we already have for contributing with things into merge requests. So he thought that the process was fairly solid, so we don't have to kick start anything there explicitly, but the other step that we have for the exit criteria is to add documentation um documenting the features of the car widget right. So I think we're still early on that, but I wanted to check in with the pulse on this.

A

What do you think would be the good moment for us to start talking about the documentation updates? How will we update the and I'm talking specifically technical documentation on how to use this sort of thing? Since we're still having features might be early, I don't know anyone has thoughts.

A

One one at a time please um so phil do you have any any moment in which the sort of consuming api would be stable enough for us to start using it based on documentation alone,.

A

So so peyton is consuming this right and um in terms of like the consumer-facing api of this core component is when will that be stable enough without adding more functionality or parameters or options or props or anything?

A

When will that be stable enough for us to start putting that in in stone documenting it.

C

um I think it's pretty stable enough now for level, one okay, but it might change for the individual ones, level. Two, maybe level three.

A

Okay, so if we already have parts of the api that are stable, we can have initial conversations about what kind of documentation we could use. What any tooling that we can use to keep the documentation up to date, eat more easily. So maybe we'll start creating an issue for that. I don't know if you already have an issue or not, but if not we'll create one and then we'll start a discussion on how that could look like not particularly rushing the implementation of documentation but starting to talk about it.

A

I think if you already have parts of it stable enough, we might as well just start talking about it. um Yeah I'll, take an action for that to bring in uh an issue, for it sounds good.

A

Sweet and what else we got. Oh, that was the technical discussion from before. um I think. That's it then right. Anyone has any other topics: announcements, discussions, anything.

A

All right, I think, that's it, then another successful and productive meeting great to see everyone have a great weekend, see you next week, bye.