161
Working on a FOSS tool to convert raw work time data into a clean report for your boss or client. Any interest?
(lemmy.sdf.org)
It's almost done (it would take one or two weeks to clean it up for FOSS release). It's a CLI tool. It works great for my use case, but I'm wondering if there's any interest in a tool like this.
Say you have a simple time-tracking tool that tracks what you do daily. The only problem is that there are gaps and whatnot, which might not look nice if you need to send it to someone else. This tool fixes pretty much all of that.
Main format is a JSON with a "description", and either "duration" or a "start"/"end" pair. It supports the Timewarrior format out of the box (CLI Time tracking tool).
Am I missing something? It looks like OP has to track their time and send it to a client or superior. What is wrong with making a tool to track your time over using excel? I'm sure if they wanted it through a specific end point they would have provided that.
The logic in the flowchart appears to take in data and mainuplate it based on normalization and ratios to fill the day. So it outputs a report with time that doesn't precisely match the tracked data, but looks nicer for the boss.
I guess if, as this person says, the intended use is made clear then presumably so long as the original logs from which the report was generated are retained then there shouldn't really be an issue. Make your nice, digestible reports that normalise over a workday and give a more grand overview of progress, and if they smell a bit too rosy or you just sometimes need a more granular accounting of time then clients/bosses can request the original raw data from the contractor/employee. Maybe this software itself should include some ability to retain a log of the processing that was done so that the relationship between its generated reports and the source data can be more clearly audited if some kind of a trust issue arises.
The hope I guess would be that you make it clear that this is a more executive summary style of report that you've added as a courtesy because it's more useful in context and that's hopefully enough for whoever you're reporting to but if they want more transparency or detail it's all there for them too.
Exactly! My tool is designed to work with existing time-tracking tools by processing their output. You can think of it as a post-processor that helps clean up and format the data.
Since there are already plenty of time-tracking tools out there (both CLI and GUI), I wanted something that could act as a flexible add-on for them.
Tracking time is fine.
Normalizing your time to the hours you were supposed to work is a massive no no. Especially if you are expected to break down your hours per project.
I mean, you obviously do it. But you never put it in writing.
Honestly I think it's good. The amount of context switching and with breaks, working on several things at once. To normalize that down to a working day seems reasonable
It isn't about being reasonable.
If you are expected to track your time to this degree (and, to make it clear, the majority of employers actively don't want you to), there is a reason. That reason usually being different funding sources. Generally a mix of grants and clients.
And if a client or grant source finds out you are lying about those? Maybe you only had enough work to do 34 hours instead of 40 hours in one week. Would you be cool paying extra because the guy repairing your muffler had a slow week?
And if people think being proud of a tool that openly talks about what everyone else silently does isn't a red flag for employers? Hey, its a great job market so I am sure none of that will matter.
Boss makes a dollar, I make a dime.
That's why I use this app to normalize time.
Totally understand your perspective, and I’m not here to push back against it. You’ve got a valid point.
I’ll just add that there are already commercial tools that do similar things to what I’m building. It’s interesting to consider how perceptions might shift if a tool were released by a company rather than a solo developer. Sometimes the context influences how a tool is interpreted, even if the underlying functionality remains the same. For what it’s worth, I have no commercial intent behind this.