Page MenuHomePhabricator

Make phrequent tasks automatically stop after a limit
Closed, WontfixPublic

Description

If someone forgets to stop tracking their work, phabricator will keep counting it. I feel this will lead to inconveniences. Like currently the tracker reports people working on tasks for 28 weeks nonstop https://secure.phabricator.com/phrequent/

I feel that there should be a setting which puts a timeout on the task.

However there are some weird issues that might arise out of this:

  1. This would have to be implemented in some sort of clean-up daemon I guess.
  2. What if the timeout is changed from 2 hours to 1 hour. If someone's working on a task for 90 minutes does the task get closed, or wait 2 hours for that task's original timeout?
  3. Should there be a way to "extend" work by not having the daemon close the tracking on the task.

For that matter, should the user be allowed to set his own maximum before the task times out? Would this become too complex?

Event Timeline

skyronic raised the priority of this task from to Needs Triage.
skyronic updated the task description. (Show Details)
skyronic added a project: Phrequent.
skyronic added subscribers: epriestley, skyronic.

I don't think we should have this, we should just make it easy for users to fix things if they make a mistake. The 28-weeks-nonstop are just users testing things and messing around, I don't think anyone who was actually tracking their time would ever hit a situation like this. In the worst case, they'd come in the next morning or whatever and be like "oh, I forgot to stop before I left last night -- arc stop --all --at '5PM yesterday'" or whatever.

As long as that's easy, I think trying to second-guess users will just be more confusing and frustrating, especially if they have to keep clicking some kind of an "i'm still alive" button every hour.

Another issue is that it's not very easy to see what you're tracking right now, but T3993 and easier access via arc tracking or whatever should help with that.

epriestley claimed this task.

I think we can solve this better in other ways, as Phrequent evolves. We can look at it again once the tool is further along.