Yes. :-)

mikepope

Couple of observations: - Eric's post is from 2003. - It's about turning down a feature request, not fixing a bug. His specific scenario occurs often, of individuals requesting features that are of particular use only to them and are not of general interest. - To emphasize his story (perhaps as a literary flourish), Eric notes that the requester notes how trivial the feature would be to implement. As Eric points out, it would be almost as trivial for the requester himself to implement. (Programming languages and frameworks are great this way.) As for the more general points: - What's the triage process MS should use for considering user requests? - How many user requests should MS implement for a product release before actually releasing that product? - Which new features added to a product in response to user requests should not be tested? What's the minimal test coverage that should be considered for adding extensions to a language like Visual Basic or C#? - Which new features should not be localized? - Which should not be documented? (FWIW, Microsoft is legally mandated by both the US and the EU to provide documentation for every public API in its products.) - Which documentation should not be localized? IOW: how do create a product like Windows or Office or Visual C# that is used by millions and millions of people every single day and have a rational development process that isn't just a matter of throwing new code into the build in response to an email from a guy who would find it really convenient if you added widget X to the next release? I'm curious whether anyone on this thread works on products that have the same install base (in as many languages) as anything that Eric works on. He's currently a senior developer on the C# team. Finally, and this intrigues me mightily: can someone cite a specific source of the idea that the Office ribbon was implemented on the whim of an academic?

mikepope