Feature request: More descriptive metadata, and perhaps better workflow

[jeblad]

Noticed the issue #91 and pull request #179, and how they are partial solutions of the following problem.

The time tracker has entries for work with two types of metadata, categories and tags. Categories are also called tasks, and they are in addition organized in the task pane. Given that categories are called tasks it sets some hard constraints on their interpretation, still the “tasks” should split into at least administrative tasks and useful tasks. In some cases they are said to be “input factors for accruals”. Tags seem to have a more free interpretation.

There are two types of metadata that are missing, projects and overtime. Projects are who to bill the tracked time, and overtime is how to bill them. Overtime is a gross simplification. Usually it is split into normal time, additional time, and overtime. I wonder if the present tag-system is commonly used for billing info.

Normal time, additional time, and overtime, is quite messy if we are going to automate the calculation. It is based upon inner and outer core time, normalized work day and week, week day, etc. It can also deviate due to local accord or contracts.

Projects should be bound to contracts, and there might be a single contract in the system with a single employer, but it might also be several contracts. Billable projects are those that are bound to contracts. Each contract would have its own contact address.

My personal favorite format is

[task|task@project]:<description> -- <time info>

where <description is free text that might contain tags on the form #tag.

For “normal time” the part after the double dashes can be left out, and it can also be left out for the drop down list.

A task will not in general be project specific, but it might be. Perhaps the description in the drop down list should be without projects, not quite sure how that will work out…

[mgedmin]

(Sorry for a long delay, I was on vacation and ignoring computers.)

I'm used to project: description (ticket) myself. Categories are projects (or clients, if I'm working on multiple projects for a client) + some other kinds (like "sysadmining").

The word "task" is unfortunately overloaded: gtimelog uses it to refer to the entire "category: description" string. I'm not sure how you came up with the "categories are also called tasks" theory.

I've never had to track overtime specifically, but wouldn't that be better automated by counting the hours worked per day/week/whatever and seeing if that exceeds a certain amount? I don't think it would be convenient to split entries to tag overtime manually every time.

Tags... I sometimes regret merging the PR that added tags to gtimelog. I don't use them myself, and I don't have a clear mental model of how they can be useful. Also, the syntax is confusing.

[jeblad]

To follow my own naming scheme (it is what I'm used to); tasks are what you do as an overall concept, projects are usually billable and associated to customers. The tasks (or concepts) are what the customer pays you to do, like programming. Often it is split in blue coat and white coat work. Some countries have regulations for how this should be reported, but it is often pretty hard to figure out what the actual rules are.

The customers have in-house projects, and they are often (but not always) given numbers (aka tickets). Odd thing, they often want to call these projects tasks. Somehow you must show which in-house project you work on, call it description or whatever, but in that field the in-house projects must be identified. If you want to play nice with the customers, then they should get numbers for time used on each such in-house project. If such an in-house project is named in a line, then I just assign the whole line to the project. Whether two tags is inconsistent is open for debate, but it should be possible to work on two in-house projects at the same time (aka tickets).

Overtime is pretty difficult to get right. You can be employed in some capacity, and at the same time be hired to do different work. If you are hired as a consultant you usually work on hourly basis without overtime, while as an employee you get overtime. Counting hours as a consultant is easy, calculating overtime as an employee is not so easy. If you have several contracts at the same time it becomes messy.