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 
) 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 
).
<snip>
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.
-Jamie