Pinned projects/subgroups in groups

Description

In some of my groups, I use several projects for common resources needed in all other projects of the group. Usually I have to search for these resource projects every time I need them because other projects are updated more commonly and move them down in the project list.

The current sorting options provide no reliable way of keeping these projects at the top of the list other than creating these resource projects before all other projects and then sorting by "Oldest created".

Proposal

Projects should be able to be pinned (inside groups for example) so that they always appear at the top of the project list. This way, they will always be accessible without searching through the list when they are needed.

The same logic should apply to subgroups as well.

*This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.*

@shad1w Have you tried using the starred view to manage a list of your important projects?

added ~19492 ~65372 ~14213 labels

@markglenfletcher Yes, I'm using that one as well but it is a bit different from what I need.

I'd like to be able to manage these per group and possibly display them in the same list as non-starred projects as well.

Another thing that I can't do is star projects for every member of the group without them doing anything by themselves - for the type of projects I have in mind, it would be extremely beneficial to have them at the top of the list especially for new group members.

GitHub has some organization/user settings that let you pin/star repos for the organization that changes the display for all users, say to pin your most popular project, best work, etc.

@sidewinder12s Is it possible to do this from the GUI? I can't seem to find this in the documentation unfortunately.

@shad1w I was talking about a GitHub feature, not gitlab.

@tauriedavis What do you think about this please?

removed ~65372 label

I would quite love to see this feature too. If you have many small sub-projects it quickly gets messy even. the gitlab org could use it. Something like this (horribly bad) mockup (just prettier):

changed milestone to %11.5

Pre-planned as a ​follow-up after pinned projects on the user profile. We should explore this as part of https://gitlab.com/gitlab-org/gitlab-ce/issues/49979.

We should definitely extend this to subgroups as well.

changed title from Pinned projects in groups to Pinned projects/subgroups in groups

changed the description

Pinning subgroups was also mentioned as an enhancement/extension in https://gitlab.com/gitlab-org/gitlab-ce/issues/49995

mentioned in epic &240 (closed)

I'm updating this milestone to a future. Reason being is that with %11.5 we are introducing pinned projects on personal projects. A Group-related iteration should follow up. We will re-evaluate this issue once we are getting closer to a release cycle planning.

changed milestone to %11.7

added [deprecated] Accepting merge requests label

mentioned in issue ux-research#113 (closed)

added Deliverable backend frontend labels

@jeremy_ I'm moving this to a later release. In %11.7 I'd like to start with Pinned projects on the profile page which is gitlab-ce~2024186.
This one is a natural follow-up.

added to epic &571 (closed)

changed milestone to %12.1

Looking forward to this one We received positive feedback on the mockups for this recently. I think we should add this to groups and projects as well.

changed the description

changed milestone to %12.0

changed milestone to %FY20 Q4

@jeremy disappointed this has been pushed off to %FY20 Q4 why? I am this customer: https://gitlab.my.salesforce.com/00161000010fYg0 we are after this feature.

added groupauthentication and authorization [DEPRECATED] label

changed milestone to %12.7

removed Deliverable label

changed milestone to %12.7

mentioned in issue #33251

https://gitlab.my.salesforce.com/00161000010fYg0 An enterprise customer of more than 1600 ultimate users is interested in this feature.

added customer label

mentioned in issue #36151 (closed)

changed milestone to %Backlog

@jeremy Why is the milestone removed? Can you re-consider this? Thanks!

Thanks for asking. My apologies, since it looks like the %12.7 milestone was accidentally applied about 6 months ago by William.

We haven't been actively prioritizing this; it's not clear to me that this is providing some clear, undeniable business/user value that I can prioritize over other Manage areas.

added groupspaces DEPRECATED label and removed Manage [DEPRECATED] groupauthentication and authorization [DEPRECATED] labels

@Rob-Powell: Would you mind providing some more details on why this is interesting to you? This is definitely something we're interested in, but it feels hard to prioritize over other areas. Would love to hear more about the problem you're facing and to see if we can consider a smaller iteration first.

@tipyn: I've labeled this ~"group::spaces" since this feels like it'll fall to your group.

@jeremy we were looking at this in place of having a group wiki as @jramsay originally advised. Instead of having a group wiki this could be a feature that people could use quickly to find a pinned wiki project that might give them some sort of introduction to the group.

added workflowproblem validation label

Setting ~"group::access" based on ~"Category:Subgroups".

