Allow creating nested group via UI

added 89 commits

5e3b9e3c...b3201ccf - 89 commits from branch master

Compare with previous version

added 6 commits

b3201ccf...d5411758 - 6 commits from branch master

Compare with previous version

added 1 commit

84247ee6 - Allow creating nested group via UI

Compare with previous version

added 1 commit

4ccdc330 - Allow creating nested group via UI

Compare with previous version

added 1 commit

9204797a - Allow creating nested group via UI

Compare with previous version

marked the task Changelog entry added as completed

mentioned in issue #2772 (closed)

I added some screenshots. Should be ok for first iteration (9.0) but feel free to disagree. cc @tauriedavis @mydigitalself

I added some minor notes to the issue 👌🏽 https://gitlab.com/gitlab-org/gitlab-ce/issues/25426#note_22142785

added 1 commit

b3412782 - Allow creating nested group via UI

Compare with previous version

marked the task All builds are passing as completed

marked the task Added for this feature/bug as completed

marked the task Conform by the merge request performance guides as completed

marked the task Conform by the style guides as completed

marked the task Branch has no merge conflicts with master (if it does - rebase it please) as completed

marked the task Squashed related commits together as completed

@fatihacet please review frontend part

@vsizov please review backend part

I have a few comments and thoughts.

1. Naming

I understand that technically these are sub-groups, but should we call them something else when we announce the feature and in the user interface.

For instance, and I know it comes with some baggage in terms of expectation, but could we call them Teams? That's generally what they will represent.

2. Nesting

