Hi Fabio,

I am glad that you feel that this could work well despite the constraints I mentioned.

Personally, though, I feel that it would be critical for the originator to supply "repro" steps/code so that it can be clear that others also achieve the negative result (confirming a BUG or some "issue" (like maybe bad/incomplete documentation, which hurts us all too)).
In fact I would think that a person suspecting that they have found a bug would:
1) check the list we are talking about.
--- If there, they now know it IS and hopefully find a workaround there too. They might also add a comment to it.
2) If NOT already in the list, start a thread to "discuss" the specific issue.
--- If discussion proceeds as normally observed, people will try to make it happen on their systems and report their findings.
3) If it is confirmed by others, then an item would be entered into the subject bug list.
--- If NOT confirmed, no need for an entry (most of the time) and probably someone has provided a 'workaround' through the discussion.

As regards actual operation/maintenance, I have no idea as to how that would happen. But I do have confidence that, if UT decides to follow up and do this, then they will adjust as needed to make a high quality list.
And I think you are exactly right when you say that UT will gain LOTS MORE MEMBERS if they have a quality BUG LIST available.

cheers


>>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?
>
>I think this is not a problem.
>KenL says this in order dissuade the community to make it.
>If a list of Bugs, "managed well", comes published in a public site, and the bugs do not come send to the MS, MS does not have alternatives, will have to use this list.
>
>>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?
>
>Many people.
>
>>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?
>
>Today some serious information on the bags of VFP does not exist.
>Therefore, only UT members uses this list, but any developer that it will know the existence of this list will become a UT member.
>
>*****************
>
>The true problem:
>"managed well" is the magic words.
>
>This list need central management, not distribuite, it will not never work if it will be left to the independent management of the members ( see Wiki example ).
>
>This list needs of two database:
>- public where all bring back problems or the presumed ones bugs find to you; this can be managed like one category of a public forum;
>- an other database ( central management ), is that one published, read only where the bugs are brought back confirmed or much probable. (This would have to be to payment)
>
>If the second not is, the thing dead after little time.
>
>Necessary the minimal information are:
>

- date of pubblication
>- VFP versions where it appears
>- description of the bug.

>not essential
>- code of example
>- workarounds.
>
>This must be opened to additional revision, not to overwrite revision ( MS style ).
>
>In the improbable hypothesis that the MS supplies support,
>the MS must, necessarily, supply this information:
>

- VFP version where the correction of the BUG is forecasts.

>
>After 90gg from the pubblicazion of the bug, if the MS not filler forecasts, the bug is not solvable, and the developers must to resign oneself to find one road alternative of program coding.
>
>Fabio