Add hierarchic properties to tags (Feature Request)

[seamustuohy]

Feature:

Make Tags hierarchical in the same way that projects are.

In my use case I use tags for tracking and the teams I work with and the type of work I do. For teams this allows me to quickly review my upcoming and historic activities with another team. I track the type of work so I can see how much time I am spending developing vs. time spend in meetings.

Hierarchy would be a welcome addition for the following reasons.

• Since some of the team names are also the same as other tasks I need to nest them under a tag "heading" I need to be able to nest team names under a sub-heading in my tag. For example while I have a development team I also have tasks which are tagged development because they are development tasks. So, I have two tags team.dev and dev.
• I work with sub-teams (i.e. team.it, has team.it.systems, team.it.networking, team.it.helpdesk, etc.) but want to be able to query for all work with team.it including those sub-teams. Currently this requires searching for all possible sub-teams. I would like to be able to just search for team.it and get all the underlying tasks

For example, If I had the following two tasks.

ID  Age   Deps Project              Tag                     Due   Description                        Urg
1    2d        website.frontend    team.it team.design             Web Host Move Meeting    10.8
2    1d        training            team.it.helpdesk meeting        Security Training        14.2

With only the few IT subteams mentioned above it becomes quite complex to filter for the tasks that I want. If I want to create a report of all my upcoming tasks with the IT team I currently have to search in the following way.

task +team.it or +team.it.helpdesk or +team.it.systems or +team.it.networking

Adding hierarchy would change this search into the following search.

task +team.it

Supporting this use-case will open up opportunities for taskwarrior to be easily used to track and report on more than simply what tasks were completed. It will allow easy categorization and reporting on how those tasks were completed, with whom they were completed, or any range of other contextual tracking that a user may desire.

[ChargingBulle]

Oh wait, this isn't a feature yet? To me it seemed absolutely in line with TWs philosophy.

My use case for this: I have different people to talk to and I don't want to disturb them throuout the day. I write down all the things I want to tell them and then once a day meet them or send an aggregated mail (This concept of an Agenda List).

With hirarchical tags this would be: Agenda.Alice, Agenda.Bob, ... I can't model this with projects because maybe I want to speak with them about a Project.

[ghost]

Please don't implement this feature request. The whole point of tags in general (i.e. not just in TaskWarrior), as a classification mechanism, is that they are non-hierarchical.

Instead, please fix https://github.com/GothenburgBitFactory/taskwarrior/issues/1720 . If that issue is fixed, then people will be able to filter for tags that begin with a common string. E.g. to filter for tags that begin team.it, users would run:

task 'tags~(^|\s+)team\.it'

Alternatively (or additionally), please change the tags attribute's startswith attribute modifier so that it attempts to match against the start of each tag, rather than its current behaviour (which is to attempt to match the start of a string composed of all of the task's tags in alphabetical order separated by spaces). This way, people would be able to to filter for tags that begin team.it, by running:

task tags.startswith:team.it

Thank you.

[ChargingBulle]

I understand your point. It's hard to guess what the user expects here. Should things with the tag home.kitchen.sink appear when filtering +home?

Given that context exists I'd say: no. But I can see good reasons to filter like that sometimes. To me tags.startswith: seems very verbose. Even when one can leave out the latter parts of the instruction. A home.* or home+ feels more appropriate.

I also have to draw back my example with Agenda Lists. One can much more cleanly implement agenda lists via different means (right now I have a report which groups by person ; other ways of displaying this information are very possible)

[ghost]

@JonasDralle wrote:

Should things with the tag home.kitchen.sink appear when filtering +home?

No, they should not, because home.kitchen.sink is not the same tag as home.

To me tags.startswith: seems very verbose. Even when one can leave out the latter parts of the instruction. A home.* or home+ feels more appropriate.

Syntactic sugar is a matter of taste. Please can we wait until tags.startswith: at least works as I described above, before we start suggesting alternative syntaxes for invoking it?

[sewe]

Let me just add another use case (for which projects seem the wrong tool, as “Reading” isn’t some project that is ever finsihed):

Tags like reading.fiction and reading.nonfiction. Contrary to @sampablokuper above I would hence argue that a filter like +reading should match both reading.fiction and reading.nonfiction, to satisfy my query for anything to read. This would also be consistent with how projects are matched.

But I do agree with @sampablokuper in that syntactic sugar can come later if the necessary machinery is already available under the hood to emulate the desired behavior.

Alas, the set-like nature of tags does cause some headaches which do not exist with the single-valued project. How many tags does task 1 have after executing these two commands?

task add "Read _War and Peace" +reading
task 1 modify +reading.fiction