How we prioritize bugs
As WPF gets closer and closer to shipping, one of the things I spend a lot of my time doing is bug triage -- prioritizing bugs and deciding which to fix. We'd like to fix all bugs, of course, but that's just not reality. There's only so many hours in the day, you can only throw so many people at a given piece of code, and fixing bugs often creates new bugs. So it's important for us to be selective. And we’d love your feedback in doing this.
Every team in WPF is a little different, and so prioritizes bugs a little differently. But my element services team (parser, property engine, styling/templating, input/commanding, interop) looks at three main factors. First thing is who reported it, and how important the bug is to them -- something that was found by you is going to get higher priority than the same issue if we found it internally writing an artificial test case, because we know at least one real customer will actually hit the bug. We’d love as much information as you can provide – not just what went wrong, but what you’re trying to accomplish, why you’re trying to accomplish it, and even in some cases the business goals of your product – the better we understand where you’re coming from, the better we can understand the real impact the bug is having on you and other people.
The second thing we look at is what the impact will be on future versions of WPF, the "now or never" factor. This comes up a lot with making sure the xaml parser doesn’t accept invalid xaml – because that would effectively change the xaml spec. And that’s a problem because there’s more than one xaml parser in the world, for example Expression has its own parser (because design-time requirements are different from those of a runtime parser).
It’s easy to overdo the now or never factor – pretty much anything, once shipped, is difficult to change, and some of those imperfections will have much more impact than others. Generally speaking, API cleanliness issues are quite low on our priority list at this point – eg, calling it "IsFocusable" instead of "Focusable". My goal is to ship a good API, not a perfect one, because if we tried to ship a perfect API, we’d spend so much time on the API that we wouldn’t build useful, performant functionality.
The third factor is the difficulty of someone outside the team understanding what's going on and creating a workaround. Some things are pretty easy to understand, others are fiendishly difficult. Generally speaking, the lower the bug is in the system, the harder it is to understand – sometimes to the point that we can’t even guess who will be impacted. For these reasons, we generally take race conditions and invalid results from the property engine and input system as very important bugs. Predicting how other people will understand something is obviously a tricky business, I do my best to calibrate this based on your newsgroup questions so keep 'em coming!
Final thing to throw in there is I believe in being honest about whether we’re going to fix something. As I said, I would love to fix everything – but I know we aren’t, so if I don’t think we’ll get to it, I’ll resolve that bug "won’t fix". I’d rather you find out now than later, because that will give you a chance to let me know if I made the wrong decision.
For specific bugs, ladybug is the preferred approach. If you have more general concerns about categories of bugs or priorities, this blog or my e-mail is a good forum. It’s all about making the right trade-offs for you, so we appreciate the feedback!