Issue time estimate, meaningful time tracking

[stuzer05]

This pr does:

1. Adds functionality to set estimated time for issues similar to Jira (in "1w 3d 15h 30m" format)
2. Now it's possible to view exact tracking time both logged, total and per-user (estimated time is not useful for tracking)
3. Replaces Stopwatch "Add time" form from Hours and MInutes to Jira-like input in "1w 3d 15h 30m" format
4. Adds ability to localize all time tracking issue comments in the future
5. Removes meaningless seconds from tracking display information
6. Makes time logging comments the same style as other comments (no new line and icon)

Why?

Time estimation is essential for some teams to know the importance of issues, the amount of effort an issue would take. And for business to know if it's profitable to spend money on developers time to implement an issue

More info on https://support.atlassian.com/jira-software-cloud/docs/estimate-an-issue/#Concepts-about-estimation

Closes #23112

[yardenshoham]

I suggest you remove the issue number from the title and add Closes #23112 to the PR description. Also mark this PR as draft while you're working on it.

[stuzer05]

Ready functionality for the moment:

• Time estimate tracking
• Time tracker "Add time" input has been changed to match the one in Jira (e.g. "1h 50m")

Empty issue

Setting time estimate

Removing time estimate

Adding time to time tracker

[stuzer05]

I also think time tracker should display the real time spent, not estimated. Otherwise, there is no way to see what time was actually spent on an issue. And the time in comments should be localized as well.

Should I change that? @yardenshoham @wxiaoguang

[wxiaoguang]

I also think time tracker should display the real time spent, not estimated.

There is a Time Tracker feature (Enable Time Tracking on the repo setting page), does it do the same thing?

And the time in comments should be localized as well. Should I change that?

IIRC there is a HTML tag and JS for similar work. I am not sure whether it could help.

[stuzer05]

IIRC there is a HTML tag and JS for similar work. I am not sure whether it could help.

All arrows pointing to time logged but not localized

The blue arrows pointing to the places where the real time should be displayed (the real value was "2w 15h" or smth)

[stuzer05]

There is a Time Tracker feature (Enable Time Tracking on the repo setting page), does it do the same thing?

It's not always convenient to use a timer based time tracker but log time post-factum. It should be displayed fully in the comments

[wxiaoguang]

There is a Time Tracker feature (Enable Time Tracking on the repo setting page), does it do the same thing?

It's not always convenient to use a timer based time tracker but log time post-factum. It should be displayed fully in the comments

I am not a real user of such function, so I couldn't suggest more 😁 maybe you could try to write a detailed design document (in the PR main comment), then many people who have similar experiences could help.

[stuzer05]

There is a Time Tracker feature (Enable Time Tracking on the repo setting page), does it do the same thing?

It's not always convenient to use a timer based time tracker but log time post-factum. It should be displayed fully in the comments

I am not a real user of such function, so I couldn't suggest more grin maybe you could try to write a detailed design document (in the PR main comment), then many people who have similar experiences could help.

Well, I'm not proposing a functionality change in time tracker. It's good as it is. However, it has 3 critical design flaws.

1. There's no way to view precise logged tracker time in comments (only estimated)
2. There is no way to view total time spend on an issue (only estimated)
3. Time tracker has no translations what so ever

Estimated time is not useful for anything and should be used for display purpuses only. Like "1 year ago" beside every issue comment

[stuzer05]

The only thing I cannot figure out yet is how to make utils.SecToTime language-aware? How to call localization function outside of templates? @wxiaoguang

[wxiaoguang]

The only thing I cannot figure out yet is how to make utils.SecToTime language-aware? How to call localization function outside of templates?

If I remember correctly, there is no such support yet.

[stuzer05]

If I remember correctly, there is no such support yet.

Alright, I'll figure something out!

[yardenshoham]

There's a proposal https://github.com/tc39/proposal-intl-duration-format

[stuzer05]

There's a proposal https://github.com/tc39/proposal-intl-duration-format

Awesome. Shoud I use it instead?

[yardenshoham]

It's not part of javascript yet

[stuzer05]

It's not part of javascript yet

Then I'll use back-end localization for now. Gitea has all the necessaary translations already

[wxiaoguang]

Thanks for asking review from me, but my review doesn't count, and I am not a real user. Maybe maintainers could help.

[yardenshoham]

I don't have enough knowledge about the codebase to approve

[jolheiser]

I really think this should gather more feedback, either here or in the linked issue (like @wxiaoguang mentioned above with a design document)

As I said in the issue, I'm certainly willing to defer to the community, but I don't (personally) understand the value of this. I am obviously not a one-man roadblock, but I am curious to know what others think.

---

To clarify, I just want to make sure this is something that will get merged before you spend a lot of time on it. I am of course very glad you want to help with the project. 🙂

[stuzer05]

