GitLab Simplify Groups & Projects Working Group, 19 Jun 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Walkthrough Azure DevOps and discuss GitLab's permissions

Description

@mushakov and @gweaver talk about the challenges we need to overcome to provide better planning and permissions experiences within GitLab.

A

Don't have some interesting things.

B

All right, so here is azure devops, so basically you can create what they call organizations.

B

So these are containers for projects and inside of organizations. You have all these different settings right that are about just like holistically.

B

What's on there like, for example, here's when you can say like what processes you allow right, so this guides, like your workflows fields, things like that, so this is kind of like higher level things that you want to apply to all the projects below.

C

And we talked about, I mean the value in this is that a I've talked to a customer recently who they manage separate instances so that they can keep different organizations separate data separate, and so, if I remember this correctly, this organization is the way this. This works in azure devops. Is there they're the isolation.

A

C

um I also think it would be good if we had this so that you could have uh users belong to organizations instead of to the instance um and I'll have a lot of settings that, especially for cloud that are stuck in the instance configuration be available in the organization configuration. So I.

B

Yeah- and these are things that we like try to have the top level group do right, but uh it's like we're doing this already, but we're just kind of mixing it with group and applying special rules to like a group, that's top level. So this would just be kind of formalizing that in a way.

C

Yeah, it makes sense.

B

uh So then, inside of that you have project, so this is like your isolation. Layer, like you, said right so and then in here you have different projects, they're, like repositories for things right um and you can choose what you enable in them right. So this one's not new, um but you basically get like a welcome screen, which basically you do this right. So you can say this is boards. This is repo. This is pipelines. This test plans artifacts right.

B

So it's like what is this for right and it's flexible and you can like make it do one or all of them.

B

um So this is basically then, within this project you have, like you know your repos, your pipelines, your test plans, and then boards are also here.

B

um The thing that's interesting about how they do boards is that I'll go back to project settings. Is that basically how it starts out? It's like you have this big container right. um When you create the project, you have what they call the default team, which is just like. I don't know in case it's like one project, one theme right and that's where it ends, um but you can actually create. Oh here, it's over here, multiple teams. So I like created another one. I can show you what that looks like.

A

um Gabe's team.

B

So you can assign permissions to it right, so you can say these people are readers. These people are administrators and there's like these are basically baked in roles. uh I could send you a documentation for that.

C

It's yeah, it's fine! I can find it.

B

But you can you create a team and then you can create an area path for them. So basically it's like you're chunking up that project into different sections and I'll show you how like where that applies.

C

Yeah go for it within a project. You can have many repositories, though, probably in many pipelines and like it's not just a one to one.

A

C

B

A

Into that yeah like yeah, you can create different repos.

A

B

So that yeah, you can just like, have different things in here.

A

B

Then, if we look at work items right, this is like everything in the project.

B

Then, if I create a new work item, let's say I'm creating an issue which is sort of the.

A

B

A

B

Like a story in jira.

B

I put it in a path, and this ties it to that team. It's still within this project, but the path is kind of linked to the team concept.

B

So I'll put it here right and save so then, when you go to boards. Basically these are team. Views of these are like filtered views of the entire project repository of issues, and if I am added to a single team, then I only see this board right. I see all of them because I'm the admin here right, but if yeah, you would see like a filter view of this, and this is where you like.

B

C

Have like your.

B

Epic and your issue, and you can filter and do configure team settings right like these are different things that you see. This is sort of like your backlog view.

B

And then one thing I haven't looked at is um reporting uh to go back to your question of like how do I see team specific analytics right.

A

B

How they do reporting is through these queries, like you, can do different.

A

C

Don't know I remember this yeah um we can look at it.

B

C

What you would.

B

Do is create different charts based on area paths and that's your team kind of like analytics.

C

So what are the things that you like about this just curious or that you think work well.

B

What I think works well is that you're separating the repository aspect from the permissions aspect, um so basically what what they have is you're, basically creating paths, containers for issues and repos, and all that right and separately right within organizations.

B

You have users right which exists at this top level, and then your users are assigned to different projects right, so you're sort of decoupling that which I think is confusing right now right and then you can create groups which are essentially just um for permissions.

B

We're kind of conflating all of that into our groups right now right and I think, having it separate, actually makes it simpler, because you can specialize and make the object smaller. So that's one thing that I like about it.

B

