Good idea. We could set it in settings.yml, so that people can call it whatever they want.

Would be nice if it can collect the different Actions of a project, so that i only see the Project name instead of 20 Actions of the same project in the Someday/Maybe list.

I like andre@roalaus.de's comment. Sometimes I'll brainstorm a project with some next actions and it's really a Someday/Maybe project.

I thought of something like that, too. Maybe simply another flag in the project model to change between Active and "Someday/Maybe". So one could make up many projects and plan them, assign actions to them (Which shouldn't be active, too) and then "park" them in the "Someday/Maybe"-state. If the project becomes more likely to be actually active one could just "activate it".

Considering for 1.8

Can this use case be resolved through usage?
e.g.
A user has a stale actions accumulating in a stalled project. The project will not be worked on for some time, and the user does not want to see stale actions in the project. If the user marks the project as "hidden" and has tracks configured not to display hidden projects, then will not the stale actions be hidden as well, preventing 'alarming colors?'

Have I misunderstood the purpose of this ticket?

yes and no :-)

The hidden state of contexts and projects can indeed be used for someday/maybe as you comment.

But it is not very easy to review your complete someday/maybe list since it is spread over several hidden projects and hidden contexts. Also putting a todo in a hidden context removed the original context. Not so awfull, but annoying. Furthermore, I personally have some contexts that I don't use anymore, but do not want to delete (archive / statistics). So looking at the hidden contexts lists and finding the someday/maybe context is annoying

That's a good point. How about a per-todo item staleness? Staleness is set as a global option in preferences. What if that setting was kept as a default setting for new todos, and a new field is created for todos:

  my_todo.days_until_stale = 3     # becomes stale in 3 days
  my_todo.days_until_stale = 0     # will never be stale
  my_todo.is_stale?  =>  false

Another possibility that could be considered is a default per-project staleness (like the default project context). When a new project is created, the project-default days_until_stale is initialized from the global setting; when a new todo is created, the todo days_until_stale is initialized with the project-default days_until_stale.

The other problem that would need to be addressed for someday/maybe usage is the promotion of TODOs to projects, and the more difficult case of demoting projects back to TODOs.

why do you want to be able to set staleness? Is it because of todos you want to place on the someday/maybe? In that case you can opt to implement a 'reset' of the staleness reference date when a todo (or project) comes from the tickler

Updating tickets (#743, #752, #768, #781, #535, #47, #295, #298, #805, #806, #324, #584, #97, #592, #344, #603, #114, #629, #636, #645, #393, #405, #433, #434, #202, #462, #220, #233, #310, #95, #635, #397, #94)

I do not use alarming colors at all, I set it in my preferences to 360 days.

If I need a task to be finished, I set due date.

Migrated to GitHub issue #1581