How To Provide Product Feedback & Suggestions For WPF CTPs and Betas
There are multiple ways customers can provide feedback and suggestions for Windows Presentation Foundation:
- getting hold of that elusive Avalon developer in a conference like the PDC
- posting comments on an Avalon developer's blog
- posting on the WPF Newsgroup, or
- posting on the WPF Forum, or
- submitting suggestions or reporting bugs on the Product Feedback Center
Here are some best practices on providing feedback, no matter what the forum is:
- Search existing items. Some issues occur widely enough that others have faced them before you. Upon searching for bugs with your symptoms, you can vote on them rather than enter an issue afresh. In addition, you can track reported bugs.
- Provide a meaningful title. Concise yet meaningful titles help route your issues to the right teams the fastest. Without one of these, the initial reviewer must read through the bug description and make a best faith effort to understand exactly what feature area owns the issue. Given a platform like WPF and the inter-relatedness of features, this can be a hard thing to nail down. So on some occasions I've seen a bug goes from triage alias to triage alias until someone identifies it as their own. Meaningful titles also help you and others search for issues easily.
- Provide clear steps to reproduce the bug. This is relevant if the issue you're reporting is a bug rather than a feature request. Providing crisp steps helps the feature team in its first step of validating the issue. Some tips:
- Use an ordered list with one item for each logical step. This makes it easier to read, convey on the phone or via email
- Mention if the problem is consistently reproducible or not
- For install or setup issues, I recommend attaching the install logs or even relevant snapshots. Look in your %temp% folder for files with "dd_" prefixes in their names
- For compile or build issues, I recommend attaching build logs. The MSBuild system supports logging with various verbosities (by using the /v:
switch on the command line or setting appropriate level within an IDE like Visual Studio).
- Provide environment information. Be sure to mention the build number or CTP name, product mix you have installed (e.g. "I installed WinFX Runtime Jan 06 CTP and Windows SDK Jan 06..."), your OS platform, CPU and bitness (e.g. "... on Windows XP SP2, Pentium III, x86"). Given that WPF is a presentation platform, it helps to provide information on your graphics card and if you have the latest video drivers installed.
- Provide solution or project information.
- Specify whether you're trying to build an application or a library.
- Is it a browser-hosted app or installed?
- Provide information on your MSBuild/Visual Studio/Sparkle solution or project (is it a single project or a solution with multiple dependent projects etc.)
- Did you specify a UICulture in your project? What about the neutral language setting in the AssemblyInfo.
- Tell us how the bug impacts your scenario or your product. This aspect, often ignored, is one of the key parameters that help the feature team decide if, when and how we should fix the problem or if we should just publish information on workarounds. Ordinarily crashes and data loss scenarios are easiest to prioritize, because of their impact. Some bugs however only show up in corner cases. But one man's corner case is another man's mainline scenario. So some context like this helps us immensely in making the right decision.
Thank you for your continuing feedback and support. You only have to look at the features that got added into WPF after our first public CTP, and you'll know we hear you loud and clear!