Nancy (said with dander UP),

>Jim
>
>>I think that simply pushing for interim releases of the docs will not really accomplish much, unless it is accompanied by some easy way to communicate observed errors/omissions/confusions.
>
>Somehow, Jim, I *knew* this would be where you went with it. It's easier to criticize endlessly, I guess.

I believe that the last time that I criticized the documentation in any serious manner was well over 18 months ago. Maybe the same tune makes it endless. Evidence of improvement, rather than deterioration, might have ended the tune too. I'm glad I didn't disappoint you, though.

>Look, the criticism is the docs aren't as complete as we'd like them to be.

In this case, no, it is not. It's a criticism that there are more (not less) errors, omissions and confusions in the new version. Yes, they are incomplete too, but that is not the issue here.

>Call me simple-minded, but it would seem the first order of business would be to update the docs. Communicating that changes have been made could be 1) a logical absurdity (how much time do they spending communicated what changed vs. changing the docs) 2) the same process as communicating what's changed in the product upgrades (seems to be an already working model).
>
Not simple-minded at all, but surely ridiculous. You take a simple statement and play it out in a silly way.

>>What is clearly needed, in my humble opinion, is for someone who is VFP knowledgeable (modern VFP, not FP or VFP3) to proofread and correct the documentation. I am also assuming that it is understood that anyone acting as a proofreader would be attentive to the smallest detail. [that person might also be able to apply the changes outlined in the UT VFP8 wish document < s >] Interim release publication at points during this process would surely be helpful.
>
>Okay, there again is the implicit assertion that MS has substandard staff with questionable qualifications working on a project. What makes you think that VFP-knowledgeable people haven't been reading the docs? And, it also seems to avoid the issue that documentation is a profession all it's own. They do somehow manage to get technical docs done. The docs aren't _that_ bad. Crikey, or we wouldn't be able to use them at all.
>
Is there some new standard that I'm not aware of that says that making a critical remark about anything MS automatically means crapping on the VFP Team??? If there is, I need to know!
Look, the things that I have come across inspired the stipulation of "knowledgeable". I can only say that if, indeed, that person is knowledgeable, then they are sloppy. And what difference has it made if VFP-knowledgeable people did read the docs??? Errors, omissions and confusions still abound, so they obviously had no say in having them corrected.
I know that technical writing is a profession in its own right. By saying that "somehow they manage to get technical docs done.", are you saying that they do NOT have a 'professional' technical writer on staff? If so, what is the relevance of your prior comment? If not, then it looks like they need a better one or to have some additional oversight on this person's output.
IF we hope to attract more people to VFP - and now may be a prime time, what with disgruntled VB programmers out there - then the documentation has got to be more accurate and descriptive. Sure, people with years of FP and/or VFP experience can get along with it the way it is, but newcomers wmay well give up andlook to something else if they depend on this stuff to get them going.

>>A few things, just off the top of my head, that I have found in perusing the new docs so far:
>
>Did you file bug reports? How the heck do we file bug reports, anyway?
>
No, I haven't filed a bug report in years. And, frankly, this "problem" (I don't categorize it as a "bug", personally) would take far too much of my time to do a job that should have been done in the first place.

>>I know that I have found at least 10 more. Too bad that the display mechanism doesn't allow for annotation, 'cuase then I could make notes and they would be easier to (re)find.
>
>Annotations would be nice. Agreed. That doesn't share your knowledge, and you'd lose the notes in an upgrade. Have you thought of starting (maybe it's already there) a Wiki topic on Doc errata and corrections?

No, but annotation would let me periodically go back to find the one's I've come across (annotated) and submit them to the authorities.
As an alternative I tried keeping a Word document open and copy/paste to it as I found errors and stuff. That didn't work because I was most often deep into a real bug (of my own) and I simply forgot to do it. I think that a Wiki topic would have the same problem (existing or not). At least with annotation I would already be on the error page and a few extra key-strokes would let me note it THEN. Later (weeks) I could collect them and do something with them.