Remove project tags

We have project tags! You can set them in edit project.

As far as I can tell, these are only used on https://gitlab.com/explore/projects. On the RHS there is a tag list:

1. It's huge.
2. It's loaded on page load, which makes the page take 13 seconds.
3. It has a terrible UX.
4. We should kill it.

We removed the counter caches in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9467, but we should probably just kill project tags completely.

https://gitlab.com/gitlab-com/infrastructure/issues/1263

To be clear: we can't remove the tags table, because CI also uses it. But we can remove anywhere we read or set tags for a project.

@smcgivern : Would it be possible to change the feature so that the project tags are loaded only when you click the dropdown button. This would allow the page itself to render more quickly, but still keep the feature (at least for now). And then when there is clear signal/priority to iterate on project tags or deprecate them, we can do so.

Not sure if this extra work would be worth the effort though.

@smcgivern @victorwu I'm going to remove this from the milestone until it's decided we actually want to get rid of this feature entirely.

@mydigitalself Since this is mostly Platform, what do you think? See https://gitlab.com/gitlab-com/infrastructure/issues/1263 for context.

Would it be possible to change the feature so that the project tags are loaded only when you click the dropdown button

@victorwu I like this, since we don't know how many people use this feature. It could be a dropdown with search like the other filters.

To be clear: we can't remove the tags table, because CI also uses it. But we can remove anywhere we read or set tags for a project.

@smcgivern What does CI use it for? Would it be a problem for CI if we could no longer set/change these on any project?

removed Deliverable label

changed milestone to %29

@DouweM CI doesn't use project tags, it tags other things instead. These all use a single shared table

I would rather remove this, and then if we need to build it, build it properly, than deal with the occasional 'the tags table is causing problems' / 'what tags table?' dialogue we have at the moment.

Given how usable the current dropdown is, I think we can take that risk

added ~1222504 label

1. Can we get a sense of % of projects on .com that have actually set tags?
2. I still don't understand the CI position - what exactly does this mean?

CI doesn't use project tags, it tags other things instead. These all use a single shared table

@dblessing are you aware of anyone specifically using this functionality?

@mydigitalself CI uses the tags table for Runner tags. We also use the tags table for Project tags. If we remove the Project tags, we can't just remove the tags table.

mentioned in issue #2978 (closed)

mentioned in commit 3e6d8e91

mentioned in merge request !10242 (merged)

closed via merge request !10242 (merged)

mentioned in commit 8d4f55c2

mentioned in merge request !9682 (merged)

mentioned in issue #36772 (closed)

mentioned in issue #18589 (moved)

@smcgivern this discussion came up https://gitlab.slack.com/archives/C0AR2KW4B/p1504635170000515. Why are we still showing the tags in the project's settings? Should we hide the option?

Edit: So, we apparently use them in the API https://docs.gitlab.com/ee/api/projects.html#edit-project.

mentioned in issue #39045 (closed)

mentioned in issue #24889 (closed)

Given that this has been removed, should we not also remove the tags field in the "edit project" page?

It would really be useful if this feature came back in some form. I have a use case where I would like to organize Gitlab projects, but would like to track more than one primary group/attribute for each project. For example project1 could be a 'data-feed' but also a '.NetApp'.

Alternatively, would it be any easier to expand the use of Labels to include Projects?

The project topics don't have much value now, because projects can't be searched by topic (at least, if this is possible, I can't find out how).

However, it would be useful to my organization if we could do this. So instead of removing the other 50% of the value you used to deliver, how about restoring the 50% you already removed in a way that doesn't cause the problem that triggered its removal? All we need is a way to to find these with advanced search. Surely that should be possible?