Add status DOING

[Quorafind]

I don't know if it is doable that make DOING available.

I have a idea like this:

And then when I click on the red DOING it will change to TODO like above one.

[Quorafind]

And when I check on it, the DOING or TODO will change to DONE

[schemar]

Definitely another status. I am also thinking about DELEGATED, SKIPPED, or OBSOLETE. Though please note that I don't have that much time. So it will be a while until we get more statuses besides TODO and DONE, unless I get help 😉

[chrisjterrell]

Maybe a simpler and more dynamic solution is would be to add a text box that pulled in tag(s). Then we could use whatever tag was appropriate to our way of managing tags.

[Cito]

Another important status would be WAITING to support GTD's waiting for list.

[claremacrae]

Feedback needed

I am looking at implementing this. I am a long way through the implementation and would like to make some decisions fairly soon in order to make a test build available.

I would really appreciate comments and feedback on the below, as a minimal first release of this facility

Proposal

I am thinking that what I will call status is entirely determined by the character between [ and ].

This is consistent with TODO being a space - and DONE being x.

So this means assigning some default characters to use in [] for the new states.

I've been using SlRvb's Alternate Checkboxes.

Here's what I've got so far:

Proposed New statuses, and the characters to indicate them:

• DOING [/], [d]
• DELEGATED Need ideas!
• CANCELLED [-]
• SKIPPED - I think that CANCELLED is better and am not proposing to use SKIPPED - unless someone things it is useful for skipping a recurring task
• OBSOLETE Need ideas!
• WAITING Need ideas!

Existing

• TODO [ ], [!]
• DONE [x], [X]

Maybe also add

• NONE
  • Means 'ignored by Tasks'
  • That would be used for any characters not in the list above.

In a later release, users may initially be able to customise the assignments, but initially it would be hard-coded.

Ideas for commands

• Quick Reference | Obsidian Tasks

done
not done

sort by status (done or todo, currently)
group by status
status is doing
status is not doing
status is cancelled
status is not cancelled
etc

checkbox is ?
checkbox is !
checkbox is not !
etc

[siddhantac]

Thanks again @claremacrae for working on this!

Proposed statuses and characters

I'm suggesting characters based on the Minimal theme which comes with its own css for alternative checkboxes since that's what I am using. There is some overlap with SlRvb's Alternate Checkboxes but it's not a 1 to 1 mapping.

• DELEGATED : [>] (forwarded), shows a right-arrow like icon.
• OBSOLETE: I think this is similar enough to CANCELLED to not warrant a separate status. But if you want to go with it, you could perhaps use [c] (stands for cons).
• WAITING: [<] (scheduled), shows a calendar icon

For NONE, I recommend using a specific character. It will allow queries to be generous and pick up as many tasks as possible except the ones identified as to-be-ignored. The opposite (ignoring all checkboxes which have an unrecognised character) seems restrictive and goes against how Tasks works today (shows icons as-is if it is not [x] or [ ]).

Alternate idea

Have you considered the idea of making this generic so that you don't have to deal with all these statuses (I expect there will be requests to add more in the future)?

What if there are only 3 statuses:

• TODO
• DONE
• NOT TODO AND NOT DONE (needs a shorter name, it's a working title for now)

The third status is a catch-all for all other statuses. This would simplify the queries since only the checkbox is ?style queries would need to be recognised. The status is doing-style queries can be completely done away with.

I am only somewhat familiar with the codebase so this might be a silly idea, but I thought it's worth mentioning.

By the way, I really like the checkbox is style queries! Opens up many possibilities for extension!

[claremacrae]

Have you considered the idea of making this generic so that you don't have to deal with all these statuses (I expect there will be requests to add more in the future)?

Funnily enough, that was what I was using until someone put in a PR to add DOING :-) #1413