added groupauthentication and authorization [DEPRECATED] label and removed groupspaces DEPRECATED label

@tipyn Can you advise if there is any plan on when we can move out of the backlog? cc @jeremy

@bma: they're no longer at GitLab, this falls under Access and @mushakov. I don't think there's any plan to move this out of the Backlog at the moment.

@bma @jeremy We don't have plans to implement this in the near term.

added sectiondev label

https://gitlab.my.salesforce.com/0016100000NnA27 reached out to express their interest in this feature. Specifically, they're trying to "pin" readme/docs projects within certain subgroups to help them organize and make more-discoverable the service documentation for these subgroups.

another customer here interested in this.

We're currently migrating multiple (20+) gitlab instances from on-prem to SaaS and this will allow us to highlight key projects to our community.

/cc @suhegbu

added 1 deleted label and removed groupauthentication and authorization [DEPRECATED] label

changed the description

mentioned in issue #360271

removed workflowproblem validation label

@mnichols1 This is a related issue: Allow to star groups (and subgroups) (#23576 - closed)

@lohrc - is there a real difference between pinning and starring? If starring already exists in projects, I'm wondering if we should re-use that pattern for groups rather than introducing a new concept. That being the case, I wonder if we should close this issue in favor of &9298, especially since that epic has 55 . Or maybe you and @mnichols1 feel like this is worth preserving as a record of a separate idea/concept?

@ameliabauerly

I think the difference here is users are wanting to pin projects to the group view so they show prominently in the list of projects for that group and it would show for everyone.

vs

Staring is a way for an individual user to make projects show up in their projects list in Your work projects and on their profile.

So yes I think there is a distinct difference in use cases.

@ameliabauerly @mnichols1 I partially agree that these are distinct use cases. Starring is more a bottom-up use case similar to favouriting an item to make it easier to re-access frequently used projects. The nice side effect of starring is that it can indicate popularity to a certain degree, if it is indeed used in that way.

Pinning as described here would be similar to how pinning works in the new navigation. I think this could be achieved by starring, as the use case described in this issue is more about making it easier for an individual user to organize their own workflow. If we would allow users to sort by starred projects and keep that as the default option for them, then pinning would probably not be needed.

However, I think there is a third use case that is more related to showcasing, which would be more of a top-down use case similar to how you can highlight certain posts in Slack by pinning them and thus making them easily accessible to everybody else in that channel. I think that is the one Mike is referring to. We would need to look into whether we want to fulfil all 3 of these use cases, and should probably create a clean vocabulary and definitions around each functionality so as not to confuse one with the other.

Thanks for clarifying. In reading through the comments on this issue, it felt like there was a degree of overlap and I wasn't sure if we needed/wanted both. This helps!

removed [deprecated] Accepting merge requests label

changed epic to &8487

added devopsdata stores grouptenant scale sectioncore platform labels and removed devopsmanage sectiondev + 1 deleted label

mentioned in issue #393775

mentioned in issue gitlab-design#2358 (moved)

mentioned in issue gitlab-design#2404 (moved)

I'm curious if the participants following this issue might have an opinion on a design concept I've been toying with. I've been exploring ways to make it easy to jump into projects that users care about directly from the navigation.

Interestingly, users star between about 5 or 6 projects on average. So to start with a sensible default, I'm showing two concepts for an Administrator that has starred 5 projects they care about. [, , , 🫐, ]

I'd appreciate any feedback on things that work well (or not) and how this would impact your ability to move around GitLab.

Rail	Dock

---

Note: This idea is not going to impact the direction of this issue, but it could inform a future change to a the navigation structure.

@dirk.lachowski you left some feedback here. Let me know if you have additional thoughts to share.

I think having the pinned projects at the bottom of the screen as shown in the Dock concept makes no sense: I assume users would be interested in accessing these more often than the opened project's settings for instance. The top tier of the screen seems therefore more appropriate. I for one would therefore rather see these above the currently opened project's menu, i.e. right below the search.

Also if that pinned projects' section could be expandable, for the (less frequent) scenario where someone needs to pin more than 5 projects, that would be a winner for me.

added 1 deleted label

removed direction label

added workflowvalidation backlog label

added groupglobal search label and removed grouptenant scale [DEPRECATED] label

added devopsfoundations label and removed devopsdata stores label

added devopstenant scale grouporganizations sectioninfrastructure platforms labels and removed devopsfoundations groupglobal search sectioncore platform labels