time estimation rule on issue with priority-1 + bug labels?

[SimonLab]

Do we want dwylbot to remind the user to add a time estimation on an issue with a priority-1 and bug labels? These kind of issues might be difficult to estimate if the bugs are still investigated.

[samhstn]

My preference would be that in this scenario, dwylbot shouldn't comment

[SimonLab]

I would still add an estimation to the issue. I think this can give a first idea how long the task might take and the estimation can still be updated later on. But I also understand that dwylbot can be a bit annoying on this kind of issue. Maybe another type of message in this situation? "Keep calm and debug. Everything will be fine :+1: (any time estimation for this issue?)"

[nelsonic]

@SimonLab great question! IMO even if there are many unknowns/uncertainties that require investigation, we should still try to estimate the time required to solve the issue, even if we end up being wildly incorrect. What we need is to:

• [ ] collect as much information as possible about the issue/bug before estimating to maximise our understanding prior to estimation.
• [ ] make it clear to both the client and team that there are still unknowns and communicate what we are attempting to do to resolve the issue.
• [ ] ask for help when the "clock" on your original time estimate runs out! (_@dwylbot could even apply the help-wanted on a P1 after the time estimate label (time allocation) expires. 😮 💡

For example: I estimated that this (P1) issue/task would take me T1d to complete: https://github.com/healthlocker/healthlocker/issues/879 but it has taken me Two Days and I'm still not finished resolving it!

I have been writing comments as I go to keep the team informed of what I'm trying. I think time estimation is a fundamental communication tool we have when working in teams. (even if the "project manager" then keeps asking "is it done yet" ... "will it be done today" ... "what's the status of X" ... because they don't understand how debugging works!!)

If we estimate that something will take T1h and it ends up taking T4h, we should leave a comment explaining why it took longer so everyone is aware of what the complexities are/were.

One of the biggest benefits is that we have a "Scrum Master" who writes code and understands that debugging is not "easy to estimate".

So: @dwylbot should should still comment on P1 if no estimate is given, but should delay commenting for 30mins to avoid "fanning the flames" of the "Production Bug".

[iteles]

:arrow_up: @nelsonic I like that, best of both worlds, a good starting point to test.

[ghost]

Closing as this question was suitably answered