Avoiding Duplicate Work

[callahad]

Coming out of the 1.32 Retro, we had at least two occasions where duplicate work occurred because it wasn't clear someone else was also looking into the same topic at the same time.

How can we make it more visible when someone is taking on an issue / a review / etc?

[callahad]

One way I've seen this work in the past is to use the assignee field as a lock: whenever you're working on an issue, start by assigning it to yourself. If you need someone else's input to move things forward, assign it to them. Basically, assume that assigned issues are "taken" and actively being worked on.

What do y'all think of that model for Unit?

If so, existing issues will be a problem. Right now we have 216 open issues, and 84 of them (~40%) are assigned to someone. I sincerely doubt we have 84 work items in flight. What should we do?

[Jcahilltorre]

They way I use the assignee field in Jira is slightly different: The assignee is the person responsible of driving the ticket to completion but not necessarily the person working on it. This means that while I can ask for assistance on an issue, it's my (the assignee's) responsibility to keep the ball moving, make sure the ticket is updated, etc.

That does not prevent the ticket being re-assigned if the work completely moves to a different member of the team.

To keep track of knowing if the ticket is being worked on or not we don't remove the assignee, as Jira has a status field (in progress/on hold/...)

[ac000]

On Sun, 10 Mar 2024 21:22:54 -0700 Dan Callahan ***@***.***> wrote: One way I've seen this work in the past is to use the assignee field as a lock: whenever you're working on an issue, start by assigning it to yourself. If you need someone else's input to move things forward,

For me, that is _generally_ what I do now...

assign it to them. Basically, assume that assigned issues are "taken" and actively being worked on.

Hmmm... (for some description of 'actively')...

What do y'all think of that model for Unit? If so, existing issues will be a problem. Right now we have 216 open issues, and 84 of them (~40%) are assigned to _someone_. I sincerely doubt we have 84 work items in flight. What should we do?

Some of those are certinaly longer term maybe nice to have things...

[javorszky]

I like @Jcahilltorre 's process around assignees. I am generally for making sure that the ticket / issue is seen through to completion, each one of us will be required to do team coordination things (comes in handy with different sorts of career progression if that's your jam), and management has one person to ask "hey what's the status", and new folks have one person to ask "hey how can I be of service?"

The caveat is that fairly regular updates / health checks on the ticket / issue are a good idea. Even if nothing changed since 4 weeks ago, if there's an up to date ping that "yeah, still waiting on ", it tells me that it's still blocked because we checked, rather than we've forgotten to check about it.

[ac000]

I think the person doing the work should be the assignee, but you can of course assign multiple people (up to 10).

The caveat is that fairly regular updates / health checks on the ticket / issue are a good idea. Even if nothing changed since 4 weeks ago, if there's an up to date ping that "yeah, still waiting on ", it tells me that it's still blocked because we checked, rather than we've forgotten to check about it.

Not too keen on that as that could easily add up to a lot of noise/spam...