---
# System prepended metadata

title: Untitled

---

### 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 
![](https://i.imgur.com/e37sKHK.png)

### 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`*

  