I like this. I think we definitely need to have this higher level abstraction level of organization right, because I think that will make things easier for us uh of just having this kind of special again like a more simple specialized object that all it does is defines boundaries right kind of like what we're doing with top level groups.

B

Then the thing that's nice for you with this is I started playing around with uh some of the scenarios like cross project linking of items right.

A

B

Because you have this uh higher level abstraction level at the organization, you can allow issues to sort of like commingle within that organization right, so you can have an epic in one project that has issues.

A

Basically, across the whole org.

B

If that's something that you know, you need to do.

A

B

Something, that's nice, um I don't understand yet how you would get those team level metrics like what you're describing right or how that would work. I haven't played around with how this basically ties into your repository right like once. You have issues and one project. I don't know how that ties into.

A

Repos and that's.

B

A

Was going to look at next.

C

Yeah, I'm pretty sure that uh the way it works is that a within an issue you you reference a given repository so like, if you can look at whatever you want, um I'm pretty sure that's how it works is like you, you more or less like ref. This is where the change is being made and here's like the change requests and the change request is the issue.

C

um I don't know if that shows up in the repo view, but um out of all of the the enterprise level tools that I was tested when I started at gitlab, this is one that had the best flexibility. I think for some of that, while also like being incredibly complicated a little bit.

B

Yeah, like the permissions model, is very complicated, um so, like a story right is that um I was working with a customer to integrate azure devops to the product I used to work on and their permissions model is actually super complicated because you have like. I was showing you um like over here in organizations right. You have users here and when they, you add them, you're assigning a permission level here right and then you're, adding them to projects.

B

You're, adding them to groups right so there's like four or five and levels of permissions is at the user level right when you join, and then that has like a whole chart of permissions associated to it.

B

Then they have these uh like groups here that have permissions level associated with them and then like within the project. You can have another set of permissions, so there's like nesting levels, and we had. We literally spent two weeks trying to create a user that had the right permission level uh just because it gets so confusing um with how flexible it is.

B

So that's something that I do not like yeah as far as the project setup. um The thing that's really nice that um they do is like. Once you build these queries and build, you can build really nice dashboards um I'll just do like, like they have this really nice uh sort of like sql like ui right. So that's really nice and then you can like career across projects.

B

So you they have a really nice integration with excel right, which the business users that I worked with loved because it's basically like deep link right, like you, do a bunch of stuff in excel, and it just like. Updates.

A

Which? People really like.

B

And then from here, basically with this data, you can create charts.

A

A

Where was it again? Oh, it turns.

B

So it's basically like excel within azure devops yeah.

A

So that's something that was nice.

B

And this is how you get some of those kind of like team level metrics, but this doesn't solve for what you're trying to solve for right, because it also um sort of imp. There's no like explicit team assignment or anything like that right. It derives all of the metrics and everything based on the location of items.

C

Yeah but that's a team right.

B

But if I'm, if you have a shared team, a shared repo uh with them, you would run into the same issue that we have.

C

Yes, you are, uh but you may maybe not, uh because you will, if one issue represents the change in the repo the merge request, which I'm pretty sure that's how it worked last time, I'll play with it um that merge request would be mapped to the area that the issue was, which would be the team. Okay, every path does that make sense.

C

A

Because there are.

C

Yeah so um like let's say you go to gabe's team in here and you have an issue, then you open up a merge request which I haven't gone through. We can go through the merge request, process and the repos and just see what it's like, but I'm pretty sure you can associate that one merge request with the issue: that's in gabe's team.

B

Oh, I see what you're saying yeah.

C

So you can pull through that way um right now. Our our problem is that we within a project we look at the emerge, requests and the issues, and we assume that everything happens in that one project, so the reporting, for example, value stream, reporting and stuff all happens uh based on the objects that are just within that project.

C

um So if I have uh my team, gabe's team and I go and open a merge request and a repo um there's no way to pull that data back into map it to my area path, if that makes sense, we could figure out how to solve that. I think uh fairly easily.

C

um If you like, you, you more or less could map which mr relates to or.

B

Resolves link yeah from the issue right, like have the issues all live in one area path here right, but then the mrs can be like multiple places, depending on.

C

Yeah and that's kind of where I was talking about a little bit too though, but like given, let's use gitlab as an example. We have, uh we have a project or an area path uh where all of our issues would live right, um that's open to the public right, but that area path that is open to the public. Where all the issue lives is not my team right, and so I would need it to live there and then also be able to associate it to my team.

