Import time tracking from other comment types

[davidscholberg]

Are there any plans for GitLab-Time-Tracking to be able to import time tracking data from (for example) merge request comments or snippet comments?

[StephenOTT]

Ya that should not be difficult to add.

Can you tell me about the use case for time comments in Snippets and MR Comments?
(originally my thinking was that because the Commits would be added, which could have the Time-Comment info, there would be no need to have time-comment support for MR comments.

For Snippets, I also saw snippets as a "example"/clipboard, rather than somewhere where work is done.

[davidscholberg]

Well, let me start by saying that we're relatively new to Gitlab (and by extension GitLab-Time-Tracking), so we're still in the process of figuring out a good workflow and how to properly keep track of time spent.

I suppose tracking the time for snippets is not all that important, since a snippet that takes more than a few minutes to make probably belongs in a README or wiki.

I'm not sure I understand your point about merge requests, however. Are you saying that commit comments can be time-tracked? I just tested this myself on a test commit comment in Gitlab, but GitLab-Time-Tracking didn't pick up the comment.

[StephenOTT]

Ah! yes you are correct. The commit code is not ported (yet) from the GitHub-Time-Tracking app. Not a big deal to bring it over.

If you think you are going to be using commits for time-tracking then i can bring the code back in asap.

But think about your workflow a bit.

Originally issues and milestones were the priority (and i still think its the primary and strongest use case).

Tracking time and budgeting time is much more than just commits. It's meetings, conversations, phone calls, and emails. So it's not just when a develop submits a commit, its when anyone on the time logs time.

There are a few use cases where submitting time-commits makes sense, but I really only see it as a aggregation/in-addition to the Issues and any time-comments.

I would love your thoughts and feedback. The GitHub-Time-tracking and GitLab-Time-Tracking was originally just a proof of concept so not tons of use cases were tested out, but would love to extend and develop further.

[davidscholberg]

Honestly, I agree with you that tracking time in milestone issues makes the most sense.

We'll need to play around with all of this a little bit more in order to be able to provide any useful feedback. We'll let you know in a few weeks how it all goes.

[StephenOTT]

One angle you can also explore (not sure the size of your team or setup), but you can explore what it would be like to have your devs commit through commits + issues (depending on your needs) and make sure they reference the issue in the commit. We can parse that out, and reference the time on the commit directly against the associated issue.

The use case would be if you find your self committing a lot of code, and a lot of hours are being spent (and may even you are doing many commits and you want to track time at a more micro level - like tracking minutes per commits), then you could use issues to track time and budget at a higher level, but use commits for your code submissions that the micro time that goes into that code development.

It is a little more complicated, but there is some merit.

[StephenOTT]

@davidscholberg any more experience you can share? I am planning on doing some work on this repo and depending on your needs, we could look to add some of the functionality.

[davidscholberg]

@StephenOTT so we've been using Gitllab-Time-Tracking a bit more, and there's a couple of things I want to mention.

• Just to reiterate what I said above, we do agree that milestone-based tracking makes the most sense. I don't think there's really a sensible use-case (for us, at least) for adding time tracking to some of the more obscure comment types, such as snippet comments.
• Regarding merge request comments, I think it makes sense to have time tracking in merge request comments for a couple of reasons:
  1. Oftentimes the merge request is when the code review happens, and that can be a lengthy process.
  2. It appears that Gitlab allows you to associate merge requests with milestones, so time tracking comments in merge requests could still be grouped by milestone.

[StephenOTT]

@davidscholberg thanks. Thats great feedback.

Adding merge request comments should not be difficult to do.

[StephenOTT]

@davidscholberg do you see more of a need for the CSV/Excel export, data import into another time tracking app, or having a Web UI for reporting on time?