I have subscribed to some of Gitlabs labels, because I'm getting a lot of emails I wish to unsubscribe from some of the labels, the problem occurs when I go to issues/labels there is 5 pages of labels which are ordered by name ascending, and it is really hard for me to find labels to which I'm subscribed, especially since there is a bug which shows same icon for subscribed and unsubscribed labels :)
Proposal
I have few different propositions (order by most likeable IMHO )
Add sub navigation same as in Repository link for example, where you could have 2 nav sub links (Subscribe, Unsubscribed)
Order labels by subscription where I see subscribed labels first
Add ability to filter labels by subscription
Set background color to subscribed row that is different
IMO all of those propositions are solving the problem :)
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
I like this idea. I think we should just add Subscribed labels under the Prioritized labels section and before the Other labels section. The subscribed labels can behave just like the prioritized labels, when you subscribe they're added to that list, when you unsubscribe they're added to the other labels list.
Thanks @lbennett for jumping on this. It's an important problem to solve, but like you alluded to, it's not priority at all. Thanks for managing it yourself!
Thanks for pinging @cperessini in the merge request. Chris: Please give some feedback on the design. This seems like a logical next iteration of the exiting labels UI. But obviously we should be aware of any impact to other areas and existing plans. For example, the labels page looks different from issues, merge requests, milestones, and even snippets. @awhildy : Do we have a clear direction how / when we want to harmonize these different views? Would we want the labels page to be similar to issues in the future so that we can do better filtering / sorting on multiple attributes?
We should add the ability to filter/sort labels. It has been brought up a few times. (https://gitlab.com/gitlab-org/gitlab-ce/issues/14520, https://gitlab.com/gitlab-org/gitlab-ce/issues/27031 as some of what I'm aware of). I think we get the most bang for the buck by simple name filtering for labels. If we can do that, and improve the overall performance of the label page, we probably solve a lot of the struggles people have. Adding the capability to to filter by subscribed/unsubscribed labels, maybe project/group level, prioritized/not prioritized, etc. would be a nice thing to add after we get basic name filter.
All that being said, I think focusing on making issues and MR search awesome is still a bit higher priority for me than some of this additional filtering capability for labels. (Mainly considering the average number of issues/mrs projects have vs. labels)
GitLab is moving all development for both GitLab Community Edition
and Enterprise Edition into a single codebase. The current
gitlab-ce repository will become a read-only mirror, without any
proprietary code. All development is moved to the current
gitlab-ee repository, which we will rename to just gitlab in the
coming weeks. As part of this migration, issues will be moved to the
current gitlab-ee project.
If you have any questions about all of this, please ask them in our
dedicated FAQ issue.
Using "gitlab" and "gitlab-ce" would be confusing, so we decided to
rename gitlab-ce to gitlab-foss to make the purpose of this FOSS
repository more clear
I created a merge requests for CE, and this got closed. What do I
need to do?
Everything in the ee/ directory is proprietary. Everything else is
free and open source software. If your merge request does not change
anything in the ee/ directory, the process of contributing changes
is the same as when using the gitlab-ce repository.
Will you accept merge requests on the gitlab-ce/gitlab-foss project
after it has been renamed?
No. Merge requests submitted to this project will be closed automatically.
Will I still be able to view old issues and merge requests in
gitlab-ce/gitlab-foss?
Yes.
How will this affect users of GitLab CE using Omnibus?
No changes will be necessary, as the packages built remain the same.
How will this affect users of GitLab CE that build from source?
Once the project has been renamed, you will need to change your Git
remotes to use this new URL. GitLab will take care of redirecting Git
operations so there is no hard deadline, but we recommend doing this
as soon as the projects have been renamed.
Where can I see a timeline of the remaining steps?