Add time spent on a past date

Discussion

From https://gitlab.com/gitlab-org/gitlab-ee/issues/1265#note_18833868

If I forgot to log my time for last week, the UI lets me back-fill WHEN the time was spent because I can enter the date that the time was spent. In the current Gitlab EE implementation it seems that you can record that time was spent, but not on what days. My boss would not like losing the information that would be lost moving from our Redmine solution to the current Gitlab 8.14 EE one.

Proposal

Ability to indicate on which date the time was spent.

mentioned in issue #1271 (closed)

added UX label

added Discussion label

@g3dinua : Could you re-iterate what use cases this would be useful for you? Is it more of a review/audit function? I can see that a team lead / manager would want to see this. For example:

• A team lead sees that an issue had 10 hours spent on an issue, but it was initially estimated to just 3 hours.
• So the team lead wants to investigate further and understand why the estimation was off.
• So the team lead wants to dig in and see who spent the time, for what subtasks, when it occurred , under what conditions, etc.

In that scenario, simply looking at the existing system notes, would enable a team lead to recover that history. I can see it might be more easily reviewed in spreadsheet form / table form though.

Is this the idea you were thinking of?

@victorwu we're using Gitlab as our main hub for everything and want to drop down other solution (trello, jira, etc). Gitlab boards perfectly works for us (with estimates and time tracking). We already wrote the system, that query API, parse it and prepare the time sheet similar to .

The main issue we have are related to the accuracy of the reports: people pretty often forgot to log their time on a daily basis. Usually, they do that at the start of next week or at the start of next months. In this case, we have a situation when time spent for one time frame is calculated in another timeframe. If we'll implement this it'll resolve this kind of issues. For example:

• team lead generate reports
• it see that it only starts of the month, but it's already logged more time than hours exists
• So the team lead wants to dig in and see who spent the time, for what subtasks, when it occurred, under what conditions, etc

Our idea is that it would be better to implement & merge this part into Gitlab, rather than implement patch & mantain it for a while. Also, it will be good to discuss if that part of functionality should be implemented in CE edition, where time tracking functionality was introduced.

What are your thoughts about that?

marked this issue as related to #1406 (closed)

@g3dinua : I was thinking we would include this info in the CSV export. That's probably easiest to get into the product quickly. And then longer-term, we could consider how to design inline reports inside the web UI itself.

What do you think about this design?

Each issue would have at least one row in the CSV export. But you would have extra rows for that same issue if there's multiple logs of people logging time spent. For a first issue, perhaps we record time spent entries. And in a subsequent issue, we could also capture when a user records subtracting time spent, i.e. remove_time_spent

@smcgivern : I imagine if we wanted to record something like this, we would have to store every time spent record, which I assume we don't currently? Would that be a problem?

@victorwu @smcgivern right now I want to stay away about details of how we'll display that data (web ui or in reports). In this issue, we discuss an ability to make this command possible: /spend 3d 31-07-2017 Implemented ability to spend time in past. What do you think about this format?

Thanks @g3dinua for clarifying. I think that makes sense as a feature. Sorry I overlooked/didn't understand that you want to set an arbitrary date of logging a time spent. That makes a lot of sense.

From a UX perspective, I really don't like entering date values in text form, because it can get really messy. So I think this really starts getting into the UX realm as we expand the use case.

@sarrahvesselov : What do you think about this feature in general?

I think creating a whole new UI just to enter date values is overkill for a feature like this. I would still like to use quick actions if possible.

@ClemMakesApps : Do you know of a way that we can pop up a date picker UI while typing in a textbox? Similar to how the emoji picker pops up.

What do you think about this feature in general?

Yes, please! Much of my career has been spent logging and reporting time for myself and my team. As @g3dinua said, remembering to log time as the work is done can be challenging. In most environments, accuracy is important. I think this is something we should do.

I think creating a whole new UI just to enter date values is overkill for a feature like this. I would still like to use quick actions if possible.

