Hi Jim,

I'm not sure what you mean by "our MINIMUM expectations from having such a list, member-maintained, here on UT". At minimum, I expect nothing. Any increment of improvement would be welcome.

Is it acceptable that there might be some duplication in order to send a request through formal MS channels? Better that this were done once, deliberately, rather than innumerable redundant submissions by people kept ignorant of each other's actions.

Would people be motivated to fill it out and to use the system before it contains a substantial amount of content? I guess that depends on one's expectations about people's participation, and their sense of the system's integrity and usefulness. The way I see it, we've got plenty of bug-related information to work from, and we need ask no more from most people than what they are already doing: post messages clearly describing their experiences with what appear to be bugs.

We already have ample discussion infrastructure, as well as content. What's missing is largely an editorial problem, and a matter of leadership. If there is to be a single consolidated VFP bugs database, there needs to be an editor, or a hierarchy of editors, whose responsibility is to take the existing body of scattered discussion and massage it into a consistent, useful, logical organization, and to maintain it. In short, someone has to take charge and perform a valuable service for the rest of us. This is not about the comparatively trivial task of submitting bug reports to MS. Skillful editing and effective leadership are not trivial tasks.

Would it suffice to provide these facilities only to UT members? Ideally this information would be made available to the widest possible community of VFP developers, at the least possible expense. It isn't fair or reasonable to expect something for nothing, though. Perhaps a more modestly priced level of UT membership providing access to the bug list could be introduced to cover the expense of maintaining it, if Michel would be amenable to such an arrangement. One way or another, it seems like too much work to be done without appropriate compensation.

It also seems like too important a problem to be left to those who fail to recognize its value. What sort of leadership can we expect from them? I would gladly pay a modest annual subscription for this service if people of your talent and disposition were behind it, whether on UT or elsewhere. I realize that you are not soliciting payment, but frankly, I would insist on offering it, and if I were in a position to provide such services myself, I would insist on being payed.

Mike

>Not trying to "steal your thunder" ChrisM, but rather hoping to move the issue along some... < s >
>
>I have been reading the "VFP Bug List on the UT" (thread #791164) with great interest, this being one of my hot-buttons for a long time. It is gratifying to see that so many other people are also feeling similarly.
>
>But it also occurs to me, as I read the thread, that there may be different ideas floating around out there as to what really is required. And I think KenL's first response in that thread, message #791406, gives us an idea of what might be it's overall utility (which I'd say is not a lot at the MS end of things).
>So I thought I'd ask the question: What is our MINIMUM expectations from having such a list, member-maintained, here on UT.
>
>For instance, KenL's response indicates emphatically that MS would basically ignore any such list, meaning that it would still be necessary for the originator to send a (duplicate) request through formal MS channels. Is that acceptable?
>
>Similarly, it would take some time before the list held sufficient content (number of items) as to really be useful. Is that OK? Would people still be motivated to fill it and to use it?
>
>Also, reviewing the UT Task Tracker entry by George Tasker in early 2002 (I presume) titled "Bugs, Workarounds and Fixes KB" and comments by people to that item it seems apparent that the best scenario would be to first discuss the problem as a possible bug in a regular thread and once apparent that it is a bug the originator could complete an entry in the BUG List. Is that right/OK?
>
>Of course *I* feel that all that is perfectly acceptable (though integration with MS would be best) because I want/need a place I can go to to check on the prior existence of a bug and I need it to be reliable. I feel that what is described above would do it.
>
>So, assuming in the worst case that a BUG List on the UT would be available but only used by UT members for viewing, monitoring, commenting and obtaining workarounds to such potential bugs, would it still be useful enough to have?
>
>Comments?