Our team evaluates Clockwork + ActivityTimeline as a replacement for Everhour plugin. The key feature that Everhour gave us is clicking "Start Timer" in the given task, that causes disabling of any other timer that counts time. It would be great to have the same behavior in Clockwork. The key advantage of Clockwork is integration with JIRA time tracking on which ActivityTimeline rely.
To be honest I don't see a use for multiple timers working at the same time. If it is really needed it should be optional.
Do you consider implementing that feature?
Hi Paweł,
I'm just analyzing competing solutions. To be honest, I'm fine with paying for Clockwork a reasonable amount, but if I stick with it I would like to understand what is the timeframe for this improvement. Any chance you can throw a number?
Also, I think this will can cause counting mistakes and if your finances depend on time measuring then there is no space for mistake.
Best Regards,
Piotr
Hello Piotr,
This is a "must have" feature and located on the "short term" backlog.
It is a crucial behavior for proper and precise time tracking, especially in "automated" mode that Clockwork supports.
It is hard to share any ETA as it depends on too many things, and the team doesn't want to disappoint you or anyone else if they are late.
Nevertheless, there are more and more customer asking for it so the team will work on that according to the backlog.
Thanks,
Jack
Jack,
ok, I hope to survive as Clockwork user till release that will include mentioned feature.
Anyway, thanks for the great plugin and quality support.
Best Regards,
Piotr
Hi Piotr,
just wanted to let you know that Clockwork can stop other timers running for the same user now. You need to enable that in Clockwork's configuration though.
Cheers,
Pawel
In the meantime, Everhour has released its native app where we sync with Jira estimates. time tracking sync is also in plans:
I've just switched teams to one that's got "Clockwork" enabled and I keep encountering this warning about having multiple timers started, so I googled and found this four-year-old bug-report/RFE.
IME having multiple things "on the go" isn't an exception, it's normal. IME having only one thing going is a rare luxury; I can't remember the last time that I cleared my workload to the point where I could purely concentrate on one task to the exclusion of everything else AND was in the ideal development scenario where I never encountered any blocking issues that forced me to context switch while awaiting unblocking.
I understand that people can't work 100% on multiple tasks at once, but it's unreasonable to expect users to go into JIRA and switch a task from "in progress" to "open" and back every time they're waiting for a CI build / waiting for a colleague to answer a question / whatever, and to switch another task from "open" to "in progress" (and back) while they work on that while waiting for whatever will unblock progress on their main task.
One *cannot* rely on humans to undertake manual corrective action to workaround a tooling limitations if one wants to have reliable results; humans don't work like that.
Y'all really need to divide the logged time between all the running timers. Sure, it's not going to be 100% accurate because people probably concentrate on one task more than others, but that's infinitely better than claiming that users are spending "more than 100%" of their time on tasks.
Maybe v1 could just divide elapsed time between open tasks evenly and v2 could maybe look at other metadata to try to determine a more accurate time split (or maybe ask the user what the time split was).
How it's done is up to you, but just saying "time tracked will be duplicated and skewed" (and hence cannot be used without a risk of fraud) isn't a reasonable answer ... especially when it's been over 4 years now.
TL;DR: A tool that can't handle real-world situations isn't suitable for use in the real world.
Hello @Darton, Peter
We at HeroCoders understand very well that switching contexts is a pain and our app is built with that in mind. Since you do not want to have warnings about multiple timers running at the same time, we recommend switching to the "Starting a new timer stops all other timers running for the same user" configuration in Clockwork's settings, as shown:
With this, you will not need to worry about manually transitioning any other issues than the one you are working on at the time, and you only need to remember to put the ticket you worked on last to a Paused/On Hold status at the end of the day, so you have no timer running overnight.
We are dedicated to improving our app and appreciate your feedback. We have some cool improvements in our backlog, including ones related to solving issues like the one you reported. If you'd like to discuss this further, please feel free to contact us via our service portal.
Firstly, thanks for the reply ... but I'm unconvinced that this is a viable answer as-is.
I acknowledge that, with this option switched on, time will no longer be over-recorded.
Instead, it'll be under-recorded - the tooling will've automatically halted one task's timer when another timer is started, but there's no mention of automatically restarting the automatically-stopped timer.
I would re-iterate that relying on humans to do a boring repetitive job (that a computer should do) is simply not a viable option; humans make mistakes when doing boring jobs; anything that "should be done automatically every time" should be done *automatically* by the software.
However, I solved this flaw another way: I stopped using Clockwork and, overall, we're switching over to another tool that _does_ handle multiple tickets (and uses other metadata to guess at the workload split). Now nobody's demanding that humans push extra buttons "without fail" because the tooling "just looks" at what's going on and measures that.
Time will tell on whether or not that solves all our problems, but it certainly solves the most obvious ones w.r.t. time recording.
Cheers!
Adaeze.