Read on Twitter
I was asked by @OllieNorris about how I decide when a task is set to WNF (will not fix). It's a case by case thing, but there's a basic set of principles.
As a rule we want to avoid setting any task to WNF . But in reality some low prio tasks will just keep getting reassigned to a future update but may never get done.
This is the fate of tasks that are low prio (so low impact or don't impact many players) but not trivial fixes. There will be hundreds of these. Whereas low prio easy wins will usually get done.
If I can't get a fix in an update I would rather keep assigning it to a future update than give up on it. If it can be fixed then let's plan to eventually do it when someone has the time.
Generally I only set tasks to WNF given four scenarios. One, the fix is way too risky because it's major surgery and the potential risks to create new issues are too high to justify the chance.
Two, the cost is too high to justify the fix. If will take someone a month to fix a trivial issue then I can't justify it, because there will always be new work or other fixes that is a better use of the developer's time.
Three, there is no one to assign the task to. This only tends to happen late in a game's life as people roll onto other projects. It's the ultimate fate for most low-prio, non-trivial tasks.
Four, the feature is not performing properly but the player's actually prefer it that way, or it's been around so long and almost no one notices so you may was well leave it. This happens way more than you know.
In summary, I assign WNF to very few tasks, I keep assigning unfixed tasks to the future in the hope they can done some day. But eventually realities will kick in where I am confident enough that it will never get fixed and close the task.
Deciding what needs to be done by launch or pushed post-launch follows a similar formula. Assuming the launch date cannot be moved that is (which I assume until someone tells me otherwise).
