VS 2005 Beta 1 – How did I do as a tester with my feature ownerships?

  • Article

As everyone else on blogs.msdn.com, I’m really excited about the Visual Studio .NET 2005 Beta 1 release. Yes, even more excited than getting an email from BillG. =)

This is the first product that I’ve worked on from the very first coding milestone to a Beta release, so I want to know how I did as a feature area tester. And as always, feel free to report any accessibility bugs here.

Feature Area Ownerships

1. Window Management Feature Area

  • Tool Window Docking, Dragging, Docking Targets (or Docking Diamonds), AutoHide
  • Full Screen View
  • Tool Window Tabs (the little tabs at the bottom of a tool window that appear when a tool window is docked at the bottom)
  • File Tab Channel
  • IDE Navigator

Note that I do not own the content within any of these tool windows, just their containers, so if you report any issues here about the content within, I may not be able to help you.

Please check out a previous post called New Window Management Features for 2005 for more details.

2. Command Window Feature Area

3. Immediate Window Feature Area

Note how the immediate window is its own tool window now, whereas in Everett, it shared the Command Windows tool window area.

How To Write up a Great bug report for Window Management

Here are some suggestions for writing great bug reports.

  1. Make titles as meaningful as possible. A good rule of thumb that I use is to ask myself, “Two months down the road, if I have to look-up this bug again, what are the keywords I’m going to use to search for it.”
    1. Clear Bug Title: “Dragging a Tool Window to the center docking target in the center of the IDE causes repaint issues” (note: I just made this example up).
    2. Unclear Bug Title: Tool Window Dragging issues. (note: I just made this example up)
  1. Give exact steps to reproduce the issue. Say you found a bug, but wanted to see whether it reproduce after restarting Visual Studio. You’ll want to know exactly what to do at each step to cause the issue to reproduce.
  2. Give as few steps as possible to reproduce the issue. What this means is if the bug can be reproduced without creating a project, don’t include creating a project as a part of the repro steps. If unsure, include it in the repro steps and leave a comment that this might not be required to reproduce the issue. I do this whenever I’m not sure.
  3. Always, always, always attach pictures of any issue with Window Management. If a repaint issue occurs, please capture the image. A picture truly speaks a thousand words. Sometimes, if you have many steps to reproduce the issue, you might want to take a picture of the before screen shot and then an after screen shot. This really helps me and the developer to figure out what the issue is.
  4. Extra credit: Does the issue only reproduce with this tool window or with any tool window. If it reproduces just with this tool window, put comments “this only repros with Solution Explorer.” If it reproduces with any tool window, use repro steps like, “Step 1. Drag any tool window….”

Where To Report Bugs

Check out the new MSDN Product Feedback Center. Here, anyone can report issues, bugs and suggestions on Visual Studio 2005 (Whidbey) and the .Net Framework 2.0!

In addition, check out the MSDN Product Feedback Center Blog! Marie, a VS Core Program Manager working on the MSDN Product Feedback Center team, is my office-mate, so I know she would love to hear your thoughts!