NOT TODO AND NOT DONE (needs a shorter name, it's a working title for now)

For searches to make sense, NOT TODO must be the logical opposite of TODO... It can't be a state on its own.

I think the reason for having a few named custom states will become clear when users eventually have the ability to customise all of this.

One user might be using a custom checkbox CSS that displays n (say) as a TODO state
And another might be using CSS that says n is done.

They are not consistent.

So by being able to write searches in terms of TODO, DONE, CANCELLED etc - and allowing users to modify the mapping of checkbox characters to the statuses, it will turn in to rather a powerful system.

In the first version there won't be customisation - which is why all my concerns currently are about the initial hard-coded version. But I just need to make sure I will be able to extend the first version later.

[aubreyz]

My vote: Definitely no emojis
DOING [/], [d] is good
DELEGATED >
CANCELLED [-]
WAITING Need ideas! <

I would add [1] [n] = do next (IE the thing after the [/])

Sort order /d,1n,[ ],>,<

But better overall : why not just /123><
User could use multiple of each number but essentially a manual sort order
For doing now next stuff and awaiting stuff

[aubreyz]

An order is sort of a state
/ = State of doing now
12345= state of pending with added bonus of order pending
< or > = state of not doing now or pending until something happens

[claremacrae]

No sorry, that is mixing concepts and will be a confusion for users and maintainers.

I’m not going to slip in a sticking plaster/bandaid pretending to be in dependencies.

If you want to propose a state of PENDING or BLOCKED or something that’s fine.

But absolutely not an independent thing that conveys order.

[claremacrae]

If we were to put an order in state and later add dependencies, the sorting code will have THREE places to go to, to determine order of tasks. It would be a nightmare. Not negotiable! 😃

[aubreyz]

OK, how about just [n] then for next. Next is the state of being the next thing to do after the / doing is done.

To digress I think this is the gap in a lot of todo systems -- You get presented at the start of the day with a large collection of stuff that could potentially get done. You need to plan what you are actually going to do, and unless you want to mess around with the task descriptors (dates, tags and so on being part of that) - the only way to do it is to grab a bit of paper.

Not to be irritating :) but I think this is different to a dependency. I am sitting here with a bunch of tasks in different categories (maybe grouped by tags) that I could do today. I need to plan what I am going to do in the next shot (/) and what I am going to do after that.
A dependency simply means that I can't do something until something else is done -- it doesn't mean that I actually plan to do it now or next (something akin to looking at your todo list and scribbling on a piece of paper what I am going to do before lunch). Actually planning to do something as part of my day is a state. The rest of the stuff just gets left because as we all know having a concept of todos that elevates clearing out of lists is a bad way to go about your life.

[claremacrae]

Thank you very much - I really appreciate the time and thought you're giving this. I will ponder these suggestions.

[alwaysblank]

Thanks for working on this! This will be a really cool feature for an already awesome plugin.

