Taskwarrior: [TW-1784] Deprecation of project: in favor of tags

[taskwarrior]

_Renato Alves on 2016-03-19T21:09:52Z says:_

Some time ago I started using tags as if they were projects.
This made sense once the same task crossed more than one project.

Since then I've been ignoring most of the project: centered functionality.
I also realized that tags can effectively act as a superset of project: without any loss of information. Currently there's some loss of functionality (e.g. task summary) but this could change in a future version.

With that said I propose deprecation of project: in favor of tags.

A non exhaustive list of pros/cons:

Advantages:

• task project would go away or simply alias to task tags
• simpler filtering syntax for tags +proj, -proj or +p_foo (or whatever the user chooses)
• remove "special" status of project: . Generalize the concept of project
• single task can belong to multiple "projects"

Disadvantages:

• Partially matching a tag is currently buggy: task tag.startswith:foo (only matches tasks that have the first added tag starting with foo, not all tasks containing a tag starting with foo). Alternative: task tag.has:foo.
• Sub-projects have loose hierarchy (by using individual tags): proj:this.that.theother becomes +this +that +theother.

Neutral (arguable):

• task summary currently acts on projects. It could be changed to use tags instead of projects.
• Other project centered features could migrate to use tags instead.

What are your thoughts on this?

[taskwarrior]

Migrated metadata:

Created: 2016-03-19T21:09:52Z
Modified: 2016-03-21T16:27:49Z

[taskwarrior]

_Paul Beckingham on 2016-03-20T12:04:32Z says:_

That's really interesting. Multiple projects is a really attractive feature. I agree with everything you said, but one thing seems problematic: sorting.

The rest are all details that we can overcome, and improving attribute modifiers for tags would be a good idea anyway, but sorting on tags is not good right now - it sorts on the raw string ("tag1,tag2"), which makes the first tag important, and I'd rather not add support for reordering tags. Any thoughts on sorting?

We could also make the current project available as a virtual tag, something like PROJECT_Foo, and keep project around for those who want to sort on it. But that sounds more like a horrible hack.

[taskwarrior]

_Renato Alves on 2016-03-20T13:46:06Z says:_

I'm not sure if I didn't miss the core of the problem but if I understand your concerns, the problem goes all the way to the format used to store the information on .data files.

Would it perhaps be appropriate to implement a set storage model? (implicitly unsorted and duplicate not allowed)

It would also make for a clear separation of entities and code when applying filters such as .has: and .hasnt:. Addressing TW-1262 along the way.

Before (indented for clarity):

[
    depends:"b874d9af-aa0d-4a7a-bd02-4b67c75b05c3,5845ab48-d9e4-4f64-820e-d8e02df56ee6"
    description:"one"
    entry:"1458480489"
    modified:"1458480518"
    status:"pending"
    tags:"tag1,tag2"
    uuid:"ff02a60f-eb78-44b1-a4e8-df86e9c43a1b"
]

After (indented for clarity):

[
    depends:{
        "b874d9af-aa0d-4a7a-bd02-4b67c75b05c3",
        "5845ab48-d9e4-4f64-820e-d8e02df56ee6"
    }
    description:"one"
    entry:"1458480489"
    modified:"1458480518"
    status:"pending"
    tags:{
        "tag1",
        "tag2"
    }
    uuid:"ff02a60f-eb78-44b1-a4e8-df86e9c43a1b"
]

---

Ok I might have missed the point indeed. Were you referring to sorting of tasks on the report?

Such that if two tasks have project:this and project:this.that which converts to +this and +this +that causing:

id desc tags
2  two  that this
1  one  this

---

Actually :) what do you mean by sorting? I'm seeing more than one "sorting" problem.

[taskwarrior]

_Paul Beckingham on 2016-03-20T13:54:50Z says:_

We can achieve that without changing the file format. All it would need is a Column::thisAttributeContainsAList flag, and some if statements. The set semantics you refer to are already implemented, but the attribute modifiers don't distinguish sets from strings.

But that's not my main concern, which is sorting. If project:A.B (where B is a subproject of A) is now effectively +A +B, then I can filter on +A or +B and that's a huge improvement, but sorting goes out the window. Perhaps it doesn't matter. Thinking...

[taskwarrior]

_Renato Alves on 2016-03-20T14:10:09Z says:_

Indeed. In my case I've mostly ignored this.
I haven't been using "project hierarchy" that much. I just tag and filter on the things I need. But this might be an issue for a lot of users.

I imagine people could use complex tags +this +this.that but this seems convoluted.

[taskwarrior]

_Tomas Babej on 2016-03-20T18:47:41Z says:_

This is purely opinionated comment: Projects and tags are a different concept in my mind. In my workflow, while projects are structured and hierarchical, tags are used for non-structured metadata. In my current setup, mixing tags and projects would make the whole thing more messy.

The lack of hierarchy with multiple tags used as subprojects would be a deal breaker for me here.

[taskwarrior]

_Frédéric Meynadier on 2016-03-21T14:12:50Z says:_

(Mmh, didn't see a discussion had started on this subject yesterday when I posted my message this morning...)

Following discussion on https://groups.google.com/forum/#!topic/taskwarrior-dev/4dtqyJc7P9k : projects gives a way to report tasks once and only once. In the context the "timew" project, this allows to make sure time is not accounted twice, which may be of paramount importance in the case of billing. I don't think it would be as easy to ensure it with special rules on tags.

• 
  
  • 
    
    Frédéric
  
  

[taskwarrior]

_Renato Alves on 2016-03-21T16:27:49Z says:_

Thanks for the info Frédéric. I heard from Paul that he was working on a time tracking tool. Glad to hear it's out.

As for project: it looks like it's going to be hard to deprecate it.
Given that timewarrior currently works on the basis of tags, maybe we'll see some taskwarrior features getting close to it for easier coupling.
I'll leave this open in case someone has any ideas on how to address the problems mentioned.

Thanks,
Renato

[clawoflight]

I really like the progress information in task summary.
It could be changed to work on tags, but given the nature of those, I really don't want to see progress for all tags... So some tags would need to be marked so only they show up, and then we're back to projects.
Also fully agree with Tomas and others.

So I would say, please leave projects in, people who don't need them don't have too :)

[slmeyer]

Having many tasks, I do not see usability without a possibility to create hierarchical structure like in projects, so I favour keeping projects