Did we previously make the decision to only have one level of subgroup? Personally I'm happy with that.
In the list of subgroups [screenshot])(https://gitlab.com/gitlab-org/gitlab-ce/uploads/1ad579f3a2ac1480a9724f76868add9c/Screenshot_2017-01-26_17.40.55.png) is it really neccessary to have the owner repeated each time? Can it not just list [Marketing], [Design] etc... seems superfluous to list them and also alleviates confusion that they are projects.
What do I see if I click on the actual subgroup in the above screenshot?

Looks good to me 👍

Did we previously make the decision to only have one level of subgroup? Personally I'm happy with that.

I checked out the branch and you ARE able to create sub groups within subgroups currently.

is it really neccessary to have the owner repeated each time?

It gets more important for sub-sub groups: That being said, it will be the same for every subgroup in the list so the duplication may not be necessary. Thoughts @awhildy ?

What do I see if I click on the actual subgroup in the above screenshot?

You are taken to the subgroup page:

should we call them something else when we announce the feature and in the user interface... could we call them Teams?

Hmm Considering you can have sub groups withing sub groups, would it make sense to have teams within teams? Maybe. But as you mention it comes with some expectations - people may also not use sub groups for teams, that is just one possible use case.

@dzaporozhets I didn't test this locally but FE part LGTM 👍

I checked out the branch and you ARE able to create sub groups within subgroups currently.

I understand you get even deeper flexibility with this, but wanted to question if it was necessary, do we really anticipate subsubgroups getting used much at all - and does it's existence complicate things?

I'm just mildly concerned that by having the functionality, we always have to consider it in the UI. For instance the breadcrumb style Group / Project navigation in the top-left, any reference to a project, all of a sudden could become cumbersomely long. People may also get lost in the depth of the groups.

I do also think it helps with naming and is another reason I'm quite keen on giving it a different name. For instance, if we call them subgroups everywhere, then currently we don't call them subgroups on the primary nav label on the subgroup page per below and perhaps elsewhere it's referenced?

.

Sorry to bang on about this, but we can only get this right once.

Don't apologize! These are great to bring up. I agree that I'm not sure you should be able to create sub groups of sub groups. @dzaporozhets was this discussed while working on nested groups?

The navigation of the (sub)group is an interesting challenge. Calling it a Subgroup there could lead to confusion since there is also a Subgroups tab below for the subgroups of the subgroups. Maybe this would be eliminated if we decide not to do more than one level of nested groups - I also would be happy with this.

@awhildy Do you have any thoughts? I do think that having multiple levels of sub groups quickly escalates complexity with the UI.

Good discussions! My initial thought is that if we are truly targeting Large and Strategic customers (https://about.gitlab.com/handbook/sales/#market-segmentation), multiple levels of subgroups is helpful. These orgs get large, and different information/work is helpful to scope at different levels.

At this point, I kind of feel like we are treating groups like folders on a file system. There are really just two concepts, files and folders. But you can have folders inside of folders inside of folders. Would it make sense to just consider this as two concepts here, groups and projects? But you can have groups inside of groups inside of groups, with projects at each level? The breadcrumb could get large, but what other complexity is added?

@awhildy the parent issue has some more background where the folder-type structure is discussed.

There are a few areas of the user interface I can think of that do start to get a little messy when you have multiple levels.

Top-left breadcrumb
The group's project page as it (currently) has the fully qualified path to each project
My project page
Cross-project issue mentions become long

If you look back to the original post, every example people give of how they might use it is:

Group / group / project

With the exception of Unity Linux, who wanted:

Group / category / section / project

but also stated

However, I'd settle for just being able to have the existing groups inside of a Unity Linux organization group

So are we really giving people what they want, or what we think they want without a huge amount of input - has anybody actually gone out to one of the big customers and asked them what they want?

I'm also thinking if there's additional feature debt we inherit from having n levels of nesting. Every time we design something that touches this area, we need to think of how many levels of nesting is entailed. Every time we code something in this area, we may have regressions due to unforeseen URL fragment length or URL mapping & lookup issues.

We did this at Gitter where we introduced sub-rooms because a couple of large organisations "wanted them", they were used by less than 1% of our userbase and were a complete pain for us, sometimes our users created rooms inside the wrong room because they got lost in the UI and supporting them whenever we wanted to do work in and around that area of code because a huge amount of pain. Eventually, we bit the bullet and dropped support for them and nobody noticed.

With the exception of Unity Linux, who wanted:

I take that back, this comment also mentioned wanting multiple levels.

https://gitlab.com/gitlab-org/gitlab-ce/issues/2772#note_4565528

Maybe this would be eliminated if we decide not to do more than one level of nested groups

@mydigitalself @tauriedavis @awhildy we are doing more than one level of subgroups. With this feature I want big projects with deep nesting (for example Android https://android.googlesource.com/) be able to be stored in GitLab. Please use this as starting point for possible UI/UX improvements and use cases. We can put some limit on nesting (lets say level 5 or level 6) just to avoid overuse.

So are we really giving people what they want, or what we think they want without a huge amount of input - has anybody actually gone out to one of the big customers and asked them what they want?

It sounds like EE approach while we are doing CE change here which should be useful for anyone. Ex. you are a single developer who has own project with micro service architecture and use nested groups for storing separate components. So I recommend we start think about feature as something we are going to use ourselves and then iterate on user feedback once released.

@dzaporozhets good points. I think it's a case of getting ones head around the terminology.

At least in my opinion, Group has some sort of organisational baggage where it's generally about people - whereas the structure that you've created allows you to not only organise as such, but also by project hierarchy. My opinion is probably skewed because I'm coming from a GitHub environment, but others will too.

So I'd just like to ask again, if we think that subgroup is the correct terminology, given the potential implication that groups already come with. Given your use case, I'm more inclined to think it's fine, but just wanted to consider if we should look at any alternatives. With what you've outlined, Team is certainly incorrect.

@mydigitalself few thought about naming:

Groups are about both projects and people.
We used Group term since beginning -> no problem so far.
Subgroups behave like groups -> you can add people to it.
We can rename Subgroups to something better but it might be even more confusing since it loose benefit of what people already know about Group.

@dzaporozhets I'm not proposing we change the term Groups - it's only the term "subgroup" that I'm a little concerned about.

But just thought it over a little more over a nice cup of tea, and perhaps another area to look at (and maybe not now, but in future releases) is the subgroup page.

In the Android example you gave above, you pretty much navigate those projects/sub-projects/groups-sub-groups :) like a directory. The current subgroup page gives a lot of affordance at the top for the logo etc... should we look at perhaps:

a) only navigating in the area below the tabs?
b) having the subgroup page look a bit less like the group page - maybe less visual affordance to the logo and name and more about the contents?

As a side point, but fairly related, does the subgroup avatar inherit from the group, or is it a ? icon as below:

only navigating in the area below the tabs?

@mydigitalself what do you mean?

having the subgroup page look a bit less like the group page - maybe less visual affordance to the logo and name and more about the contents?

@mydigitalself maybe. Lets see what @tauriedavis can propose.

As a side point, but fairly related, does the subgroup avatar inherit from the group, or is it a ? icon as below:

subgroup has own avatar. Subgroup is own uniq group, it just has parent on top.

added 760 commits

b3412782...da359c46 - 759 commits from branch master
62f13bae - Allow creating nested group via UI

Compare with previous version

added 1 commit

7b353411 - Allow creating nested group via UI

Compare with previous version

added 1 commit

f39dbf3d - Allow creating nested group via UI

Compare with previous version

resolved all discussions

merged

mentioned in commit 059d1ae4

added subgroups label

Allow creating nested group via UI

What does this MR do?

Are there points in the code the reviewer needs to double check?

Why was this MR needed?

Screenshots (if relevant)

Does this MR meet the acceptance criteria?

What are the relevant issue numbers?

Activity

Admin message

Admin message

Allow creating nested group via UI

What does this MR do?

Are there points in the code the reviewer needs to double check?

Why was this MR needed?

Screenshots (if relevant)

Does this MR meet the acceptance criteria?

What are the relevant issue numbers?

Merge request reports

Activity