[raldu]

I have came to the understanding that the things that we'd like to keep track of as "todos" are more like "issues," than specific and physical actions.

The "tasks" are only meant for the day, maybe drafted daily and be disposed of and forgotten in a post-it notes fashion.

The issues, then are more like a backlog of requirements, a call to duty, like "briefs on the mission."

The "issues" are the question; and neither todos, nor tasks are the answer.

It is robotic to compile and keep track of a set of "actions to be done" several days into the future, but those todo.txt's as a database can be treated as valuable asset, as a "documentation of scope," for a team-of-one, or many.

Hence the treatment of those not as "todos" as issues, with their shifting nature of requirements and many ways of resolution.

Such a database deserves reinventing because nothing else can be as tailored and as diamond-cut as the one that's been built by you.

[mxuribe]

Your approach on "issues" is fascinating! It certainly sounds like you're talking about almost tracking tickets...you know like for a dev or tech support team...Because my experience is that often tickets are not a one-and-done thing. Often enough, they require a little more folow-up, and i myself like to add comments along way towards the progress of completion...so, yeah, your approach sounds alot like tracking tickets...which in itself is NOT bad at all. The only concern is that tracking tickets often requires some pretty robust software/tool...so unless we're talking a kanban, the fear i would have is that the software/tool to use for tracking tickets might be too unwieldy for quick, let's say mobile tracking of progress...though i admit that may wrong on all thre above.