The PFC and Transparency

Josh Ledgard wrote a great 4 part series on transparency and implications for customers and corporations. The PFC is an excellent study of the points on benefits and fears associated with increased transparency.

The PFC by nature exposes all the problems in the product as perceived by customers (aka bugs). Publicly listing all your faults would seem like a recipe for disaster. But when the product developers have an opportunity to respond to each issue providing rationale or a fix, there is an opportunity to swing the pendulum of public perception. Fixing a customer issue and being responsive and human is the key. So how are the Microsoft responses to PFC bugs and suggestions affecting perception?

Text alone is a difficult medium for communication at times. Brevity or certain wording can be perceived as rude. Giving a long and thoughtful explanation to an issue can score big points.

A few questions for discussion:

What is your current perception of Visual Studio and Microsoft?

How has this perception been affected (positively or negatively) by the Microsoft responses to PFC issues?

As users of the PFC, what score do you give Microsoft overall for the quality of responses?

Do you feel you have a better understanding of the internal workings of building Visual Studio via the responses to bugs and suggestions so far?

Comments

• Anonymous
  January 10, 2005
  The openness of the PFC really raised my opinion of the development process for Visual Studio 2005... I wish it were available sooner in the cycle so really really good suggestions (like this one: http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=fb7b3c93-a9e9-418b-85b3-b67a195c7e1a ) would have had a shot at inclusion in the product.
  
  It is great to have, now that we have it :)
  
  The responses from Microsoft to various bugs are mixed in quality. The best ones usually include the name of the person responding, and a blog link so we can see further into how things work. The system-generated responses are not very helpful... with certain ones (see devdiv schedule link under links tab) being totally useless and confusing to people on the outside.
• Anonymous
  January 10, 2005
  Ryan,
  
  What do you think about response quality from community (me ;-) at your reports
  http://lab.msdn.microsoft.com/productfeedback/ViewFeedback.aspx?FeedbackID=FDBK17963 and http://lab.msdn.microsoft.com/productfeedback/ViewFeedback.aspx?FeedbackID=FDBK17964 ?
  
  ;-)
• Anonymous
  January 10, 2005
  The comment has been removed
• Anonymous
  January 11, 2005
  Thanks for your comments.
  
  Regarding suggestions, internally, we too wish the PFC had been ready earlier in the cycle, it just happens that was when the project got off the ground. It's with great disappointment on our side as well to not have the time to implement many of the great ideas customers have submitted.
  
  For the next version of VS, the PFC will be available earlier in the process. We expect more suggestions to be resolved “fixed” when we do that.
  
  We've long been observing that the PFC process for bugs does not work as well for suggestions. We want to track suggestions as a running list that lives independently of any specific release. We don’t want people shooting down suggestions quickly simply because they are busy shipping the current version.
  
  Also, keep in mind that any suggestion resolved as Postponed will be considered again for the next version.
  
  
• Anonymous
  January 13, 2005
  "We don’t want people shooting down suggestions quickly simply because they are busy shipping the current version. "
  
  I completely agree. Rather than forcing "won't fix" or "postponed", a better design would be to have a version list ("Whidbey", "Orcas", "Post-Orcas", "Probably Never").
  
  I think after VS 2005 ships, the groups will have to sit down and review every single one of the suggestions and put them into one of the categories I just mentioned.
• Anonymous
  January 13, 2005
  The comment has been removed
• Anonymous
  January 13, 2005
  I love the idea of changing the suggestion resolution's from won't fix and postponed to a more version specific timeframe... though even that would be a best guess and "goal" as opposed to hard commitment. We've discussed for a while changing the resolution text for suggestions because the one's used for resolving bugs are confusing.