Joseph S. Myers <[EMAIL PROTECTED]> wrote: >> Nobody is going to be blocked by this; no bootstrap will be broken; no >> wrong code will be generated. This ain't code. In many common cases, the > > Wrong code will be generated when someone relies on subtly wrong > information in the documentation. It is a well-established failure mode > even on the best wikis (i.e. Wikipedia) that someone inserts subtly wrong > information because of not knowing better (or not knowing that there is > controversy among experts about which of two versions is correct) and this > does not get corrected soon if at all.
That is right, but there are level of interests. The debate can be on some small detail, while the big picture is still good enough for beginners or intermediates. Having something which is possibly wrong on some subtle details is still better than having nothing at all. As I said, I am a strong sustainer of "commit now, refine later". > (b) I don't see Wikipedia edits routinely getting > reverted simply for lack of substantiating evidence. Yeah, but I widely use it and it is still very useful. It may not be 1000% correct in each word, so what? Are printed books any better? Or is there a real only truth? We're entering philosphy here. What is certain is that Wikipedia wouldn't be 1/1000th of that if there was a review process for each patch being submitted. > Perhaps the wiki could automatically send all changes to gcc-patches to > assist in review? I strongly support this (and was going to suggest this myself). I'd rather it be another list though, say wiki-patches or doc-patches, because of the amount of traffic that is going to be generated (think of all those small typo fixes, or spam reverts). -- Giovanni Bajo
