Welcome to EMC Consulting Blogs Sign in | Join | Help

SSIS Junkie

Commendable transparency from the Visual Studio team

I spend a fair bit of time on this blog negatively criticising the various product teams within Microsoft when they do something that I think is worthy of that criticsm. Hence, its only fair that I criticise positvely as well. This blog entry is one such critique.

Today I raised an issue on the datadude forum concerning a very minor improvement I'd like to see made to the product. Following a reply from Gert Drapers I then made this Connect submission requesting that the behaviour be changed. Following that Jeff Welton from the Visual Studio team posted this reply:

Here's an opportunity for me to add some transparency on how our internal team processes work and what that means for our customers.

Jamie raised this issue to us through the Connect site (connect.microsoft.com), and from there the bug found it's way to the DB Pro team.  Once the bug was put into our team's bug database, it awaits a decision from the Triage team, which is made up of 3 senior members of the team and of which I am a member.  For those unfamiliar with the triage process, the triage team reviews all bugs and suggestions from internal sources (usually our QA and Dev teams) and from external sources (Connect, MVPs, field reps, etc.).  We review each bug trying to gauge the answers to the following key questions:

  • Is the bug real or does the suggestion point out a real design hole?
  • What is the impact of the issue?  How many customers does it affect and how deep is the affect?
  • How does the issue compare in severity and priority to the other work items and bugs that we have and anticipate in the foreseeable future?

As you might expect, there's at least as much art as science in the process.  We make our call on the types of questions I mentioned and either accept the bug or suggestion for work or resolve the item as 'by design' (the bug is not real but rather a misunderstanding of the product), or 'won't fix' (the issue is real but we judge it to be of low impact; it would not receive our attention in the foreseeable future).  There are other resolutions that are used less frequently, but you get the idea.

In the case of this particular issue, we triaged the item and determined a resolution of 'won't fix' due to the low impact we perceived and lack of votes for the issue in Connect (we look at votes when we are undecided about an issue or leaning toward rejecting it as an additional datapoint on the breadth of impact the issue may have).  All of this is, of course, a judgement call.  As QA on the team knows, a rejection from triage is not necessarily equivalent to stone tablets coming down the mountain, but rather 'pushback' from triage, meaning "We're not convinced that this bug is impactful enough to meet the bar.  You'll have to give us new data to change our minds".  From that point the tester that entered the bug can either agree with triage and close the issue or decide (with, perhaps, some justification Wink) that triage is peopled by chowderheads who missed the big picture, provide more data, and ask for reconsideration (if the tester feels strongly, we encourage them to show up at our daily triage meeting to add detail in person; tragically, we can't afford that opportunity to our valued Connect bug authors Smile).


Anyway, these are the takeaways that I'd like our customers to have from this:

  • We really do review all Connect bugs that come to us, right alongside other bugs/suggestions that the team files.  The fact that the issue comes from a current or potential customer does add weight to the issue.  As you hit bugs or just points of frustration with our product, I encourage you to let us know about them through Connect.
  • Though it is a secondary data point, we do pay attention to votes that a Connect issue receives (or fails to receive)
  • Triage is open to pushback in the form of new data, additional scenarios, etc.  If we've rejected an issue and you don't feel that we properly understood the context, severity, or breadth of impact of the problem, please reciprocate our pushback with some pushback love of your own.  The key, again, is to have those additional data or scenarios. 

Providing information about internal processes even when that information is not requested is welcomed. Transparency of this order is not something we have come to expect from the Redmond behemoth. For that, thank you Jeff.


Published Thursday, October 25, 2007 9:47 PM by jamie.thomson
Filed under:



Jason Haley said:

October 26, 2007 4:28 PM

Buck Woody said:

I try to do the same thing with transparency since I've been here (about a year now) over on the SQL Server Management Studio (SSMS) side. I'd love to hear what you think:


- Buck

October 26, 2007 5:03 PM

bharry's WebLog said:

I've blogged a fair about over the past couple of years on transparency in our process. I've also advocated

October 29, 2007 2:36 PM

Darren Gosbell [MVP] - Random Procrastination said:

SSAS: What changes would you like to see?

November 11, 2007 9:46 AM

bharry's WebLog said:

この 2 ~ 3 年、私はかなり頻繁にブログで自分のチームの透明性について書いてきました。社内でも積極的に透明性の重要性を主張しています。今日紹介するブログに注目したのは、透明性に関する優れた見解が述べられており、ユーザーから

April 24, 2008 6:03 AM
New Comments to this post are disabled

This Blog


Powered by Community Server (Personal Edition), by Telligent Systems