Activity Log (Better time tracking)

[booniepepper]

Great ideas from @stranger-danger-zamu in a discussion from #12

[Elapsed time] is a bit dangerous since a thing can be within the stack for a while before floating to the top and then it might not be worked on. So it's pretty simple to have something balloon in elapsed time pretty quickly.

1. One option is have elapsed time be a number of seconds as the head of the stack. So Sigi would track when an item become the head of some stack and then save the elapsed time when it exits being the head of that stack. This would probably be the most accurate tracking, but with some added complexity.
2. You can also just compute elapsed time as the difference between creation and completion/deletion/finished time, but then the numbers might be huge.
3. Another option is utilizing an activity log which allows for querying an individual item's events and calculating elapsed time between any two events becomes pretty trivial. Determining which events should be stored does become a larger factor though (eg. only transitions or transitions and something becoming the head).

Option 2 is easiest to implement, but easily the least useful to any human trying to be productive.

Option 1 might be a good bang-for-the-buck, but I think it's useful only when people are doing some kind of pomodoro tracking or other very specific workflow.

Option 3 has some ideas to think about re: scaling issues, but it would easily give the best analytics for anyone interested.

---

Kind of leaning towards Option 3

[booniepepper]

So, the more I think about it, the more I'm thinking that the paradigm of:

• {stack}
• {stack}_completed
• {stack}_deleted

...has to go.

Any change here should use a major version bump to update, though.

I think an activity log is a better way to go, but I'm having trouble thinking of how to implement it in a way that would be most useful. I'm going to leave this open and wait for either inspiration to strike, or for someone to bounce ideas off of.

[stranger-danger-zamu]

Activity log

If it's solely tracking the time that something has been "worked on" then it should at least record two events, when something becomes the head of a stack (entered_head) and when something stops being the head of a stack (exited_head). Each event would record the event time, the item ID, the event description (entered_head/exited_head), and any other contextual information that would be helpful.

Querying for a specific item from the activity log would return all events, so you would sort the events chronologically and calculate and sum all the elapsed times to determine the cumulative elapsed time.

I think currently the items are missing IDs. ID are required to make an activity log work. It could be as simple as a UUID4, the nanosecond-specific created_at timestamp, the sha256sum of the data/name, or even some combination of attributes (eg. ${timestamp}-${first_stack}).

You could implement it as "proper" activity log (ie. append-only log of chronological events), but that can run the risk of being slow to query (since it linearly scans through the items). You can "index" the logs (and there by improving search performance) by storing the events as a hash map/dictionary. So you can query with the item ID and get the record of all of its previous events in one go.

Of course, that does make it hard to piece together other use cases for the activity log, so it comes down to how you would want to use it.

Oh and: Any item that is currently the head would be open ended so a missing exited_head should be assumed to be the current time.

[booniepepper]

What kind of information would you try to get out of time tracking?

Average time per task? Slowest x tasks? Fastest y tasks?

(I'm not thinking I'll go all the way to an end goal, but want to make sure I make something that can at least be a foundation for something useful)

[stranger-danger-zamu]

Ah I was thinking of statistical analysis.

Being able to determine the mean and standard deviation for a type of task is huge in estimating delivery times. You could also do pattern detection or cluster analysis on the tasks (or type of tasks) to see if there is a particular pain point. Types of tasks can be determined by tags (ie. simple hashtags).

I do something similar with my bash history where I do frequency analysis to see if something should be automated. So for something like Sigi it might help discover certain types of tasks I'm slow at or helping clear backlog by raising the priority of certain "easy" tasks.

I wouldn't want Sigi to be the thing actually generating the analysis but definitely allowing for easy exporting of the data and metadata.