I really think this should gather more feedback, either here or in the linked issue (like @wxiaoguang mentioned above with a design document)

As I said in the issue, I'm certainly willing to defer to the community, but I don't (personally) understand the value of this. I am obviously not a one-man roadblock, but I am curious to know what others think.

To clarify, I just want to make sure this is something that will get merged before you spend a lot of time on it. I am of course very glad you want to help with the project. slightly_smiling_face

Sure, I tried to explain why this feature is needed both in this pr and the issue. Besides, this pr also is a quality of life update for already existing time tracking.

[yardenshoham]

Also after this: https://github.com/go-gitea/gitea/blob/f4920c9c7f5947d3b6476610f39bc3492ab4ef3b/models/migrations/migrations.go#L469

[stuzer05]

Also after this:

https://github.com/go-gitea/gitea/blob/f4920c9c7f5947d3b6476610f39bc3492ab4ef3b/models/migrations/migrations.go#L469

Done!

[yardenshoham]

Your functions should actually be in a new file v245.go, don't modify old migrations

[stuzer05]

Your functions should actually be in a new file v245.go, don't modify old migrations

Good point! Done

[wolfogre]

I agree with @jolheiser's comment on https://github.com/go-gitea/gitea/pull/23113#issuecomment-1444098901.

I don't fully understand the value of this feature either. To clarify, I don't believe it's entirely useless, but I am uncertain whether it's worth the effort. It's not just about one PR; there's also the matter of maintaining the feature and ensuring API/Cli support in the future. Reverting it would be nearly impossible once a new CommentType is introduced.

As @jolheiser said, this should gather more feedback.

---

Moved to https://github.com/go-gitea/gitea/issues/23112#issuecomment-1446071127

[stuzer05]

I agree with @jolheiser's comment on #23113 (comment).

I don't fully understand the value of this feature either. To clarify, I don't believe it's entirely useless, but I am uncertain whether it's worth the effort. It's not just about one PR; there's also the matter of maintaining the feature and ensuring API/Cli support in the future. Reverting it would be nearly impossible once a new CommentType is introduced.

As @jolheiser said, this should gather more feedback.

Well, this feature is the only thing which is missing for time tracking, concidering there's another issue which adds statistics https://github.com/go-gitea/gitea/pull/19808 , this would greatly improve functionality of gitea in terms of replacement many other systems like Jira. Besides, time tracking is already an optional thing in gitea. Honestly, I don't see an issue to make time traking complete

I would love to maintain this feature. I use gitea for a long time already

[codecov-commenter]

Codecov Report

Merging #23113 (fd5adc5) into main (443dcc2) will increase coverage by 47.41%. The diff coverage is 42.34%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

@@            Coverage Diff            @@
##           main   #23113       +/-   ##
=========================================
+ Coverage      0   47.41%   +47.41%     
=========================================
  Files         0     1140     +1140     
  Lines         0   151159   +151159     
=========================================
+ Hits          0    71676    +71676     
- Misses        0    70998    +70998     
- Partials      0     8485     +8485     

Impacted Files	Coverage Δ
modules/structs/issue.go	67.56% <ø> (ø)
modules/templates/helper.go	43.63% <ø> (ø)
routers/web/repo/issue.go	36.11% <0.00%> (ø)
routers/web/repo/issue_timetrack.go	0.00% <0.00%> (ø)
services/forms/repo_form.go	39.50% <ø> (ø)
services/issue/issue.go	29.89% <0.00%> (ø)
models/issues/issue.go	51.64% <22.72%> (ø)
models/issues/comment.go	48.71% <100.00%> (ø)
models/issues/stopwatch.go	57.28% <100.00%> (ø)
models/issues/tracked_time.go	66.50% <100.00%> (ø)
... and 1142 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[lunny]

Maybe we need a better sidebar design, there are too items for time.

[stuzer05]

Maybe we need a better sidebar design, there are too items for time.

I'd would love to work on new time tracking/estimate ui in the next pr, since I don't have ideas just yet and I'm really tired of merging conflicts from the main branch. Merging this one would be of huge help tbh 😅

[wxiaoguang]

@go-gitea/maintainers especially @go-gitea/technical-oversight-committee

Go or no-go for this PR? I know there were some discussions, but I think there is still no clear conclusion.

Since this PR is still active and well-maintained, from my perspective, if some nits could be fixed and some core code could be well tested (by test code), I think it's good to have.

But before spending more time on improving and writing more test code, could there be a clear conclusion? To save everyone's time.

[lunny]

I would like to have this feature but I think something needs to be adjustment and discussed. If we have this feature, generating a gante graph will become possible?

• What's the relation between due date and estimate? Looks like both them are for planning. Or maybe we could just have a plan start date?
• If we have estimate, then the issue siderbar will have estimate, track time and due date. I would like have a careful UI design to make it more clear, organized and use less places.