GitLab Settings UX, 28 Jan 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: How might we simplify settings inheritance?

Description

Two GitLab designers discuss how different settings are inherited through groups and projects.

A

Neat so yesterday daniel you commented um that you had a related issue that you wanted to cover together.

A

So can you talk me through a little bit what you were envisioning building out with melissa on the cascading settings.

B

Yeah, so I actually, she just passed this uh issue off to me uh yesterday in our one-on-one, so I haven't had a full chance to understand the scope apart from, if we think about how settings work in our organization, a lot of them are based specifically at the object they're associated to not in an organizational inherited model. So I can have five different projects that have different behaviors, despite all being within the same group, for no particular reason so, for example, like uh project deletion.

B

So this one that we want to highlight is delayed project deletion. So I, as a.

A

B

Owner or maintainer of uh content within my group, I should be able to remove or delete projects or assign a behavior that's standard across all of my projects within my group. So if I wanted to say, for example, I know I'm going to automatically delete a project, I don't need them to sit in a delayed status for.

A

B

X, amount of time- or I can say I want that protection across all my groups, despite what somebody who is the project uh maintainer within that level, so that would ensure certain sort of safety or protections, and so this sort of thinking can be applied to any number of things that hasn't been done, and so, when you said that or when she told me that y'all had something going on similar to this, I was like okay well right.

B

Perhaps we should think about other things or architecture, fundamental architecture within the platform that controls or maintains this sort of inherited settings or inherited features that need to be cascading or exist across an organization not just at the specific object level.

A

Yeah, that makes sense yeah. The issue that you commented on for us was the one where we were essentially creating an avenue for an administrator or a group owner to push down their push rules onto their groups or sorry their projects that have already existed at least with push rules when you have defined them and configure them at a group level, um they will be inherited if it's a new project, but the old ones don't inherit it. That probably, is to prevent some things from breaking.

A

um I don't know exactly what all those edge cases might be, but I assume people have their workflows and they might not want to force those settings on everyone, but we had heard from a number of compliance customers that they were having to go into each project, compare and contrast, set and then move on to the next one and do it over and over and over and over again, which could be very cumbersome for a large team.

A

So our thought was, let's start with something pretty small by just giving them an opportunity to see which ones are using different settings and then see how they would want to move from there in terms of enforcing that. But what were you envisioning doing for uh the delayed project setting? I know from my experience I believe, when it's set at the group level.

A

Existing projects will inherit it, but if there is a subgroup, so if it's like group has it set, but then there's a subgroup that doesn't have it set, then the project will not have it set for a delay deletion. I think that's the case right.

B

And so I think the idea being is that that it would just kind of force it from the top down and not have that sort of flexibility or freedom at that point. So if you want to enable the flexibility, you then would disable that at the primary level at the group by saying, allow people to do whatever they want at the object level and then at the top level. You could just say this: is the default behavior and enforce it across the entire organization.

B

So it's one point of contact where they, the admin would make that determination. If they need that flexibility or not, and if not, then the flexibility is open to whatever they want to do, and that's sort of the kind of initial rough draft thought of it, which makes tons of sense. It's like okay, well yeah. Why hasn't it been this way before, where you have one simple toggle, so to speak, or a setting that says, enforce this globally or do not and allow uh enforcement locally.

A

Yeah, I think one way we were considering um helping these administrators specify the granularity of who they want to inherit. These settings was by continuing to evolve the compliance frameworks, so there's an issue to introduce the ability to mark a compliance framework as open or customizable versus a regulated one, and then I think the theory that we want to introduce over time is, if it's a regulated compliance framework, you can force the projects that have that association to inherit its parent settings when it's not something that's normally inherited.

A

So this would be a great example of like push rules or um delay deletion if it's like buried within a subgroup.

A

So I think that was what we were envisioning we're just kind of a ways off from getting to the point where we're able to specify these are the things that you can perpetuate down that aren't happening today.

B

Yeah, I I'm looking at it like as the idea of how can we do this. I guess and the idea of an mvc.

A

B

I think, just from my initial, like first thoughts of this by doing this sort of top level admin toggle you give that admin, the the flexibility to do that.

