Comment 7 for bug 306378

Wow, people are still reading this! (Because they wish they could close it?)

I have to respectfully disagree to the extent that a sufficiently open Wiki is a free-for-all, and a sufficiently locked-down Wiki isn't actually so much a Wiki anymore - but still lacks some useful side-effects of "thinking in the KB pattern", particularly the way entry numbers (as with LP bug numbers) provide a quick sort as to which information is potentially most relevant/current.

As an example of some common trouble with Wikis:

https://help.ubuntu.com/community/UpgradeNotes is linked from the actual "Get Ubuntu" page on Ubuntu.com and happily defines "Long Time Support". It also contains a melange of instructions for numerous different versions... but actually isn't altogether horrible, just the fastest thing I could find that points to the "slippery Wiki slope."

The first search result for "compatible hardware" in that Wiki's search is this link:
https://help.ubuntu.com/8.04/installation-guide/amd64/hardware-supported.html
...yes, that link. To information that would be relevant to 8.04, if it weren't a 404.

The first apparently-relevant result hasn't been updated since 2011 (and in this case the stylesheet used makes it very, very difficult to recognize that the information may be stale when you're actually on the page, since it's in fine print. At the very bottom.)
https://help.ubuntu.com/community/RecommendedHardware

It's the dangling-reference/abandoned-resource problem that bothers me with Wikis the most ( sample discussion of the issue in hypertext systems in general here: http://www.ra.ethz.ch/CDstore/www5/www362/overview.htm ) ... in large projects, like an OS distribution, you end up with supposedly general topics competing... I'm not saying "RecommendedHardware" and "SupportedHardware" and "SuggestedHardware" actually all exist as articles in the Ubuntu Wiki, but it doesn't take much browsing to run into similar problems.

There's nothing really "magic" about the KB approach except that encouraging applies-to: version tagging, and resolving forward and back references (superceded by:, etc), along with the tendency toward serial numbering, makes locating actual relevant and correct information much easier.

And from a use-case perspective, I'd say a "KB" maybe fills the same niche as the "Answers" feature... but that again tends to be too focused on "resolving" / closing "issues" than actually improving documentation quality as a whole. (And when someone internal to the project discovers a bug that slipped into a release that needs a workaround... do they 'Ask' a question against the project for others to find an 'Answer' to? Unfortunately I do suspect producing quality documentation for free has competed - unconsciously - with the mission of a lot of FOSS companies to 'sell support'. Not ascribing actual malice, but it's just a conflict of interest that helps ensure the situation stays somewhat dire - why allocate resources to _reducing_ the need for the one revenue-generating product?)

Anyhey, just food for thought and I do think both Wikis (preferably more open than closed) and more formalized "KB"s both have a place - Wikis are sort of a sketchpad / design draft / engineer's notebook, while the formalized "KB" should be as authoritative as the "official documentation" - but covering all the corner cases and surprise issues that'd bloat the "official documentation" to 20,000 pages if such existed.

(And I suppose I should also observe that a KB _is_ much like a bug database - but a bug database focuses on 'closing' issues - especially if the issue is with user knowledge rather than a patchable software defect - at which point they tend to get swept into the closed/expired/invalid pile and a lot of useful 'institutional memory' is wiped rather than retained.)