GitLab Manage:Workspace Group, 3 Mar 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Workspace Plan

Description

This video walks through our MVC plan for Workspace

Epics:
Migrate Groups & Projects to Namespace - https://gitlab.com/groups/gitlab-org/-/epics/6473
Admin panel: Move features down from the instance level to the group level- https://gitlab.com/groups/gitlab-org/-/epics/7314
Implement the top level namespace - https://gitlab.com/groups/gitlab-org/-/epics/4257
Consolidate & Cascade settings - https://gitlab.com/groups/gitlab-org/-/epics/4419

Slides: https://docs.google.com/presentation/d/1nAhc5_hITSKdzLXg132cui6MtyD01sl_AJK6r0oPup8/edit

A

Hi, my name is erica lewinsky and I'm the group product manager for the managed stage here at gitlab today. I want to talk through workspace and this new concept that the workspace group is working on. So without further ado, let's get started this presentation and link contains information related to upcoming products, features and functionality. It's important to note that this information presented is for informational purposes.

A

Only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this video are, and links pages are subject to change or delay. The development release and timing of any products features and functionality remain at the sole discretion of gitlab. So, let's start with what is a workspace, and what I want to mention is that this concept of workspace is the top level namespace.

A

It's also called a top level group, a root group, an instance group. The name might change we're going with workspace right now, but it is that top level entry point of everything, consolidating everything you need in your organization.

A

It represents the highest hierarchy of a group within an organization, so there's different permutations, how we've seen different organizations organize their groups and projects within gitlab, and so, if we look at a workspace, it could be this top group, a this top group. A may have flat projects underneath it. It may have groups underneath it and may have sub groups underneath it that also contain projects, but that top level group, that's the workspace.

A

Other permutations can be no flat projects under needs or workspace, but it may have a bunch of groups under it that contain projects. Other organizations are organized a bit differently. They have a group, then they have a subgroup. Then they have a project and there may be even a mixture of all of these different permutations, in any case, that top level that consolidates all that. That's the workspace, it's important to note that there's really nothing special about that top-level group. It's treated like any other group.

A

It just happens to be at the top, so this is different ways that we can look at it and that's uh when we talk about workspace, the terminology, that's what I want. You to keep in mind when you're, when you're thinking about it. So why are we even working on this workspace initiative?

A

There's really three goals for this project. One is efficiency. The second is parity and the other is accessibility.

A

um It's also a really good time to remind ourselves of our product principle, which is to take pains to avoid instant level features, and the reason is because anything that we developed for the instance level is only available for self-managed users.

A

All our sas users cannot really benefit, from instance, level functionality. So, when we're thinking about it, we need to have a really really good reasoning into why we're developing something in the instance level. We should avoid that in all costs and implement things at the group level, and now I want to talk a little bit about our goals in terms of efficiency.

A

Whenever we develop a feature lab, we duplicate the code more than once. We implement it once for the project level once for the group level, maybe for the subgroup level and then for the instance level.

A

Now we're introducing this new concept of workspace, we're really looking at a namespace. Okay, so the namespace can be a project, it can be a group, it can be a sub subgroup and it can be that top level group, the workspace group.

A

What this allows us to do is when we implement a feature for the nays place level. We only implement it once we do not implement it. Many many many times so it's much more efficient, we have no more duplications, features are released once and we can even remove all those code, duplications that we have from the past from working this way of duplicating the code in terms of parity.

A

We create a consistent experience for sas and self-managed users, and even the the user experience between groups and projects also is a little bit confusing, um and it's something that we hear a lot and user surveys that people don't really understand where they are. There is a difference in the way that feature, because this will eliminate it and, lastly, accessibility. For example, today, in admin view an administrator, a git lab administrator can view and take action on specific functionalities, and no one else can even view those capabilities, not even talking about take taking action.

A

For example, we have a feature: that's called devops score, which we we give a score for an organization based on what devops, implementations and features they use within gitlab, and today only the gitlab administrator can see that no one that doesn't have admin capabilities can't even view that so it's we have these hidden features that no one can really benefit from so making this success accessible for more users will not only increase user adoption, but will also bring those features to the people who need the most, which may not be that administrator.