C

So my team could plan it, even though it doesn't live in the same area path.

B

Yeah, that's where I was thinking of like where well is it as easy as having like a team field right? That is like a group right so which group owns this.

C

B

And then, basically we have views within that group that show you all the issues that that group.

A

Is assigned to.

C

Yes, by default, it would be the group or it would be the group wherever the thing where the issue is created. Unless somebody specifies something else right, so they can pick something else. When it's created and more or less say that the team we didn't call it, we could just call it whatever we call the container or the thing the shared namespace type thing, and then it would just show up there.

C

The only the thing that gets complicated is what, if I am in my my repo, which is like the shared place, uh and it has a given set of milestones that are there and people who can see things, and then I have my team area path that only my team has access to and we put a set an attribute on that issue.

C

That is from the shared thing, because it's now been granted it's like assigned to my team, like we put, we put an iteration on there that is not accessible to this other shared place where the issue lives.

B

That's what we're saying so.

C

What would the experience be when they see that and then, if they click on that link to go, look at that iteration report would give them a 404. They don't have permissions. You know, that's just the the thing to think through when.

B

Yeah, maybe if all those things are managed at the like organization level, then you might not have that problem.

C

They won't all be managed at the organization level, though,.

B

Yeah, sometimes that makes sense.

B

Yeah, it's a good point. It can be like labels, it can be like milestones. It can be a lot of things right, like basically anything you manage at the project level.

C

The way that you could.

B

Lives over there, but you want to see it here and man.

C

Yeah, the way you can resolve that is show maybe show the information, but don't let anybody who is not a member of the team to which the thing is assigned, modify it whatsoever or like change any of the metadata it'd be like a guest. Only access to the issue.

C

So, depending on who owns the who, the issue owner is or which group or which team, whatever they're the they're, the team that can set the metadata on the issue, I don't know it's like. I don't know how to sell for this.

B

Yeah, I know I know I'm like I'm thinking. Maybe it's just like a point or two like you can see it. You can report on no, but if you can, if you need to be able to report on it, you have to have things like this sprint and all of that apply to it in the same way.

B

Everything else right, because if you like, because my first thought right like where I was going with this is like- maybe you see it, but like all the labels and milestones and whatever are still the ones for the other team for the other area right, but then that breaks apart when you try to do any reporting on it right, because now you have these like foreign things, foreign labels, foreign milestones right that you can't really correlate very easily to the rest of the info.

B

So maybe what you're saying is right like when you, when somebody claims it right when you own it, then it's almost like it lives in your area. Now.

C

C

B

And your labels, your milestones, your epics right, like I, don't know what the rules are right, but basically these are the things that apply to it. Now.

C

Yeah, I I don't know if that is like makes it overly complex from a performance standpoint, so I feel like at some point we're gonna have to decide how to handle it.

B

C

That's one of the things I liked about having the repo separately here. Is it just like you, don't really have a choice um but then again like we couldn't use this in. I think the way it was intended right within git lab having like a public uh issue tracker and all that other stuff, then you would be in the same boat where we have to come up with like a labeling system.

C

That sort of thing. um The other thing I like about this is separating pipelines out from repos, because pipelines like you might only want to define one pipeline that processes all of your different repos right.

B

Yeah, this basically allows you to separate everything out if you want or put it all together, if you want the way they.

A

They've set it up.

C

This is sort of like what I was envisioning when you have the shared namespace with all the resources is you can enable a repo.

A

C

A a your pipelines or just your boards, if you want- um and we should talk to cic folks about what it would look like if they want to have pipelines that can impact many children because, like what I could end up seeing is then you have like one hierarchy: that's all your repositories uh and then you could set up like roles for your pipelines at the very top level uh name, space type thing that then all the children, repose inherit or something there's a lot of cool things that you could do in terms of, like nesting, that stuff together.

B

Oh yeah, that's something that's interesting. They don't have nesting rules, so that's something that we definitely uh have an advantage over like everything is flat.

C

C

B

They all live at the same layer. You know what.

A

C

Yep all right, uh so that's the access problem or permissions problem, because I think in my video I also showed how right now it works.

C

Fine that you can share a group or project with another group and people can have you can set what permission level you want them to be able to have so that they can see all the things and then the next step would be like if they can see all the things left and then assign a thing to their cell switch up there, and we can think through that a little bit more.

C

