search

go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
43.23k stars 5.32k forks source link

Issue time estimate, meaningful time tracking #23112

Open stuzer05 opened 1 year ago

stuzer05 commented 1 year ago

Feature Description

  1. Add functionality to set estimated time for issues similar to Jira (in "1w 3d 15h 30m" format)
  2. Allow to view exact tracked time both logged, total and per-user (estimated time is not useful for tracking)
  3. Replace Stopwatch "Add time" form from Hours and MInutes to Jira-like input in "1w 3d 15h 30m" format
  4. Add 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

Screenshots

image image

stuzer05 commented 1 year ago

Added a pr https://github.com/go-gitea/gitea/pull/23113

jolheiser commented 1 year ago

I don't necessarily agree with this, at least not "time as a metric". Many agile/sprint teams use various metrics, some are just numbers indicating "how big of an item" it is. I think think this should take some consideration/planning before adding.

Regarding the UI, I think two boxes with numbers in them isn't initially clear what I'm looking at. As well, what about things that may take multiple days?

Do other users agree and want this? If so, I will gladly defer to the community.

stuzer05 commented 1 year ago

Clease check the pr, there are scheenshots of ready functionality. It makes more sense to set time as jira does in its time tracker (e.g. "2d 15h")

siegenthalerroger commented 1 year ago

I have to agree with @jolheiser that I would be more likely to use a "points" system for estimating the "effort" of an issue, rather than a time value. As part of this feature it'd be great to also have this alternate option available aswell :)

stuzer05 commented 1 year ago

I have to agree with @jolheiser that I would be more likely to use a "points" system for estimating the "effort" of an issue, rather than a time value. As part of this feature it'd be great to also have this alternate option available aswell :)

What "points" are based on? Time estimation is the basic measure introduced in countless development strategies and in business in general

This functionality relates to time tracking, which is also helpful for the statistics. "Points" is kind of a different thing IMO

stuzer05 commented 1 year ago

Time estimation would greatly improve https://github.com/go-gitea/gitea/pull/19808 statistics

untainsYD commented 1 year ago

I do fully support @stuzer05 PR, in my workflow it would be great to have such a feature, maybe it should be optional or configurated via repo settings. This would help in estimating the hours of the sprint.

siegenthalerroger commented 1 year ago

@stuzer05 I agree that it can be a different thing, however in agile methodologies it is abnormal to use concrete time-estimations. Rather techniques such as story points are utilised to represent the effort a given issue will require to solve. Of course, one does not exclude the other but in the context of meaningful time tracking statistics, integrating point systems is highly relevant (statistics for "average time per point", "average time for x point estimated issues", etc.).

stuzer05 commented 1 year ago

@stuzer05 I agree that it can be a different thing, however in agile methodologies it is abnormal to use concrete time-estimations. Rather techniques such as story points are utilised to represent the effort a given issue will require to solve. Of course, one does not exclude the other but in the context of meaningful time tracking statistics, integrating point systems is highly relevant (statistics for "average time per point", "average time for x point estimated issues", etc.).

Yes, there other methodologies, of course. I think points should be a separate issue, as there's so much more to than than this issue could introduce

Viktors-m commented 1 year ago

We use time estimaion in our compny, and we lack time estimation very much in gitea.(( We changed many issue tracking software, and recently switched from jira + gitlab to gitea alone. Time estimation is the only thing missing

amberlex78 commented 1 year ago

Would love this feature to be implemented

wolfogre commented 1 year ago

Copied from the PR:

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 #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

@stuzer05 Never mind, it's just my personal opinion, I may be wrong.

And I may have made a mistake, maybe #23112 is a better place to talk about this.

lunny commented 1 year ago

Maybe a start date or(and) deadline is better than just an estimate time. An estimate time cannot be used with other components of Gitea.

stuzer05 commented 1 year ago

Maybe a start date or(and) deadline is better than just an estimate time. An estimate time cannot be used with other components of Gitea.

Deadline is as completely different thing. Having a deadline you have no way to calculate time efficency for any task. It's just an end date. Meanwhile, estimation is a certain time needed to implement a feature. And estimation time is not related to any deadlines.

emacsway commented 1 year ago

I agree that it can be a different thing, however in agile methodologies it is abnormal to use concrete time-estimations. Rather techniques such as story points are utilised to represent the effort a given issue will require to solve. Of course, one does not exclude the other but in the context of meaningful time tracking statistics, integrating point systems is highly relevant (statistics for "average time per point", "average time for x point estimated issues", etc.).

@siegenthalerroger , are you sure what you're talking about? There are a few quotes from the original source:

Ron Jeffries: "i was there when story points were invented and they are about time, no more and no less." https://twitter.com/RonJeffries/status/1295135210976301057?s=20

Ron Jeffries: "OK, experts who think story points aren't about cost, and that cost isn't essentially time, educate me. What are they, what are they good for, why do we estimate them? In answering, show no concern for the likelihood that I invented them. If I did, I'm sorry now." https://twitter.com/RonJeffries/status/1128296444845330433?s=20

Ron Jeffries: "I may have invented story points. If I did, I am sorry now." https://twitter.com/RonJeffries/status/815924184257851392?s=20

See more info at:

siegenthalerroger commented 1 year ago

@emacsway That doesn't contradict what I intended to say. Story points are an abstraction of time, and as such their integration in a meaningful time-tracking system is important. I am used to using a fibonacci scale for time-/effort-estimations, estimating directly in hours/minutes isn't conducive to such a system. That's all that I meant.

Concretely I'd love to be able to select between 1,2,4,8,16 "points", and having that mapped to some hour amount in order to be used for the time tracking statistics.