Exactly, which is my main point I'm trying to make here. We've got a situation right now where we've got documentation that we say is _the_ source for info about MediaWiki, and yet we cannot vouch for it.
I don't think our major issue is vandalism or people purposefully inserting false information, but more so users who don't really know exactly what they're changing, they just know what worked for them. I've got several docs I've looked at in the past several days that suffer from this: clueless people trying to be helpful.
Not that we should discourage helpful people, but helpful people don't always know what they're talking about; at least not well enough to allow them to set the documented standard :)
Yes, but the help namespace is a much simpler, less controversial place to start than other parts of the wiki.
This issue was brought up there years ago, long before there was any technical means to address it.
The idea is these pages could be mirrored to a local site, but the problem is that mirrored set could easily contain vandalized, wrong, or nonsense pages that would need to be sorted out, which pretty much rules out any kind of automated mirroring, which was part of the point of setting it up that way. Flagged revisions could simply fix that.
In most pages, unless the flagged revision was shown by default, it wouldn't be too useful. Here, as long as you can access the flagged revision easily, i.e. via the API, it would solve a real problem without discouraging editors by preventing their work from being shown on the site.
And, really, help pages don't need to change that often, so a brief lag wouldn't be a problem. If fact, it could even be useful, i.e. to document new features as they are implemented, but flag which version of the page applies to the latest quarterly release.
Although it's good if the developer can document every detail, it may not be practical for them to spend a lot of time polishing the document, if they can at least get their point across quickly. From what I've seen, misspellings and bad grammar tend to cause a bunch of IP edits, but these tend to sort themselves out. The problem is when the documentation is unclear, people may clarify things that they don't understand.