5 ms·

I am conflicted on this. The spec is nice. I love the recognition that dates may be imprecise (e.g., 2022-05 -- although I would count that as the last day of

by D13Fd 5y ago

I am conflicted on this. The spec is nice. I love the recognition that dates may be imprecise (e.g., 2022-05 -- although I would count that as the last day of the period, 23:59:59 on 2022-05-31, rather than the first day of the next period, 2022-06-01). I like the thought that went into it and the nice presentation. On the other hand, I do not think this is necessary or even all that helpful in the real world. You don't need a standardized format if you are writing to do items manually in a text editor. You just write them. In the vast majority of cases no one is going to see them but you. Time spent conforming to a spec is time wasted. A formal spec also doesn't help much for apps to use this format. There is not a huge need for portability between to do apps, and for most users to do items are ephemeral and not something that needs to be archived and revisited. Even if an app adopted this, being tied to a plain text format would likely hinder feature development, including the ability to sync across multiple devices. Beyond that, different to do apps use different systems of categorization and tagging, so really in practice I doubt this will become any kind of standardized format. So, all told, it is a beautiful effort, nicely presented, but I think it is unnecessary.

haswell 5y ago
> A formal spec also doesn't help much for apps to use this format. There is not a huge need for portability between to do apps... To add some counterpoint to this, I try a lot of apps. Partially because I'm always looking for the one that's better than what I use now - looking for the thing that fits me the best - but also because I just like trying things. Portability means a greater chance that I'll fully dive in and use an app to its potential vs. some light use. There have been a few times that I've found a new app/solution that was clearly better than what I was currently using, and this was both exciting and frustrating. Frustrating because it meant I'd either have to leave my history behind, or spend a ton of time trying to port it over somehow. I realize I'm part of a niche group of people, but I feel like a spec like this was meant for a pretty niche group of people. I for one do not agree that this is unnecessary, but I do acknowledge that it's probably not necessary for a lot of people.
- jotaen 5y ago
  > I feel like a spec like this was meant for a pretty niche group of people. That’s spot on actually.
- johnwalkr 5y ago
  Portability and human readability in a normal text editor are huge plusses for me. I mostly use paper notebooks, but when I need to keep track of todos over a long period of time for a specific thing, I like to have a text file located with that thing. With all of these cloud-based tools we now use, everything’s refactored to be organized based on tool, then project instead of project, then tool. I for one am starting to rethink this. Changing of tools or people, or simply passage of time inevitably loses information, or knowledge of where information was stored. I could see myself using this format for simple tracking in a git repo where I don’t want to use GitHub or another similar tool. One use case would be getting things done in a JIRA/middle-management heavy organization. Having the spec is then nice because anyone could use their preferred tool if they want to and one could easily check for open todos in a bunch of folders/repos.
jotaen 5y ago
I appreciate the criticism, thanks! I disagree, though, that adhering to standardised formats is not worth it. Currently, there are countless todo apps and editor plugins out there, which all do very similar things. However, each needs their own dedicated editor plugin for syntax highlighting, and you can’t easily switch the client apps without having to also switch the underlying data format. What I agree with is that standards limit the creative freedom of tool creators. But that’s the same balancing act all over again, no matter where you look at.
- deleted 5y ago
  [deleted]
smoe 5y ago
A spec makes it more easy to build tooling around it. I reckon the people that love emacs org-mode, do so not mainly because of its specification, but the power to manipulate those plain text files in the editor.
zamubafoo 5y ago
I think that having a formal spec would help since a lot of the minutiae that is done to format and the like can be in the form of snippets in (nearly all) text editors used today. So just having the autocompletion for people editing in text does wonders. As for standardization, applications don't have to target it as their on-disk format for it to be useful. Instead of bespoke JSON/XML schemas or proprietary formats, having a plain text export format is a big win. Specially if it's human readable and human writeable.
- D13Fd 5y ago
  I'm not sure this is the best tool for an import-export format, as it is unable to capture all of the data available in some to do apps. I could see it being OK as a sort-of data backup format. But it's missing a lot of data that really ought to be tracked by an app, like creation, update, and completion times for each item. Many apps also track priority, sort order, hidden/unhidden status, attachments, and other things. This stores none of that. Even then, the value is fairly small. In 20+ years of using to do apps, I can think of very few times that I've referred back to completed to do items.
mufufu 5y ago
I disagree, having the spec is the first step to building tooling around it. People can port plugins that support this format to vim, eMacs, VSC, etc.. and create functionality around it. For example: reorder into a date view
- systemvoltage 5y ago
  I think the author is saying there is already a spec, just one abstraction layer above: Plain text. Anything that can read and write text can interact with the to-do list. In some ways, it is more portable.
- thirdwhrldPzz 5y ago
  Still, why plain text? If the goal is “wrap it in UI” why a new white space, special characters. Why not YAML or JSON and the vetted libraries to read and write the format? As a user I don’t really have any concern with what underlying data format and structure it stores things in. I want to manage my todos! This could be an SQLITE file for all I care. Software engineering should be about more productive UX, not flexing one’s ability to parse arbitrary syntactic art.
  - jotaen 5y ago
    I think the viewpoints on that are wildly diverse. As far as I’m concerned, it’s the exact opposite. Hence, I think it’s great that there is a big variety of different approaches that everyone can pick from according to their own preferences.
    - thirdwhrldPzz 5y ago
      Sure; I’m just expressing mine. The “glyphs and how to display or sort them wars” aren’t important enough to me to take real offense to alternatives. This is just idle discourse for me. Lindy Effect type thoughts, why import another dependency; familiarity, existing portability, and habits with current formats; deep and wide tooling and language support… road built; let’s drive to shovel poetic drivel out the door.
  - 5y ago
oezi 5y ago
I think it is nice when there is a well thought out spec for something. But in this particular case, I think it is not compatible enough with other tools. In particular, Markdown has a todos (using the same `[ ]`) and just uses indentation for grouping. I find this more intuitive and it renders in markdown renderers. For priorities, I have adopted the notation of OneNote which puts exclamation and Unicode star symbol next to the todo brackets. I also use some other conventions: [-] for obsolete rather than [~]. [>] for postponed until later Implemented in my Todo manager TUI: https://github.com/coezbek/rodo https://github.com/coezbek/rodo
- jonnycomputer 5y ago
  Might be right, but as an interchange format between todo-apps, might be worth it?
- randlet 5y ago
  > In particular, Markdown has a todos (using the same `[ ]`) and just uses indentation for grouping. Came here to mention the same thing. I use a plain text todo format that is quite similar (thought not nearly so thought out/complete) to the one OP is proposing, but I use indentation for grouping as it's a lot easier for me to visually identify related groups of tasks.
vhanda 5y ago
> A formal spec also doesn't help much for apps to use this format. There is not a huge need for portability between to do apps, and for most users to do items are ephemeral and not something that needs to be archived and revisited. Even if an app adopted this, being tied to a plain text format would likely hinder feature development, including the ability to sync across multiple devices. Beyond that, different to do apps use different systems of categorization and tagging, so really in practice I doubt this will become any kind of standardized format. I disagree. I maintain a rather popular plain-text-based app [1] and the formal spec makes this something very very easy to add support for. Infact the only thing that could make this even easier is if there was a way to verify my own implementation. [1] https://gitjournal.io https://gitjournal.io
- D13Fd 5y ago
  Yes, you could add support for it. To what end? Do you think the usage will be high enough to justify the effort to implement and maintain it? Even imagining the ideal world where every to-do app implements this, portability of to-do items between apps just isn't that big of a problem. There isn't a big need to move long lists of to-do items between apps. And in the real world, this won't be implemented perfectly. You'll have the App A implementation, the App B implementation, and so on. Look at Markdown. You'll have headaches migrating your to-do items automatically and in the end, most likely, you'll just end up copy and pasting them. It's not that hard and old to-do items aren't that important to the vast majority of people.
  - vhanda 5y ago
    This sounds a bit defeatist. Yes, it won't be perfect at first, but there is always a chance of reducing the barrier to entry. The lower it is, the more % of users / developers / apps are going to use it.
    - D13Fd 5y ago
      It's not defeatist. As I said, I just don't think, even in the optimal scenario, that it is a goal worth achieving. Personally I'd rather software developers focus their time on more worthwhile features.
posharma 5y ago
Agree. Todo lists are ephemeral. They're not meant to be stored and archived. Just write the list already, execute the items in the list and move on. Focus on getting things done rather than creating new formats for these ephemeral lists.
- noizejoy 5y ago
  > Todo lists are ephemeral. They're not meant to be stored and archived. I have many recurring items on my todo list. So those might be nice to be portable between apps.
RankingMember 5y ago
Agree, not everything needs a special format or spec. To me, it just obfuscates the core purpose of a to-do list for me, which is to record the bare essentials to remind me of things I need to do, then do them and forget about them. Anything else is just more overhead I don't need.
eigenvalue 5y ago
Where I think something like this is most useful is as a common interchange format. For example, if you are using TickTick as a todo app and decide you want to switch to using Notion or something. If there were an ecosystem of converters to this common format, that would make this trivial to do.

by D13Fd 5y ago

haswell 5y ago

> A formal spec also doesn't help much for apps to use this format. There is not a huge need for portability between to do apps... To add some counterpoint to this, I try a lot of apps. Partially because I'm always looking for the one that's better than what I use now - looking for the thing that fits me the best - but also because I just like trying things. Portability means a greater chance that I'll fully dive in and use an app to its potential vs. some light use. There have been a few times that I've found a new app/solution that was clearly better than what I was currently using, and this was both exciting and frustrating. Frustrating because it meant I'd either have to leave my history behind, or spend a ton of time trying to port it over somehow. I realize I'm part of a niche group of people, but I feel like a spec like this was meant for a pretty niche group of people. I for one do not agree that this is unnecessary, but I do acknowledge that it's probably not necessary for a lot of people.

jotaen 5y ago
> I feel like a spec like this was meant for a pretty niche group of people. That’s spot on actually.
johnwalkr 5y ago
Portability and human readability in a normal text editor are huge plusses for me. I mostly use paper notebooks, but when I need to keep track of todos over a long period of time for a specific thing, I like to have a text file located with that thing. With all of these cloud-based tools we now use, everything’s refactored to be organized based on tool, then project instead of project, then tool. I for one am starting to rethink this. Changing of tools or people, or simply passage of time inevitably loses information, or knowledge of where information was stored. I could see myself using this format for simple tracking in a git repo where I don’t want to use GitHub or another similar tool. One use case would be getting things done in a JIRA/middle-management heavy organization. Having the spec is then nice because anyone could use their preferred tool if they want to and one could easily check for open todos in a bunch of folders/repos.

jotaen 5y ago

I appreciate the criticism, thanks! I disagree, though, that adhering to standardised formats is not worth it. Currently, there are countless todo apps and editor plugins out there, which all do very similar things. However, each needs their own dedicated editor plugin for syntax highlighting, and you can’t easily switch the client apps without having to also switch the underlying data format. What I agree with is that standards limit the creative freedom of tool creators. But that’s the same balancing act all over again, no matter where you look at.

deleted 5y ago
[deleted]

smoe 5y ago

A spec makes it more easy to build tooling around it. I reckon the people that love emacs org-mode, do so not mainly because of its specification, but the power to manipulate those plain text files in the editor.

zamubafoo 5y ago

I think that having a formal spec would help since a lot of the minutiae that is done to format and the like can be in the form of snippets in (nearly all) text editors used today. So just having the autocompletion for people editing in text does wonders. As for standardization, applications don't have to target it as their on-disk format for it to be useful. Instead of bespoke JSON/XML schemas or proprietary formats, having a plain text export format is a big win. Specially if it's human readable and human writeable.

D13Fd 5y ago
I'm not sure this is the best tool for an import-export format, as it is unable to capture all of the data available in some to do apps. I could see it being OK as a sort-of data backup format. But it's missing a lot of data that really ought to be tracked by an app, like creation, update, and completion times for each item. Many apps also track priority, sort order, hidden/unhidden status, attachments, and other things. This stores none of that. Even then, the value is fairly small. In 20+ years of using to do apps, I can think of very few times that I've referred back to completed to do items.

mufufu 5y ago

I disagree, having the spec is the first step to building tooling around it. People can port plugins that support this format to vim, eMacs, VSC, etc.. and create functionality around it. For example: reorder into a date view

systemvoltage 5y ago
I think the author is saying there is already a spec, just one abstraction layer above: Plain text. Anything that can read and write text can interact with the to-do list. In some ways, it is more portable.
thirdwhrldPzz 5y ago
Still, why plain text? If the goal is “wrap it in UI” why a new white space, special characters. Why not YAML or JSON and the vetted libraries to read and write the format? As a user I don’t really have any concern with what underlying data format and structure it stores things in. I want to manage my todos! This could be an SQLITE file for all I care. Software engineering should be about more productive UX, not flexing one’s ability to parse arbitrary syntactic art.
- jotaen 5y ago
  I think the viewpoints on that are wildly diverse. As far as I’m concerned, it’s the exact opposite. Hence, I think it’s great that there is a big variety of different approaches that everyone can pick from according to their own preferences.
  - thirdwhrldPzz 5y ago
    Sure; I’m just expressing mine. The “glyphs and how to display or sort them wars” aren’t important enough to me to take real offense to alternatives. This is just idle discourse for me. Lindy Effect type thoughts, why import another dependency; familiarity, existing portability, and habits with current formats; deep and wide tooling and language support… road built; let’s drive to shovel poetic drivel out the door.
- 5y ago

oezi 5y ago

I think it is nice when there is a well thought out spec for something. But in this particular case, I think it is not compatible enough with other tools. In particular, Markdown has a todos (using the same `[ ]`) and just uses indentation for grouping. I find this more intuitive and it renders in markdown renderers. For priorities, I have adopted the notation of OneNote which puts exclamation and Unicode star symbol next to the todo brackets. I also use some other conventions: [-] for obsolete rather than [~]. [>] for postponed until later Implemented in my Todo manager TUI: https://github.com/coezbek/rodo https://github.com/coezbek/rodo

jonnycomputer 5y ago
Might be right, but as an interchange format between todo-apps, might be worth it?
randlet 5y ago
> In particular, Markdown has a todos (using the same `[ ]`) and just uses indentation for grouping. Came here to mention the same thing. I use a plain text todo format that is quite similar (thought not nearly so thought out/complete) to the one OP is proposing, but I use indentation for grouping as it's a lot easier for me to visually identify related groups of tasks.

vhanda 5y ago

> A formal spec also doesn't help much for apps to use this format. There is not a huge need for portability between to do apps, and for most users to do items are ephemeral and not something that needs to be archived and revisited. Even if an app adopted this, being tied to a plain text format would likely hinder feature development, including the ability to sync across multiple devices. Beyond that, different to do apps use different systems of categorization and tagging, so really in practice I doubt this will become any kind of standardized format. I disagree. I maintain a rather popular plain-text-based app [1] and the formal spec makes this something very very easy to add support for. Infact the only thing that could make this even easier is if there was a way to verify my own implementation. [1] https://gitjournal.io https://gitjournal.io

D13Fd 5y ago
Yes, you could add support for it. To what end? Do you think the usage will be high enough to justify the effort to implement and maintain it? Even imagining the ideal world where every to-do app implements this, portability of to-do items between apps just isn't that big of a problem. There isn't a big need to move long lists of to-do items between apps. And in the real world, this won't be implemented perfectly. You'll have the App A implementation, the App B implementation, and so on. Look at Markdown. You'll have headaches migrating your to-do items automatically and in the end, most likely, you'll just end up copy and pasting them. It's not that hard and old to-do items aren't that important to the vast majority of people.
- vhanda 5y ago
  This sounds a bit defeatist. Yes, it won't be perfect at first, but there is always a chance of reducing the barrier to entry. The lower it is, the more % of users / developers / apps are going to use it.
  - D13Fd 5y ago
    It's not defeatist. As I said, I just don't think, even in the optimal scenario, that it is a goal worth achieving. Personally I'd rather software developers focus their time on more worthwhile features.

posharma 5y ago

Agree. Todo lists are ephemeral. They're not meant to be stored and archived. Just write the list already, execute the items in the list and move on. Focus on getting things done rather than creating new formats for these ephemeral lists.

noizejoy 5y ago
> Todo lists are ephemeral. They're not meant to be stored and archived. I have many recurring items on my todo list. So those might be nice to be portable between apps.

RankingMember 5y ago

Agree, not everything needs a special format or spec. To me, it just obfuscates the core purpose of a to-do list for me, which is to record the bare essentials to remind me of things I need to do, then do them and forget about them. Anything else is just more overhead I don't need.

eigenvalue 5y ago

Where I think something like this is most useful is as a common interchange format. For example, if you are using TickTick as a todo app and decide you want to switch to using Notion or something. If there were an ecosystem of converters to this common format, that would make this trivial to do.