A

Those are the goals of the workspace project and I want to talk about the migration path, so we talked about the fact that now we want to implement something once at a namespace level and based on the hierarchy. If I'm a project, I'm a from group subgroup. If I'm at top level group that's how the features will change, what we want to do is we want to start migrating features over by features that are missing today from the group level and bring them into that group level. So more people can enjoy it.

A

The next step will be adding the same thing: we're going to start with things that customers explicitly requested next step, we're going to add those missing group functionalities that have not necessarily been requested from customers and, lastly, we'll start removing the code duplications from the code.

A

That is the the general path that we're taking so in terms of the phases of the project. This is a long-term project and we have a lot of different things that we're working on. Some are parallel and some are serial. So I'll talk a little bit about that. Our first phase is migrating groups and projects to the namespace. Now I mentioned workspace is that top level group, but we actually flip the order of the way that we're doing the implementation.

A

What does that mean? It means that, instead of starting from the top level group and and introducing that uh top level namespace view and what we're going to see, we actually started from the foundation. We started the foundation because projects did not belong to namespace. So in order to create a way not to duplicate code, we need to have a core construct that a basic one that can be used by any of these hierarchies and the one that we chose was namespace. So the first phase which we have completed is creating a project.

A

Namespace we've done that and we're now in the phase two of this project, which is backfilling the existing projects into project namespace. um The good news is, we've already finished, backfilling all the projects in gitlab or that's our development project to the project name space. So any new development- that's done is already done in this new namespace concept, which is great um and now we're in phase two, which is replacing core usages of project with project namespace.

A

That is behind the scenes, we're fixing routing, porting and all different things so that everything will work once we're ready to migrate in phase three we're going to start the first migration functionality today, space, the first migration is, is going to be with the planting. The plantain is moving over labels, so now labels will be will exist in the group level.

A

In the project level, labels is actually an interesting one, there's actually six different places in the code where labels exist, and this will make it so that we can only have a single implementation in the code and, lastly, we'll do a cleanup after the plan team uh will finish their migration, where we will create a framework together with them to explain how to migrate features over to this new namespace convention, so that any product manager can pick up their upcoming features and migrate.

A

Their features over in parallel, where we started working on migrating, the features from the admin panel into the group level. So one of the main pains that enterprise customers have, for example, is that they any sas customer doesn't have access to the admin panel. The only people that have access to the admin panel on gitlab.com are git lab team members. What that means that every time they need to do some administrative activity like ban user or unblock a user, they actually have to go through gitlab support team and that it creates inefficiency.

A

So what we want to do is bring all those capabilities up to the group level for group owners or even project owners in general. A namespace owner owns their namespace, so it could be a project. It could be that group. It could be that top level group and they should have full control over their users and groups and so on. So we are now moving over missing functionality to the group level. From the admin panel, we already started with moving view only read-only functionality.

A

So now it looks pretty much the same, and our next step will be moving edit permissions. So in terms of user management, a group owner can add and remove users from their group. um The next step after migrating. The admin panel is implementing that top level namespace, which is um what is that going to look like what is that view that I see today at that top level?

A

Is it going to be any different from the group level? This is all uh being defined next, we want to consolidate and cascade settings and I'll talk a little bit about that in the uh in the next few slides and permissions.

A

So this is all the phases that we need to complete in order to succeed in creating this new workspace concept. So let's talk about about what we're migrating in the admin panel so today, this is how you view and manage users in a namespace. This is the admin panel view, and you can see that we can see um users that you can see the active users. You can see how many admins there are. You can see uh different things that are enabled and disabled within their settings.

A

How many are deactivated, how many are not allocated to projects? In addition, you can see the the name of the person you can see how many projects they they belong to, how many groups, when they were created. Last activity, you can also edit and change their settings in terms of groups.

A

What you can see here is the name of the group. How large it is, how many members there are. Is it public? Is it pro private you and you can edit and delete it? Those capabilities did not appear in the group level.

A

We already started migrating some of the functionality over, but we do want to create parity between the two in terms of cascade settings, which I promised to talk to to talk about what we were planning on doing, and this is very conceptual uh it may change, but the idea is that you can cascade specific settings based on the hierarchy that you are.