But I think that would I it's a weird fringe case, but more and more organizations I'm talking to have like the shared services projects where everybody contributes uh like what they call intersourcing and then they have all their like teams where they work on all the stuff that they've been assigned and the house set for repos over there for that they pull all the share packages into so.

B

Yeah, I think the more common scenario is probably the one that we talked over slack, that.

C

B

Believe it was a sales person sent to you, which was you have um sort of like a department right and within the department you have teams and to cover the higher level. Epic completely.

B

There's all all different teams basically need to work on an issue for it, and then all of them combine sort of like complete epic, but right now, there's not a good way to handle that outside of creating epics within each group. Right like.

C

Yeah or using labels, but that's still you know like if you want to go for like zero trust, then you want to be able to add people to just what they need access to um and create the things there and so we're working on epics. Now we create an epic, you can assign it to a child group which is really small change, but that way you have flexibility like push things up and down or almost change the assignment of the epic.

C

I think eventually, the same could apply if you have, if you create an epic like in a top level group, and you want to assign it to a child group, you could assign it to that child group and it would show up in that list without having to move there. It's like where something lives is almost like less important than who has access to it because, like you, would already have like, if I'm in a top level group- and I created it in the subgroup- I would already see it and it would roll up anyways.

C

So this is just like the reverse proxy of that saying, like I'm, going to create it here and I'm going to assign it down here to this one, and it will.

B

A

C

Or something like that.

B

Yeah, it's almost the same problem, but just slightly different right, because it's but it's yeah, the location uh is one kind of facet of it and then the access and basically how you time together is another.

A

B

A

B

Right now, they're kind of mixed together.

C

Yeah, uh did you look at jira at all or what they were doing.

B

Yes, so basically- and this is neo- I don't know if this is new or if I've never seen it, but they also have a construct of an organization on.

A

A

I don't know why I kicked me out. I think.

C

A

Oh yeah, I logged into something else, one second, all right.

B

I was inviting myself.

A

To see what that experience is like.

B

So they also have the concept of an organization um on cloud at least.

B

A

How do I get there now administration.

B

B

This is where we have users, you have groups which are also for basically different permissions.

C

How does jira line play into that like? How do you, I you sent me some info on sort of the integration a little bit, but if.

A

C

C

So how do you have like progress role? Because I watched like an hour-long demo on geroline? It was showing how you could have all of your information from jira roll up into progress, reporting on your road map and your strategic initiatives and a lot of stuff and sort of inside of jira line.

B

So, basically, how it works is, and your journaling is pretty uh like close to safe, whereas you have um like a portfolio right. So these are all different objects. You have a portfolio, you have a program, uh you have a team, an agile team right and you have work items that align to each of them right. So teams works on stories, programs, work on features and portfolios, work on epics and themes, and it's all sort of like a single hierarchy.

B

um And then you basically set up an integration between a jira board and a um agile craft team.

C

B

So the board- everything that's in this board is this team's work and you sync it all over right and then you also can sync epics right. So epics in jira end up being features in a line which is like super confusing, because then you also have epics in the line.

C

B

uh But jira epics are really like safe features, uh they're not really safe, epics, which is like a whole other thing where it's like people that use safe, don't like jira, because they can't rename all their stuff to be like safe right and they spent like thousands of dollars, training everyone. And then it's like wrong in jira.

A

B

Was like a whole thing, but anyway you think it all over right. So you think all over all the like team level work items to align and then within a line. That's where program editors do their work and they basically build up all the hierarchy of work items there and that's.

A

How they do all the reporting.

B

They tie everything up.

C

Okay sounds fun, so I think we want to have some basic support for that, like that's, where I think we're close to having support for that and uh with we're gonna, add epic boards so that you can do that and stuff, but we don't want to go safe, whole hog by any means. So um I know that's what I'm trying to think about keeping things as simple as possible and we're using like small primitives, where applicable like if we need to do teams eventually, so you have specific permissions to different places. That's fine!

C

You could also treat like a namespace as a team, because you can already share a namespace with another namespace. It's kind of like.

B

Yeah, I think, that's the direction. I would want to go right if, if like, because right now, um just like share the challenges, I'm hearing about from like the sales and the tam teams, is that basically people end up creating these, like members, only groups right where all of all they're doing is creating like a hierarchy of users right for permission, so they're, basically saying like these are my admins. These are my ops people. These are my you know. Qa and sharing those groups to wherever is appropriate right, like.

