With all due respect, explaining a broken process doesn't make it any less broken.
On Wed, May 12, 2010 at 6:44 PM, David Kean <david.k...@microsoft.com>wrote: > Alright, given that I've actually been on both sides of the fences on > this one, let me try and explain what happens on the other side: > > 1) Customer files a bug on Connect, it appears in our TFS bug database > internally. > 2) First CSS/PSS or whatever they are called these days have a look at > it to try and reproduce the problem. This is to reduce the amount of product > support that the feature team themselves have to do (which would take us > away from feature work). > 3) As these are support personnal and did not actually work on the product, > they usually don't have as much context as the feature team themselves - > hence why some bugs that seem obvious to someone who's used the technology > extensively might be resolved as not-reproducible. The best way to get > through CSS is to produce a simple repro project that clearly shows the bug. > 4) After CSS have reproduced the problem (or if it is a suggestion), they > assign the bug to the feature triage team (usually a senior PM, dev and > test) to look at it. CSS also will add a comment to the customer to tell > them that they have done that. > 5) We look at the bug to determine a couple of things: > > i) Is it by-design? The bug may be exhibiting behavior called out in the > documentation, or called out in the spec (internal document describing the > design of the feature). Or it may be relying on behavior that we don't > guarantee (such as relying on the result of String.GetHashCode). > ii) Is it really a suggestion? Is the request a new feature, API or > behavior that we previously didn't have? These usually fall in priority > against normal bugs - and we usually consider these in the next planning > milestones (which in the 6 months to a year of the product cycle means next > version). > iii) Is it a bug that we would fix? A variety of factors come into play > when we decide whether we should fix the bug; How risky is it? Would it > break compatibility? How many customers would benefit from it? It is a > corner case? Does it have a reasonable workaround? Is it in an area that > we're no longer investing in? > > The ultimate resolution of a bug can take many months depending on the > which part of the product cycle we are in, bouncing among various members on > the team to gather information, and then usually sent back to the triage > team to decide above. The triage team will then usually add a comment to the > customer. > > Now the tricky part of above, is that you guys don't see the whole story > behind the bug. While a bug may have one or two public comments from > Microsoft, internally there are usually a whole bunch of comments from devs, > PMs and QA explaining the underlying details, calling out the spec or doc > that describes the behavior, or explains how it would break compatibility. > Unfortunately, due to the design of the system - it's very easy to forget to > add comment to the customer to explain what's occurring underneath or to > even know that the bug itself is a customer filed bug. This is why sometimes > bugs are closed without comments. > > On top of this, we actually change backend databases every product version, > and when this happens sometimes the link between the external site and the > internal database breaks, meaning that any updates to the bug are not shown > externally. If you've got any bugs from 2005 that are still active, then > chances are this is one of these cases. I've re-raised this issue a couple > of weeks ago, so hopefully we can a resolution soon for these. > > Another thing that I should add about the 'Won't Fix' tag: This can > actually have two meanings depending on the team: > > 1) It really means Won't Fix - something that the team won't look at fixing > unless a lot of people hit the same bug or provide feedback. > 2) It means Won't Fix for this release, but we'll add a special tag to it > that means 'consider it in the planning for vNext' - this is similar, but > confusingly not the same, to the Postponed resolution. > > Unfortunately, external customers can't see which one this is. You need to > gleam this from the comments of the product team. > > Now this turned out to be longer than I'd planned, its late over here > (1:41am) and I really should go to bed. > > ------------------------------ > *From:* ozdotnet-boun...@ozdotnet.com [ozdotnet-boun...@ozdotnet.com] on > behalf of Eddie de Bear [eddie.deb...@gmail.com] > *Sent:* Tuesday, May 11, 2010 10:05 PM > *To:* g...@greglow.com; ozDotNet > > *Subject:* Re: benefits of using vs 2010 > > I agree with Greg on this one. I've submitted bugs and enhancements > which received positive responses (from Microsoft) only to be closed "Won't > Fix" at the last minute. Even if they were migrated to VS-Next would have > been a better option, but to have them closed with no explanation just > discourages people from submitting anything. > > Ed. > > On Wed, May 12, 2010 at 2:04 PM, Greg Low (greglow.com) <g...@greglow.com > > wrote: > >> Too true Mitch. >> >> >> >> Unfortunately, most of the folk I know that used to submit a lot of bugs >> and suggestions have stopped doing so. There are way too many “by design” >> responses. And most suggestions (rather than bugs) have no response until >> the product is about to ship, then they come back with “closed won’t fix”, >> without comment or even a name of who to talk to. >> >> >> >> It just isn’t a good feedback mechanism at present. >> >> >> >> I’ve even had entries submitted in detail, that a bunch of people have >> voted for, many have commented that it’s important, and it’s been closed as >> “closed not reproducible”. Again, with the decision attributed to >> “Microsoft” and no other name present. You’d think if a number of people >> think it’s important and you can’t reproduce it, you’d reach out to the >> person posting it at the very least. >> >> >> >> I can’t make sense of many of the statuses either. I’ve had another one >> that said “can’t reproduce” but also then said “fixed in SP1”. >> >> >> >> Regards, >> >> >> >> Greg >> >> >> >> *From:* ozdotnet-boun...@ozdotnet.com [mailto: >> ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Mitch Wheat >> *Sent:* Tuesday, 11 May 2010 10:22 AM >> >> *To:* 'ozDotNet' >> *Subject:* RE: benefits of using vs 2010 >> >> >> >> While I'm sure the folks at Microsoft do their utmost to fix bugs, it >> doesn't take long to 'burn' bug submitters with "This is by design" >> responses >> >> >> >> Just my 2 cents. >> >> >> >> Mitch Wheat >> >> >> >> *From:* ozdotnet-boun...@ozdotnet.com [mailto: >> ozdotnet-boun...@ozdotnet.com] *On Behalf Of *David Kean >> *Sent:* Tuesday, 11 May 2010 8:19 AM >> *To:* ozDotNet >> *Subject:* RE: benefits of using vs 2010 >> >> >> >> > Sadly most of the worst bugs from VS 2008 are still there. >> >> >> >> Can you tell the ones that you keep running into? Or can you head over to >> Microsoft Connect and file these? Customer feedback is a *huge* factor in >> what bugs in fix – if we find the bugs internally but no customer has >> reported them, these fall in priority against other bugs that customers have >> filed. >> >> >> >> *From:* ozdotnet-boun...@ozdotnet.com [mailto: >> ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Mark Jarzebowski >> *Sent:* Monday, May 10, 2010 5:09 PM >> *To:* ozDotNet >> *Subject:* Re: benefits of using vs 2010 >> >> >> >> I've switched most of my current apps to VS2010. >> >> >> >> It's looks nicer and is more pleasant to work with. >> >> >> >> Sadly most of the worst bugs from VS 2008 are still there. >> >> >> >> Also not much there to improve productivity for coal face developers. >> >> >> Regards ..... Mark Jarzebowski >> Director Software Engineering >> Business Model Systems >> Kew Victoria >> www.bms.com.au >> >> On Mon, May 10, 2010 at 1:22 PM, Anthony <asale...@tpg.com.au> wrote: >> >> >> >> Anyone using vs2010? Is it worth upgrading some projects? >> >> >> >> >> >> regards >> >> Anthony (*12QWERNB*) >> >> >> >> >> >> >> >> >> > > > > -- > Eddie de Bear > Mob: 0417066315 > Messenger: eddie_deb...@hotmail.com > Skype: eddiedebear > -- Joseph Cooney http://jcooney.net
