tri·age:
At Microsoft triage is a process used to sort bugs. As teams start shutting down the product for a major release, they decide which bugs to fix, which bugs to postpone, which bugs to move to another milestone etc. As you sit in a triage room, knowing your customers is huge as it defines what bugs make it and what dont (because you start prioritizing the bugs with respect to customer scenarios etc). Some calls are easy (the product crashes when you type? Fix it!), and some are borderline. In general you triage bugs with respect to a bar - the higher the bar the less bugs you take and the more serious the bugs you take are.
We've been triaging in C# for a while now and today we had a bug I thought describes some of the pain we feel and the first hard calls we have to make to ship. Essentially we looked at a scenario where a user has code like this:
void B()
{
goto C;
//Some stuff here
C:
return;
}
If you do a rename refactoring on C, its going to fail.
We decided not to fix this bug for several reasons:
a. In the case above its trivial to do a rename
b. Gotos are always in the same method, so a find and replace would work just as well. If you had several gotos in the same method, it would be easy to do fix this.
c. Using gotos is not a best practice and we dont expect significant sets of people to be affected by this.
We agree this is a bug. However, the idea behind triage is to slow down the checkins, so that you dont risk regressions and fix only the most important bugs. We felt this was ok not to fix, since it doesnt do anything bad on a users machine (crash it, hang it, slow down the machine, break a key customer scenario) and we dont think its that common a scenario. Not fixing this bugs, prevents the risk of regression from a fix + frees up a developers time to focus on and fix other higher priority bugs he might have.