B

Okay, but you don't change anything underneath it because underneath it nothing changes except for the restriction, whereas if somebody tries to do something, that's in the restriction they'll get to receive a message or they won't have access to the visibility that says they can do that thing right, and so this is where I'm trying to think about it more higher level and not just specifically about deleting something a deleted project or a push rule yeah.

B

I don't know what do you think about like a for the mvc or how we could try that as a first attempt on doing something like this.

A

Yeah, it reminds me a lot of what I think libor has been working on with the jira integrations. um I think that's at the group level, I'm digging through my gdk right now to see if I can um see if it's surfaced yet into the codebase or if it's still an idea in design um yeah. Let me pulse it real, quick.

A

So the way they introduced their mvc for inheritance was they have this little toggle here, essentially, where you can say, okay default settings are inherited from the instance level, but we want to use custom settings so you're basically saying we're going to divert from what has been set um or you can go back to using whatever set at your instance level and it locks everything down. So they give the approach of we're going to box you in. But if you want to unbox yourself, you can.

B

See I'm looking at this and I think okay, this might have security concerns where, if someone not at the admin level says, I want to change this because it's my project, I want to do this. The way I want I was like well, no you're part of the organization or this project is part of the organization that needs to maintain compliance standards. It has to maintain backup security. You know redundancy to make sure things are protected, and so this looks like too much flexibility unless I'm not understanding or misinterpreting where this exists.

B

So it's like at the group level setting right yeah. This is.

A

At the group level, I think you're right, that's the tricky thing about the inheritance with settings and like enforcing things is some things inherently are not something that we really are so tied to in terms of security, compliance like giving teams the flexibility to customize their jira, that's probably necessary, like not every project's going to use the same jira project but, like you said, like enforcing a soft delay. That might be something that the whole company wants to have, and they don't want to get the option to opt out of it. They just like.

A

No, we really do want to be able to get a waiting period before people delete stuff for whatever reason, um or even more specifically, like merge, request approvals.

A

That would be another area where they're just like no, like we're going to require all merge requests not have the author approved their own merge request yeah across your company, we're not going to allow that and you don't want to have projects that can divert from the settings, but yeah.

A

That's the tricky. That's the tricky part. I.

B

Think what you think, though,.

A

Is it seems like we have a couple ideas that are in motion and we can use these as ways to educate how we want to refer other settings in their direction forward.

B

Yeah, that's sort of what I was thinking is that so we have a way to, for example, this jira method.

A

B

I think if we do like a categorization, if we think about what settings or features our actual security concerns versus like it, doesn't really matter what the project level does, if they do that, like I just use an example like renaming it, um I don't think there's a strong change or reason to restrict something, but that's something we can definitely get feedback on right. So, like say what are the top five things that should be 100 lock down?

B

What are the top five things that are you totally don't care about at you know whatever object level, and so we can use that as a proposal by saying these will be the primary settings that are enforced globally by this new feature and.

A

B

Know push rules, uh project deletion, um the the five things that people have most concerned about and we can.

A

B

Do like a simple survey on that, like you know, to send out an email uh for research, saying: hey, you're, a sysadmin you're a.

A

B

Owner what do you want whenever you think about secure settings that should exist uh inherited across your organization or settings that you don't care about? So we perhaps we can come up with a little research proposal with uh anna to try and come up with a mailer for that, because I don't think we need real. Like interaction, I mean honestly, like our top five.

A

Yeah I mean it'd, be a cool card, sorting activity if we just like kind of audited our um settings as they are today and kind of group them into different categories to show like these are inherited um with all projects. These can be. If you do this method, these are you know. The wild west autodevops is another example where they have their version of inheritance, where it's telling you where it's coming from, and then you can checkbox it and say we want projects to default.

A

To this thing, so you know, there's just a bunch of different examples out there.

B

Yeah, should we try and schedule something like that, so we can create a card sorting event or experiment.

A

Yeah, I think that'd be really fun.

B

Okay, cool- I don't know who else we would want to include like perhaps libor in regards to this uh jira work or um hyanna, was doing something with the settings in total um uh yeah.