A

So if we look at the settings today, you you can imagine we would have this enforced globally option, and that means that you have a permission and you can set it if you check this enforced globally, it cannot be overwritten.

A

If you do not check this, then any namespace beneath it, a project or group- can have a different setting, but we do plan on adding a warning if the setting does not match the higher group, but you can override it. So that's the kind of a general idea of how we want to implement that cascading setting down. This is also really powerful for compliance, because that means you can set something at that top level organizational view and make sure that all the settings are complying with the same set.

A

I showed you what the admin panel looks like for groups and for users. I want to show you what this looks like in terms of a subgroup admin view today, so not really admin, it's a group owner view, but equivalent. So what you see here is, if I am now looking at my groups, I can see my group members and I can see um the source when they were when they were granted access, their max role and expiration, and you can see that this is a little bit different.

A

Going back to what I showed you in the admin panel for users, what you can see is that there's a lot of missing data from what we saw in the group level, because we don't see any data about the groups and projects when they were created uh last activity- and we don't have this edit and settings capabilities.

A

So we plan to create a parity between the two we've already added last activity uh in the last milestone. Last activity is really important for you to know whether or not a user is active. With this information, you can't yet deactivate a user or remove them from your user base, but at least it gives you a notion of how many active users you will and the next iteration will also allow um to deactivate and remove the user from from the base.

A

But this also is related to billing and usage and the ability to view who is using what and whether or not an inactive user is taking up a seat which is going to help a lot of our enterprise customers. Today we have a bunch of missing capabilities between the ability to manage users, which is the biggest pain point for enterprise customers.

A

Some of them are require admin, approval for new signups user cap block, auto created users, either with omnioff or with ldap, the activate user, automatically deactivate dormant users and band users, and we will iterate on adding these slowly. I do want to note that we are planning only to add this capability to provisioned users. A group owner or a namespace owner will not be able to kick you out of gitlab if you're not provisioned. This is specifically for provisioned users in big organizations.

A

If you are a community team member, an open source project, a namespace owner, can remove you from their namespace, but they will not be able to ban or remove you from the entirety of gitlab, so gitlab administrators, they moderate user access by approving, blocking, banning and and or deactivating users, and we want to give them this capability again for provision provisioned users, okay, the the admin area today has a dell dashboard that shows you different information that I imagine that we would want to migrate at one point into this.

A

Namespace view tells you how many users we have in license how many maximum users you have? How many are over and gives you statistics about project users and groups today in the group level? This is the view we have so it kind of is the same information missing the statistics of um the projects and users and groups, but we kind of want to consolidate this to a single experience.

A

And user management, so today, in user management, you can see all these capabilities that we have in the admin panel um active users, administrators. We walk through this and the ability to add new users. We do want to add this capability also to the namespace group owners.

A

Again, there will be a difference between non-provision users and provision users in this aspect again going back to the admin panel today, when you have that edit button that I showed you a few slides ago on a specific user, this is the access that you get. You can see um the name. You can see um how many personal projects there are. You can see um the ability to block or delete, and so on. What we plan to do is add this information for non-provision users, we're going to show any public data and for provision users.

A

We will show the full set of data and the edit capabilities for this specific namespace owner. So going back to the admin panel and our mvc, our nbc is unifying the group's view for admins and group user users we're already midway of doing this. We already completed this. We have the ability to edit and delete this links to that group setting and allows you to remove it already directly from the setting and for users.

A

We have a full plan of iteration, starting with read-only capabilities for listing users um and the ability to search users, and then slowly we will add more active activities like add: remove users blocking users banning users again for provision users for a first iteration. What we're doing is adding the ability to filter enterprise users. We already added a few milestones ago, the enterprise badge which tells you if this is a provision user, now we're adding the capability to filter it so that we can easily identify them and then take actions on. Thank you.

A

If you have any questions, feel free to email me at ogowinski, gitlab.com or slackme. This presentation also contains a list of epics that can be found about all our work in simplifying groups and projects moving the admin panel into the group level, uh consolidating settings and so on. Everything we talked about, there's epics available um on the gitlab.org project feel free to ping me there as well. um I hope this was helpful. See you later.