SNIP
>
>>For instance, let's say that Product Support gets an overload of calls over a period about "problems" with VFP's ComboBox. They smartly decide that some "How To" articles would be the antidote so they write, edit, review and publish them. They've done their job, but the VFP Team is none the wiser that, most probably, the content of their documentation is the cause of most of those calls in the first place! Nobody, most especially not the novice, is helped by this procedure.
>
>How many times has a member of the VFP Team (particularly Mike Stewart) pointed to a KB article? Quite a few. My impression is that they are accutely aware of the existence of the KB articles.

Sure, and Sergey is the undisputed king of locating relevant KB articles here. But that's not the point! A bunch of KB articles to make up for documentation deficiencies is helpful but really cannot be considered the FINAL resolution. Fixing the documentation is the FINAL resolution. Below you say that is another team's responsibility, NOT the VFP Team's. It get worse, not better, George!
>
>>Now let me discuss the 'fix list for VFP 7". From your description it is up to Product Support to gather all of the prior BUG articles for VFP 6, 5 and 3 and ferret out those that do not have a 'fixed' indication attached.
>>Then they have to try each one out to learn if it is fixed or not. Those that are 'fixed' get added to the list of fixes. When they have been through the whole list then they can write, edit, review and publish the "List of Fixes in VFP 7.0" article. With any luck at all we just may get it as VFP 8 is released! Those that remain as bugs in the current product require each of their articles to be updated to now include VFP 7.0 in the 'applicable to' line.
>
>The other side is that the KB cannot be updated piecmeal without giving the impression that an issue wasn't addressed when it may very well have been address. Further, they can't even start working on what's been fixed or not until the software goes "gold". IOW, is RTMed.

I guess that the VFP Team keeping track of what they (believe) they've fixed and informing Product Support of these is too much to ask.

>
>>I'll end by discussing the BUG Reporting facility with the (new found) knowledge that these go directly to Product Support and not to the VFP Team.
>>A submitted bug must be reproducible to be able to be squashed, and we all understand that. But VFP has sooo many different mechanisms/SETs that can influence processing and Windows has even more (not to mention different versions at varying fix levels). There is a very high probability that an abunbance of the submissions prove to be not reproducible in one (or even two or three) trials. We have witnessed that here more often than not in the 50+ VFP7 bugs reported on UT! The Product Support group can legitimately dismiss the report as not reproducible! They cannot contact the submitter (at least the 'regular' submitters) to learn more factors that might be implicated because submitters mandatorily are anonymous!
>>I contend that the VFP Team has more in-depth knowledge of the product that would (often) let them deduce mitigating factors to assist in reproduction of the problem submitted. I contend that the VFP Team has a vested interest insolving problems rather than just handling them.There is a HUGE difference!
>>There must also be a "political" problem with the current practise. After all, if I was the Manager of the VFP Development Team I wouldn't take kindly at all for some outside group to be declaring bugs in *MY* application. I've gotta believe that there is an additional layer of "review" imposed in the system just because of this.
>>
>>The procedure explains WHY 99%+ of the bugs reported here (UT) for VFP7 remain unacknowledged in the KB. I say that means that a change is needed, not that the current practise is in any way acceptable or sensible!
>>
>>I never would have guessed that things worked the way they do and I doubt that many regular VFP users did either.
>
>If people report bugs and fail to provide a detailed description and code sample to reproduce the bug, IMV it's as good as not reporting the bug at all. I recall one post here (I can't recall who made it, unfortunately) where the poster stated that he wouldn't give further information beyond what he had already posted because it wasn't his job and he didn't feel that he should help MS make money.

That poster was 1 in a million. Again, you don't seem to get the point here - I can have a bug on my system, create minimal code that reproduces the bug on my system, send it off to MS with all fields of a bug report duly completed, and never hear that they did NOT reproduce it on their system(s)!
Because there are so so so many semi-related factors that may be set in a particular way on my system (or I may have a unrelated piece of software that most don't have but I have no clue that it's implicated) yet not on MS test systems, the thing gets dropped as non-reproducible without my knowledge. I still sit in hope of a fix yet none will ever be coming!!!!
I say that it is virtually impossible to cover off ALL of the potential bases when sending a bug report in and that MS has got to recognize that and amend their method of handling bug reports to accommodate the reality.

Jim

SNIP
>
>As far as the quality (in general) of the VFP (and other Microsoft) documentation, I've had the experience working with products from other vendors and their documentation. Certainly, the stuff from MS isn't perfect, but it is consistently the best, most accurate, and most informative. Would I like it to be better? Sure, but given what I've just said, what's out there is great by comparison.

I just can't help but imagine how much better it would be if things like the ones discussed here were factors in documentation maintenance.

Jim