A

Michael lee is taking over a lot of the um restructuring of the settings layout.

A

Professor should.

B

Come out with him.

A

Yeah, you could be interested and then I don't remember who's in charge of auto devops.

A

It's I'm blanking now, but.

B

I want to say an audio, but I could be wrong.

A

A

Yeah, I can't remember exactly who's. Does the auto devops portion, but yeah we could just kind of uh be bop brown. Obviously we just share it in the ux co-working space, I'm sure they would speak up for themselves and um yeah. We could just kind of get started on mura or something it's the areas that we already have on top of our heads, like, I can think of all the ones that compliance is concerned about, like protected branches, um merge, request, approvals, push rules and I could categorize the ones that I know like what else.

B

You guys got yeah yeah. That might be a good way to do it. Let's grab a mural board and just put it in the co-working channel to say: hey we'd, like your feedback on top five settings, you think are not important or are important for group level.

B

Inheritance, okay, yeah- that sounds good.

A

um So did you have any feedback in terms of thoughts on the direction compliance was taking with.

A

B

The button to recursively apply.

A

B

B

So if you push the blue button, everything the whole audit system is the default or whatever.

A

In that instance, it'll just set them all to that default, but I don't really know how this would happen necessarily.

A

Well, I guess what could happen is someone could add a new project and then change their push rules, because nothing is stopping projects from changing their push rules once they're created they might inherit new ones, but nothing isn't forcing them to keep those so.

B

This is more like.

A

An opportunity to keep an eye on projects and see are they? Are they not because in this example, they might not care about giganet's push rules, they really might not. They might only care about the ones that they put compliance frameworks on. That's our assumption.

B

Let me read the job to be done here, just for the video. So when I have configured push rules at the group level, I want a single action that applies those rules to all existing projects, so that my entire namespace is brought into compliance with these push rules without me having to manually, update every single subgroup and project, and that's.

A

Like a very like micro, job esque, one too.

B

If we look back at the visual that you had, I think.

B

Visually, it makes sense. I don't see anything weird or like missing. uh I want a single action that applies the rules to all existing projects, so just setting the setup defaults below everything would be set all default instead of having to push everyone individually right yeah.

B

Is there a uh a zero state or a response state that shows like grayed out, so you don't have the buttons on the right to set as default.

A

I say like if there were no projects with custom push rules.

A

B

Perhaps like a varied state, where, like you, see the ones below that have like some change or something- and it says when you set this default all these will then change or something.

A

um I don't think anything like that. I mean I had like if there were no projects with custom, push rules um but yeah it's basically. If sorry, it keeps jumping to the comment, so it scrolls down.

A

uh Okay, nope keyboard is dead, um but yeah I just want to. If they hit that all we want at least warn them, like hey you're, about to change. Six, you sure yeah, um it's not like it can't be recovered like they can't technically recover. It's just gonna be kind of painful to do it.

B

A

If you didn't mean to do that's what I was.

B

Yeah, that's what I was wondering it feels like. It might be too easy to push without understanding the repercussions.

A

It's one of those areas of the product where it's not there's a lot of traffic there, um so I would say it's probably only our persona that's going in there um but yeah I mean with that said it's possible, but um I just I yeah I'm. I.

B

Would imagine it's not a big deal yeah? I wouldn't imagine it's like a big problem to focus on, but definitely something to be aware of and document saying, hey, just educate what happens if this doesn't go the way as expected, or somebody wants to undo or is.

A

There an undo yeah, if not.

B

Just like hey, this is the way it happened. You have to go back and do everything manually um yeah like is there a way like a save state variable or a save profile.

A

Like in settings like when you like do this, and then you hit save to yeah, um no, I think it all it's I mean currently awaits the size. It would take action right away. I think that's definitely something we want to be aware of, like you said and open for feedback.

A

Interestingly, when we had shown this to a few customers, they were just like hey. We don't want to push buttons at all. Just give us an api. Okay,.

B

Yeah, so that's another thing: one of the tricky.

A