I think your suggestion to Clement would be a good first iteration. I would very much like to introduce a more robust UI for time tracking in the future. I think it has a lot of value and would be worth the effort.

Do you know of a way that we can pop up a date picker UI while typing in a textbox? Similar to how the emoji picker pops up.

Should be do-able. Similar to how we have auto-complete for usernames, you're wanting to show a dropdown with a datepicker?

So right now it seems we need to clarify next things:

• how this quick command should look (and think about backward compatibility);
• how this dates should be stored in the database;
• how UX should look;

how this quick command should look

According to https://docs.gitlab.com/ce/workflow/time_tracking.html & https://docs.gitlab.com/ce/user/project/quick_actions.html seems like format, that working for everyone is:

/spend <time> <date>

how this dates should be stored in the database

right now I see 2 options here:

• introduce new date field
• use that custom date as value for updated_at/created_at

From my perspective, it'll confuse people if we'll use updated_at/created_at for this purpose, but I'm not sure if it's acceptable to introduce new field. @smcgivern @victorwu can you suggest?

how UX should look

I really like an idea with calendar dropdown (like we had for usernames, issue numbers, etc), so we need to decide which symbol will trigger that dropdown. @ClemMakesApps @sarrahvesselov, do you have any ideas?

so we need to decide which symbol will trigger that dropdown

My go-to would be a calendar icon. Do we have a GitLab calendar icon designed @hazelyang?

@g3dinua @sarrahvesselov @ClemMakesApps : I was thinking that we wouldn't even need a calendar symbol.

@ClemMakesApps : Could you just type /spend 2h and right away the datepicker UI would appear?

@smcgivern : Any problems/ideas on storing the date for when the time spent is entered?

I was thinking that we wouldn't even need a calendar symbol.

That makes sense if the datepicker appears after typing /spend 2h @victorwu.

My go-to would be a calendar icon. Do we have a GitLab calendar icon designed

@sarrahvesselov We have this calendar icon -->

@sarrahvesselov @hazelyang to be clear, I think @g3dinua is referring to a keyboard symbol here, like we use # to load issue autocomplete. I guess we could use the emoji for that, but I'm not sure we need anything: I think a first iteration here would just be to get people to type the date in YYYY-MM-DD format, and reject if it doesn't match a valid date.

From my perspective, it'll confuse people if we'll use updated_at/created_at for this purpose, but I'm not sure if it's acceptable to introduce new field

@g3dinua it's totally acceptable to introduce a new field for this We can call it spent_at, or something, and fall back to created_at when it is NULL (for existing records).

I think a first iteration here would just be to get people to type the date in YYYY-MM-DD format, and reject if it doesn't match a valid date.

I assumed that this approach would incur more work (with the date parsing and validations), and it would be better to just build the date picker UI right away. But if this is the better choice initially, I have no problem with it.

@sarrahvesselov @ClemMakesApps : Do you want to make the final call?

From a usefulness perspective as an MVP, we should expose this information via system notes, as we won't have any place to display this info initially. (Next issue being exposing it via an CSV export for example.) But I don't want to build some data entry feature where you don't actually see the data back.

I think @g3dinua is referring to a keyboard symbol here, like we use # to load issue autocomplete.

Ah, makes sense. I read symbol and my mind went immediately to icon.

@ClemMakesApps, you make the final call on this one

I assumed that this approach would incur more work (with the date parsing and validations), and it would be better to just build the date picker UI right away. But if this is the better choice initially, I have no problem with it.

@victorwu whichever way we do this, we have to send the result as text, so we need the validation anyway.

I'm not really convinced that we need another shortcut character like we have for # because we already have so many.

I haven't dived deep into gfm autocomplete, but I think /spend <time> <date> is fairly do-able. It might be easier to separate it out as two commands though.

@smcgivern going to start with this issue. Will implement the first iteration without date picker (just basic logic with validations) and will create separate MR with UI, when everyone will be on the same page about the shortcut character

@g3dinua awesome, sounds great

mentioned in merge request !3044