How to people ensure good use of Won't Fix across multiple teams


I was wondering how people working with several teams ensure that issues are not closed as Won’t Fix when they shouldn’t, and its use is consistent across the teams. Do you, for example, ask members of other teams to review issues closed as Won’t Fix on a regular basis? Or have certain senior developers notified when issues are closed as Won’t Fix so they can review them? Or restrict permission to close issues as Won’t Fix to a few senior developers? I’ve tried different mixes of these and not yet really stumbled on something that works really well and consistently yet.

1 Like


Thanks for asking the question. It’s a good one.

Could you share why the things you’ve tried haven’t worked? Is this a process problem, a tooling problem, or maybe a people problem?


1 Like

Hi Ann

Yes, it is much more of a people and process problem than a technology problem. In this case, it is balancing team autonomy with consistent high quality levels across teams, and having enough reviews in place without them becoming a process bottleneck. Much more a question of how best to use the Won’t Fix features than the features themselves.

The only improvement in the tool I can think of that might help is to make it easier to set notifications of Won’t Fixes for a group of projects or a whole portfolio. It is super easy to do it for individual projects but not so easy if you have 20 or 30 projects in a portfolio that you want someone to keep an eye on, and I certainly don’t want notifications for all 5000+ projects in our server :blush: