Are you wondering what the team is up to right now? Well, along with many other teams in the Developer Division, we are feverishly working to bring you our next Beta.  We've been in what we call "Ask Mode" for four weeks now and have only taken around 65 fixes in that time. We still have 50-100 bugs that we would like to fix before we ship the Beta, but we are near the point where the overhead of Ask Mode is limiting our ability to do work for the product in whole.  Ask Mode is the point where teams have to "ask" to make changes - even bug fixes - to the product.  We are in shut down stabilization and we evaluate every change very closely to minimize the risk to this stabilization.

There are usually two stages to Ask Mode - product team level and division level. In the former the product team (so, the VC++ team) ultimately decides which bugs can get fixed; in the latter, our team has to ask approval at the division level to make changes.  At both the product team and division levels, you have a group of people making the decisions that represents each area of the group,  each function of the group and in some cases the managers for the group.  The division group is basically made up of the division release team and product team reps.  The product team reps are generally box PMs, test managers and some dev managers.  Together we work on stabilizing together so we can eventually sign off and ship!

I'll say here that I owe you a post with an overview of the milestones that we use at the present time.

To get more specific about what our team is up to, I can tell you that we tend to see the product shut down in a sensible way - the "back-end," or, code-gen and tools team tends to shut down first, with the "front-end," or language compiler, not far behind.  The libraries and IDE teams tend to stabilize after the base stops moving.   We meet each morning for a team triage of Ask Mode issues and decide which fixes we want to take to the division triage in the afternoon.  We discuss a lot of things: the customer scenario and how common we think it is, whether or not the problem is a regression, what root cause for the problem is, the code diff for the fix, the testing coverage, the risk of the fix and the impact of not taking the fix.  All of this information together with a "bug bar" helps us make our decision.  A bug bar is a list of criteria that describes the kinds of bugs we should be fixing at this point of the Beta cycle.

The test team is completing a full test pass (full meaning they run every test they have including manual test cases) to report a full status of quality.  We track quality on several different metrics, and that is another post I will owe you (or maybe I'll revive the Five Testers from VC to tell you about the metrics!).

april