Also, if you currently have blockers, friction, or anything else impacting you from recording worklogs in Jira quickly, please share them here.
We have some budget as part of BB-10142 to create tickets and allocate time to address these blockers - eg. to fix bugs in automation software, thinking about your own workflows, get onboarded to time tracking or automation software.
I use a tool called klog via a wrapper CLI I’ve written myself. What I like about it is that it uses a simple text format that you can write in a text editor.
My wrapper CLI basically uses klog as the backing storage and adds support for Jira. The wrapper will pull my active ticket and let me select where to log time, or I can give it a ticket number or link, and it’ll pull in the details from Jira to add to the work log as a tag. I can also push logs to Jira from it.
Here are some issues I face among others:
I sync the logs between my laptop and desktop, and sometimes they get out of sync and need to be manually reconciled.
If I log any time without a ticket, it will not sync (this is by design)
Just wanted to note that I had been uploading (syncing) my work logs a bit inconsistently, but since this discussion I added a daily reminder email to myself and that’s been working well - I have been syncing them every day since I set that up.
I use a combination of go-jira, timewarrior custom script and neovim to sync my logs daily. This is the timewarrior extension script that takes my timewarrior logs and converts into gojira cli commands that log worklogs.
I have a small macro setup in my neovim that create below piece of text in the day log at the end of the day.
To track my time, I use the Clockify browser extension with some private customizations to support our Jira instance (and automatically create tasks, projects, and tags in Clockify with a single button click).
To sync my time logs, I use a custom Python script with minimal deps (aiohttp, click, rich).
I have a Clockify browser extension, which I start tracking when I am working on a task (I generally work on one ticket at a time). When I stop working on that ticket for that time, I stop the time and log it on jira ticket. I find this workflow simple. I also cross-check once a month if I have missed logging something.
I am aware of the automation, but I really don’t have enough data points to prove that it saves time for me.
I find it annoying and time-consuming. That said, it does let me be a bit lazy with how I name my time logs in Toggl Track, knowing I can clean them up when I log time in Jira at the end of the day. It also makes it easier to average out time spent on small, miscellaneous tasks and spread that time across multiple tickets.
I was, but figured I needed developer knowledge and tools to set it up.
The manual process is ok to me (I work on no more than 3-4 tasks a day).
I tried setting up Tempo during my onboarding, but couldn’t get it to work, so I let it go (I didn’t spend much time on it). About a year ago, I planned to set up something based on what Navim has, but I never took the time to do it. Also, I thought the Jira migration process would be smoother, so I didn’t want to invest much time in it.
The manual process works fine for me; it doesn’t feel like it takes up much time. I create the logs in Toggle using the task codes (e.g., FAL-1111, MNG-1222). At the end of the day, I upload my logs using those codes; it makes it simpler and faster.
I am aware of the automations. I’m not sure it will save me any more time. I feel like I’m going to spend more time on setup.
Not sure about time-consuming, but it is a bit annoying.
I have been meaning to modify one of the automation tools or to write a new one to suite my needs, but have been procastinating on it mostly and then we decided to migrate away from Jira and my plans to automate my time logging workflow really went to the back burners.
I would be, except I think it started as just a simple script with some hardcoded credentials, so open sourcing will require rewriting the history. Or I can just squish it and start the history from scratch.
I also initially make the system modular and support multiple backends, klog, timetager and timewarrior so it would log to all three so I could compare them in practice. I settled on klog in the end so the others are only kind of supported.
Would you like a ticket and some time budget to investigate/modify/write automation here? There are already two tools that work with Toggl (toggl-tempo-worklog-transfer and Minutes), so it may not need much effort.
That woul be great, but given the imminent move away from Jira, I am not sure it is worth investing time on this till we know what the new tool looks like. It would be great to schedule a ticket when we make the move to rework the existing automation scripts.
NOTE: we are planning to migrate away from Jira at some point, but there is no timeline set. Also, many of these tools and documentation could be easily ported to the Jira replacement. Thus it is considered worth the time investment to improve and document this process.
A note from Xavier on this: “Agreed about it being worth it, even though we are going to switch from Jira. I’m sure some people will prefer to keep tracking their time with their preferred tool, so this would then be adapted to match the new tracker, rather than fully lost.”
In this case it’s your choice; if you’re content with your current process until we have a Jira replacement, that is totally fine. Just know that there is budget available if you decide you would like to spend time on this. I’d also encourage you to use the budget if you’re finding your current process is impacting timely worklog uploading.
