OK, now that I have fessed up to having a lame excuse, I will state it without further fear:
During much of September, my team-mates and I have been busy trolling forums and our inboxes for bug reports from customers in addition to copious ones that our QA team contributes. We wanted to get as many of them fixed as we could without doing radical changes that would impact the stability. Now that we are practically out of time for fixing any more bugs, I can turn my attention back to this blog.
But first a bit about the process itself:
We are constantly torn between users who chide us for not providing a "go live" license with our preview which our QA team hasn't even touched and users who admonish us for shipping products that have bugs. We can't satisfy the former due to our conscience (yes I do have one I think) and the latter due to practical impossibility. So we do what mere mortals have to - manage components to a schedule. The price of being on a train like Visual Studio 2008 is to satisfy the authorities like the station master and the conductor. You have to get a ticket, get on the train in time etc.
The last phase before the metaphorical train can leave the station involves something along the following lines:Each component team has to make a "triage" decision about bugs that can and should be fixed vs. features that can be done in another release and bugs that can be postponed because they are either too minor to rise up in priority or too risky for the late stage. The decisions then get communicated to the product unit "ship room" and division's "ship room" as follows:For a while, we are in "tell mode": we have to tell what we are doing and invite comments, scrutiny etc. This pushes component teams to think harder and ensures a consistent bar.Then in "ask mode", it gets more interesting and we have to ask for permission to make any change for a bug fix at all. We present a case for fixing a bug, the actual fix, risk assessment, new tests etc. and then we may or may not get an approval depending on the jedi council's decision.
I can certainly imagine a beta user's frustration who reports a bug that is not fixed by RTM. However, the processes above ensure that the flow of changes is throttled and the product is stabilized so that it can be shipped on schedule.
Anyway, most of the bugs we could have fixed are behind us. Now I don't know if we can take any (and hope there aren't any so heinous that we will be allowed to take them). So I can do a bit more writing.
Apart from bug reports, we also found a constant stream of common questions and sources of confusion. Since I have a significant role in causing the confusion, I figured I will try to atone a bit with a few posts. Here are some thoughts from my side but feel free to contribute more. As usual, I will do the easy ones and leave the hard ones for you to figure out :-)
Now I am digressing so better stop right here.