• OBSOLETE: I agree w/ @siddhantac that this just seems like "CANCELLED" with extra steps and could probably be skipped for an MVP.
• WAITING: Could this be changed to BLOCKED? To me, "blocked" communicates the unique status more clearly (and would more clearly tie into any eventual task dependency resolution query logic). "Waiting" (based on the comment that recommended it) is language specific to a task management system, but outside of that system I feel like its meaning is ambiguous in the context of task status. For a character, I'd suggest [.] (a shortened form of an ellipses, commonly used to indicate a pause or wait) or [|] (blocked by a "wall" 😉).
• NONE: Again I agree w/ @siddhantac—I think having a "none" status to query against would be very useful in certain use cases (i.e. I want to use the ability to toggle styles based on check-box status, but I don't want to pollute my global task list) but should potentially be tied to a specific character. For a character, I'd suggested [n] or maybe [_].

[erauner12]

providing a dataviewjs query here for context:

get all tasks that you are waiting on:

dv.taskList(dv.pages('"Inbox"').file.tasks .where(t => !t.completed && t.status == "|") )

[adam-wood]

Not much new here, but posting some confirmation
DOING [/]
CANCELLED [-]

NONE - I agree with @siddhantac & @alwaysblank , I think it could be best to have something explicit/specific to avoid unexpected search results. I think this could be useful. [n] or [] both seem suitable. I have a preference for [] as it avoids English bias.

OBSOLETE - I agree with @siddhantac & @alwaysblank , for an MVP this could be same as cancelled. I don't have a use case to distinguish.

WAITING [.] works for me, like @alwaysblank

Separately, until you allow customization, I think it best to only have one possible character per status.

Also if you do allow customisation, this could create unexpected behaviour if people share lists via copy-paste or possibly sync. Eg [.] might be 'In Progress' for me and 'done' for someone else.

I came here to check to see if I could configure toggle to cycle through [ ] → [x] → [-], so would love to have this functionality. However I can immediately see different people wanting to deactivate / activate / re-order different statuses from the toggle order.

[claremacrae]

@adam-wood Thanks for a very helpful reply.

Also if you do allow customisation, this could create unexpected behaviour if people share lists via copy-paste or possibly sync. Eg [.] might be 'In Progress' for me and 'done' for someone else.

I think from the replies so far there are already inconsistencies between the different commonly used custom checkbox snippets, so inconsistency is inevitable.

[claremacrae]

Just to say that I haven't forgotten this.

My conclusion from the above comments is that there are too many differences between the letters used for different themes and snippets to come up with a search mechanism that won't require people to rewrite their queries once a version that supports customisation is available.

It's like I've got all the components in bits on the garage floor and I'm trying to work out how to assemble them all in a way that I have confidence that I've not introduced bugs along the way.

[siddhantac]

Thank you @claremacrae ! I can help with development and/or help with testing an alpha/beta version.

[claremacrae]

Thank you @siddhantac. I will definitely take you up on that.

I made a lot of progress today. There's still a long way to go, but now I'm confident I can make something really very good out of this, thanks almost entirely to a lot of previous work by @sytone on his fork. (I'm giving him full credit in the commits that pull in his work. He shows up a co-author in the history.)

I've now got the parsing, filtering, toggling and rendering code refactored so that all the current behaviours are implemented using sytone's new Status storage classes.

So the current code in Tasks now is basically a massive - and very safe - refactor in Tasks, along with extra tests I added to the code I've pulled in. My new tests found the source of 2 or 3 bugs I'd discovered when exploratory-testing the fork - and so I've been able to fix those issues in the Tasks code.

(@sytone - do let me know if you would like me to create PRs in your fork for the things I fixed, if you would be likely to use them... I'd be pleased to contribute back.)

I've probably got another half day of testing the above - and then it's on to the interesting stuff, of pulling in the code that allows users to customise the available states, and easily edit the states of particular tasks (via the modal and via new commands).

There then still needs to be some thought on how to update the search filters.

[sytone]

I have had zero time to touch my fork with work commitments. I am using it as is for the moment until I had time to work out how to effectively port back but looks like you have just done a large chunk of that which is awesome.

[danrfletcher]

As an ex-ClickUp user, what I found very useful was the set of default workflow processes with the ability for the user to add their own statuses, order them & then choose which workflow process to use for a particular task

Task Status UI in ClickUp

What I think would make this feature great is the following:

User able to create their own task statuses.

As a task user, I want to create my own task statuses so that I can customise the workflow process that I use. This would be useful for implementing scrum &/or other product/project management frameworks in Obsidian. It would be great to get SlRvb's Alternate checkboxes by default & from the UI, be able to create new statuses & assign to emojis/icos as required.

This would require the ability to map multiple statuses to 'To Do' & 'Done'
For example, done for the scrum example below is Done [x] > ✅ & for the books example is Read [x] > 📚. Both use [x] but are represented by different icons.

Open for the scrum example is Open [ ] & for books is To Read [ ] > 📕. Both map to [ ] but represented by different emojis.

User able to create custom workflow processes.

As a task user, I want to use my custom statuses to create custom workflow processes so that I can manage a diverse set of processes in Obsidian. For example, I may track a set of books I have read in Obsidian, creating the following statuses & ordering them into the following workflow process

1. To Read [ ] > 📕
2. Reading [rg] > 📖
3. Read [x] > 📚

I may then also be working on a project in Obsidian using scrum so could create the following to track that:

1. Open [ ]
2. Pending [p]
3. In Progress [d]
4. In Review [r]
5. Blocked [b]
6. Done [x] > ✅

User able to assign the workflow process for a particular note via YAML.

When using multiple workflow processes, it would be necessary to have a way to distinguish which applies to which note via frontmatter i.e.

---

workflow: 'Scrum' #Assignes scrum workflow to this note.

[claremacrae]

Hi @danrfletcher, thanks for the write-up.

ClickUp

I used ClickUp for a year or so, and paid for it. For the avoidance of doubt, Tasks - with one main contributor - is never going to try and compete with something the size of ClickUp even before they got silly amounts of capital.

What's coming in next Tasks version

Having said that, for most of the last week I have been working on implementing custom statuses. It's going well - there is a lot of work still to do.

I expect the next Tasks release will offer most of what you are requesting:

• New standard statuses, including DOING (which is the subject of this ticket)
• Ability to create custom statuses, where in each one:
  • you chose the character between the [],
  • and give it a name - it must be a single character, note.
  • and you specify the next status character to use in the chain

These will be saved in global user settings, not customisable per file in YAML.

(which won't be surprising, given that Tasks does yet not read YAML frontmatter at all, so that is a whole separate body of work)

How global custom workflows will be definable in the next Tasks

In my experiments with the new features, I have effectively set up several different workflows already, via things like:

• P -> C -> C
  • Pro -> Con -> Pro
• ! -> d -> X -> !
  • Important -> Doing (Important) -> Done (Important) -> Important

In effect, I then chose a workflow by my choice of the first character on the task

The scope of issues

Nothing personal but...

When I first took over Tasks, I struggled with the number of tickets that seem to be requesting one particular specific change, but then on further reading other users have come along and made additional requests, widening the goalposts considerably from the initial point.

It's pretty demotivating to do the original request and then not be able to close it because there's half a dozen extra things requested - and also you've no way to track what remains.

So I've come to the realisation that each ticket represents the thing initially requested, and will be closed once its request is done (or earlier, if it is not going to be done.)

So once I have implemented and released DOING, this ticket will be closed.

YAML - please create a separate feature request.

Therefore, if you still feel it's important, please feel free to create a new issue that makes the case for putting customer per-note workflows (or however you described it) in a separate feature request.

It doesn't need to make the case for custom statuses and global workflows.

But it would be helpful to know why global chains of status could not satisfy your needs, given the extra complexity that per-file workflows would incur, on coding, documentation and maintenance.

[sytone]

You could create a project and then make a issue per feature requested or bug and then just have it on the board. It would mean the creation of issues from a discussion but it may help with overload and planning. Issues in GitHub are just work items with a poor name. :)

That way you can control the only one item per feature request and not have the issue of discussions breaking out to multiple ideas and trying to track them all in one discussion which can be overwhelming. Also makes it clear to see what is on the backlog of work for others to contribute.

https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects

[claremacrae]

Thanks @sytone. Done: Project: Custom Statuses for Tasks Plugin (view)

[erauner12]

hmm, should statuses be paired up with the following? I think minimal theme is using these?
https://github.com/obsidian-tasks-group/obsidian-tasks/blob/main/resources/sample_vaults/Tasks-Demo/Manual%20Testing/SlrVb's%20Alternative%20Checkboxes.md?plain=1

[claremacrae]

@erauner12 please could you explain what you mean by “paired up with?”

[erauner12]

could you explain what you mean by “paired up with?”

Ah sorry for lack of context, what I actually meant by that is in terms of pairing up the name/function of task status to existing css icon snippets of most popular theme.

For some additional context, I did not go out of my way to import any custom css snippets. I am just using minimal theme. Which led me to believe that it would be the closest thing to a source of truth to sync task status with.

[erauner12]

Also, I actually just tested everything from the link I provided above in minimal theme, and only the following status had unique status icons:

- [-] `-` Dropped
- [>] `>` Forward
- [?] `?` Question
- [/] `/` Half Done
- [!] `!` Important
- [b] `b` Bookmark
- [I] `I` Information
- [p] `p` Paraphrase
- [i] `i` Idea
- [c] `c` Choice
- [d] `d` Doing
- [f] `f` Clue / Find

example:

[claremacrae]

thank you. There is no standard set of names for the different task status characters, so it will possible for users to set up their own, and a few popular sets will be be made very easy indeed. Including the two you mentioned.

[claremacrae]

I've started a Project to track the remaining work on this, for the first and subsequent releases.
Project: Custom Statuses for Tasks Plugin (view)

[claremacrae]

If you are interested in testing out a close-to-version-1 of custom statuses build, please see:
#1530
"Test build of Tasks with custom status support - for testing and (critical) feedback"

[claremacrae]

This was just released, in Tasks 1.23.0 🎉
https://github.com/obsidian-tasks-group/obsidian-tasks/releases/tag/1.23.0
See the links in that release page for copious docs and tips.

You can search with status.type is IN_PROGRESS.