다음을 통해 공유

Connecting With Connect

  • 아티클

Hi Folks,

This post is motivated by some recent discussion I've seen in the various tubes.  I don't mean to be critical of any of what's been said.  Rather I want to shine a little light on our thinking, processes, and tools.  We have been trying to improve how we handle the items that come in through Connect, but hopefully some understanding of how we thing will also help improve communication between the SQL Server community and the engineering team.

First, a caveat:  Some see Microsoft as a collective, but this is far from the truth.  I can speak to how I and my immediate group deal with Connect, and to a lesser extent how the broader SQL Server group works with Connect.  I don't have any clue, e.g., how the Office team uses Connect.

On with the show.

Defects and DCRs

Internally, we have two major categories for issues: defects and DCRs.  Here are some working definitions:

  • A defect is an issue where the behavior of the project does not match what it is supposed to do: it does not match the specification.
  • A DCR---or design change request---is a request for a change in what the code is supposed to do.  This could be a request for a new feature, but it could also be a request for a change in the design of an existing feature.

This distinction is a key one for us.  It is embedded in our bug tracking system, and it affects how we deal with the issue.  For example, as we ramp down towards a release, we're concentrating on fixing bugs, not working on new features, and this distinction helps us separate the two.

In some cases, this distinction is clear:

  • SQL Server crashing is clearly a bug.
  • SQL Server losing data is clearly a bug.
  • A request for a new time interval type is clearly a DCR.
  • Support for a new spatial method is clearly a DCR.

Sometimes, this distinction is not clear, even internally.  Take, as an example, the latitude-longitude ordering issue for the geography type.  Despite the fact that our original behavior did not match many customer's expectations, it was a DCR, not a defect.  More precisely, I think, it was a defect in the spec, but since the code did what the spec said it should, we called it a DCR.

Even fuzzier are issues with some long standing SQL Server behavior that have no real specification.  Take, for example, the issue with IsNumeric Marco Russo raises.  If you want my opinion, IsNumeric is a terrible, terrible function, but its behavior is so ensconced in legacy that it is essentially a spec unto itself.  You want a change?  Excellent: you're sane.  Still, it's almost certainly a DCR in our book.

Then there are the issue that are, perhaps, clear internally, but that aren't clear to anyone outside.  Kent Tegels filed an issue about spatial indexes with an OR clause.  This seems like it should work, but is there a bug or was it not supported by design?  It turns out to be the latter: it's not an unreasonable thing to want, but compromises had to be made in the design in order to put out the release.  More on this in a bit.

Bugs and Suggestions

Hopefully this gives a small picture into how we view various issues internally.  How does this map to Connect?  This, at least, is simple:

  • Bug <--> Defect
  • Suggestion <--> DCR

The actual system for dealing with these issues is complicated by the fact that our internal issue-tracking system is separate from Connect.  So, when an issue comes into Connect, it has to be synchronized with our internal system.

This synchronization has a few quirks.  First, it isn't completely lossless.  For example, Kent's issue above was originally filed as a bug, and became a defect on our side.  It has since been converted to a DCR, but still shows as a bug, not a suggestion, on Connect.  This could lead to differing expectations if we do not properly spell things out in our comments on Connect.

Second, only issues filed through Connect show up on connect.  This is generally desirable from our end, since not every issue should really be published.  On the other hand, this can cause issues when we resolve duplicate Connect items against non-Connect items: the public loses the ability to track the issue, even though it is alive and well.  I generally think the Connect item should be retained, but the general practice has been to keep the oldest item.

Beyond synchronization issues, while our system does tell us whether an issue was filed through Connect or filed internally, it doesn't exactly scream it.  The result is that people may act on an issue without immediately realizing where it came from.  I'll let you determine whether this is an honor or a curse: your issues are surfaced to us just like you're part of the team, but we can sometimes get a bit snarky with each other.

Regardless how you feel about this, it's important to think about how you classify your issue when you submit it.  For example, an item filed as a bug/defect may get closed out if it really should have been a suggestion/DCR---even it it was a very good suggestion/DCR.  The presumption on the part of the person who resolved it would likely be that if you really wanted it to be a suggestion/DCR you would have filed it that way, and that you'll reopen it with the correct issue type if you really want it.

I'm not ignoring our responsibility, here: we should be better about handling these items as well.  Our initial communication on Kent's issue was not what it should have been, and he was right to call us on it.

Connecting with Connect

I've found the connection fostered through Connect to be very valuable, and so I want to keep encouraging you to keep file issues, both bugs and suggestions.  We do read them and they do have a huge impact on product development.  Try to be mindful of how we deal with these issues, but don't worry too much: it's much better to file an issue slightly incorrectly than to not file it at all.

For our part, we'll try to continue to improve both the quality and timeliness of our responses, as well as to be more mindful of the fact that the community has imperfect information and can't read our minds.  We aren't as transparent as we could be, but we're working on it.

 

Cheers,
-Isaac

Comments

  • Anonymous
    August 15, 2008
    Isaac, thanks for your message. I know (and I admitted in the post) that the specific case of IsNumeric was not the right one to raise the issue of the "by-design" issue. However, is the "by design" answer that is irritating by itself, for the reason I explained. If you want a more concrete example of a bad use of the "by design" answer, take a look at this one: https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=262197 A Service Pack 2 on a server product (SSAS) that breaks a working feature of a recent client product like Excel 2007 cannot be called a "feature by design", whatever the procedure to handle DCRs and defects is. For me, it was an "unwanted breaking change we are not able to fix in this version, but we cannot admit it in front of our customers". This episode made me particularly suspicious when I get the "it's by design" answer.... That's the story - thank you again for your post. Marco

  • Anonymous
    August 15, 2008
    Hi Marco, I may be projecting myself too much onto the rest of the team, but I doubt there are too many face-saving "by design" calls.  I suspect there are some cases in which the person simply didn't want to deal with the problem, but that most of the incorrect "by designs" are either cases in which the person resolving it didn't really understand what was the problem was. Cheers, -Isaac