### Current Scenario:

- All tags in catalog resources are mapped to categories in Hub. Currently, when new tags are found in catalog, these tags are mapped to category called `Others`.
- Hub needs to check every time and do the maintenance of mapping the tag to categories so that it does not fall under Others.

### Proposed Solution:

- Remove the mapping between Tags and Categories
- Add category in catalog task as annotation. There should be only one category for a task. Multiple categories are not allowed.
- Tags will be used as keywords in Hub
- If category is not added, Catlin should throw an error to add a category
- The category should be added from the predefined category list
- If category doesn't exist then one can raise a PR on hub to add the category and then hub owners can decide whether to add that category or not

### Pros of having categories:
- Grouping of tasks becomes easier
- For e.g. Task for building images can be grouped together to a single category `image-build`
- Creating a more generalized and precised list would make the maintainence more easier by adding it in task manifest

### Reason behind not using Tags only
- Since list of the tags is long hence maintainence would be difficult
- Grouping of tasks w.r.t tags becomes cumbersome
- For e.g. - There can be tags such as `git, github`, etc which would have same meaning but different names, hence filtering won't be efficient
- There can be tasks which has same tags but usecases of both the tasks can be completely different so it affects the grouping
- For e.g. - Consider a tag `build` it can be used with both `golang-build` and `docker-build` i.e. filtering won't be much efficient
- Having just tags will also affect the user experience and hence maintaining that will be not effective in Hbb UI left panel as it will be a long list

### One Category per Task

- This idea was taken from the application such as Operator Hub
- Having one category would precisely group the resources and filtering of resources will be more efficient
- We can have a more precised and generalized list so that they don't mix, the current list mentioned in the TEP is just the sample one
- Or may be we can restrict to two categories like what Github Actions does

### Searching v/s Filtering

- Based on the above proposed solution `categories` and `tags` will be completely independent of each other
- Resources will be *`filterd` only through `categories`*
- Resources will be *`searched` through `name`, `displayName` and `tags as keywords`*