A

B

Repo access, but they basically have like all this stuff in those groups that they don't need right. It's almost the same as like when people are creating issue only uh groups and it's usability wise. It's weird right because it's like oh, don't touch anything. They actually put it in the description like don't create issues here, don't create repos here, don't do anything other than add people and only add them at this layer. Don't create projects and add people there, because that's not how we want it set up right.

B

So it's solving for that where it's like there's this very specific use case that people are trying to solve with groups that we have today, and this is their the way they're doing it. So, let's just make it easy for people to do that.

A

C

Well, one of the things that you could like: if, if we reuse a small primitive, you could have like a toggle that says like this: is a people only group and like yes, just just disables everything but like under the hood? You don't have to create this new thing. It just is the behavior of that's kind of how I was envisioning it.

C

So that way, if you want to have a wiki only thing, you could have a whole tree of those and then have like the t people only groups like be sent over into there or maybe the part of the reason why I think we have these notification. Only groups, people groups right now- is because they want to use the notifications like at you know so and so team right. So I've seen a bunch of those too where it's like. This is a team notification group.

C

That's the only reason they use it for notifications, um but they would use it for issues if they could have issues in other places show up there, but since they can't they say, don't create issues here, because all of our issue management happens over here, where we don't have that. So.

A

I think it's almost.

C

It it will solve a lot of problems.

B

Yeah, actually that's a good point like if we had issues and people uh group right. That could essentially be like that and we pulled issues from basically wherever that group was assigned. Let's say it right to an issue, then that would be like your team's space right. That's where you manage like who's on your team and what are they working on.

C

Yeah um trying to think of like if you had one just for different permissions levels and then one that is like your team's hierarchy and then one that is your repos, your other resources that could get a little complicated. But I don't know.

B

You might, though, right because if you have I'm thinking like what's a use case for a permissions, only group right, it could be like your auditors, for example, like you say, these people have access to everything right, so you create a group, that's auditors, and then you basically will add them at the top level and they have access to everything, but those others are also part of their own. Like.

A

B

Right and they might have a board.

C

B

C

B

Right, maybe it's only for permission.

C

Yeah, I think that's just where it really comes down to making it flexible, but also user friendly. Like the other feedback. I've gotten is the non-technical folks when.

A

C

Come into a gitlab namespace, they have no idea what to do, and so they're they're, like their first touch, they're completely missing out on a lot of the hidden values like what I heard, um and I think this is where the opportunity is to surface all that stuff when you create the namespace or somebody comes into it for the first time to have like a great experience based on what the namespace has been used for.

C

B

Yeah, so let me.

B

So jira actually does some stuff like that right. So it's like I'm creating a project I'm actually classic. Just because.

B

Yeah so like this is pretty nice right, so they have these.

B

I didn't click into all of them. I don't know exactly what they do, but they're kind of like saying.

A

B

Actually, let's do one of these right like a.

A

B

That's one big thing that atlassian is uh so yeah: it just creates like a basic project, but it they already have pre-created boards. You could do this with a blank one right, but they're just applying.

A

A template to it, which is kind of nice.

B

um That's all it does right and I assume they have issues yeah like special issue types.

C

All right um cool, I'm gonna to I'll put this on unfiltered. If that's okay with you and um we'll take some of these things that we've been talking about stock and put them into an issue. uh I think liam still is like unsure about this, which is very valid.

C

um I guess just as we continue to think about it. The one thing I want to avoid is having it filter through a bunch of stuff in a place that has a bunch of things that I don't care about. Just so I can see the things that I do care about, which is what is draining on me personally and I think also like a lot of our users is like.

C

I can see all these things, but I don't care about 80 of them because they don't involve my team and I don't want to have to like use filters, never viewed after meaningful, like experience.

A

B

And right now we use labels right like even we're feeling this like. We use labels and, like that's how we do things.

C

Yes, I would like to get away from that label serve the purpose for some things, but I think for other things, we should build in better experiences, so um cool all right, I'll, open up an issue to talk about this more, let's get other folks in the working group involved. Thank you for your time. You're amazing um and I appreciate the collaboration.

A

Yeah same this is.

B

Fun and yeah I'll take it I'll, look at the jira stuff and I'll put it in a similar document. Just so we can see what you know. Other people are doing.

C

Good idea, thanks a lot have a great weekend.

A

C