Parts is we always have these customers just want apis and then other day like. Why don't you want to use the ui? What's what's the hold up.

B

I'm wondering if it's because they're connecting to different systems to say no, I just need to pass this data into another system, and the system then does the work for it there or whatever.

A

It's that, but it's also, I think some of it is a persona of an individual that likes to be in their own workflow and their workflow is living in terminal so yeah they love.

B

Just being able to send.

A

Commands they love not going into the ui, so I think that's one of the.

B

Well, that could be like, maybe like a proof of concept nbc like let's build this into an api and then the next iteration will be like what is this like on the front end. um Just as like a proposal like.

A

Yeah, especially if you get feedback.

B

A

Yeah I talked to mike about that idea, because this we run just almost all the time. It's almost like. We always build api first and then we build the ui and that can be dangerous because building an api isn't necessarily like creating the value that we would hope. It's kind of like a stopover.

A

um It's almost like solving for the wrong problems at times. So what mike's challenged me to do.

B

Because it's no longer like why.

A

Yeah and he's like just ask more why's like trying to figure out if they want api, why do they want api? What it? What is the intent where they.

B

Maybe that's also.

A

B

A fracturing of the persona too right could be. Perhaps the persona needs to be more refined by saying persona. A is this terminal user who just does specific work within terminal, whereas persona b really needs that dashboard, because they don't work in the persona. They just need to see everything in a visual, easy to digest manner, and so.

A

B

I think that's.

A

True, I do think there's a variety of people that serve this camera in the compliance manager role because it is a bit of a hybrid. You might have your like vp of engineering, be the person that manages the compliance for your entire organization, which I've talked to several people that are like that and they're, not like writing code every day. So they do want to use gitlab to drive those actions.

A

But then you might just have your lead senior engineer being the person and they're as much responsible for compliance as they are for shipping code and they just love living in their work, more comfortable yeah. So so I guess that's.

B

Supposed to be listening to one more.

A

Than the other two.

B

Well again, that's we have to do uh like inventory or research of understanding what that scope or what that percentage is right. Do we have 90 percent of our users? Are the cto or just doing the the legal compliance work? And then you have like you know ten percent or one percent, just doing the everything from the command line, or vice versa.

B

We need to find those numbers. I know anna was doing another research study right now, but I don't know if she had one specific for compliance or for this persona. I don't believe so.

A

Okay, cool yeah. I think I still think our um proposal here is small enough that we'll get some useful learning out of it. If it's hot garbage we'll delete it, and if it's useful, then we have something else to build off of.

B

Yeah and just to remind myself, this is going to be at the group level and it will work at every sub group and project.

A

Yeah so at least the way that vision is, I mean back end might tell me I'm totally off my rocker here, but like this would be an example of like hey, there's, just there's a subgroup with a project underneath it. We can see that we know that they're different, um so cool yeah, we'll see.

B

Yeah I mean this looks. This particular use case makes total sense.

A

B

A

Not seeing any faults, I'm positive, they're our faults, but it's easier sometimes to find them out by building something pretty small figuring it out yeah. For sure this is definitely one of those cases.

A

I saw a really great conversation yesterday with uh sid on iterations, and they were talking about the um this feature they'd introduced into like the merge request page where you can expand and collapse sections of changes, and um they had just like gone in and replaced certain things, and then they learned that it wasn't easy to tell the difference between a user having hidden and collapsed something versus the system having collapsed something, and so they had to follow up with something so that you could differentiate if the system collapsed it or if the user had collapsed it once you open the page.

A

B

Just a great example of like.

A

Yeah, it's just.

B

A

Like when you, the problem, you're trying to solve for was, people were missing um portions of the code because they were automatically collapsed.

B

So then they added.

A

A section to be like hey, there's, hidden code here and then users came back and said: you've now increased the page size a lot by adding this to every single file that has hidden stuff that we've already collapsed ourselves. So, okay, great! This is one situation where we want to learn how users want to interact with the data to better for what we do next, because all we can really do is assume what they want: yeah for sure sweet. Well, thanks for chat, daniel enjoy.

B

Your life, oh, thank you, take it easy thanks again,.