Hard disagree. The strength of the Arch wiki and Wikipedia is their content, not how they are (supposedly) organized. People are more likely to write good documentation (IMO) if they like what they are documentation.

I can’t agree.

It’s not tree-based vs graph-based. Even folders as organization structures can mimic graph-structure via shortcuts since Windows 95 (and symlinks on Unix exist since forever I suppose).

The culprit in most commercial company project is the effort & willingness to allot time for organizing and maintaining information hierarchy.

And let’s be honest: What’s the main workflow for retrieving information from Arch Wiki or Wikipedia? Searching! The last resort in every company wiki which organizational structure (tree) isn’t suitable for information lookup.

If that is not argument enough to ditch Confluence for Media Wiki then frankly I don’t know what is.

Confluence is also just the graph approach with an automatically maintained Table of Contents. And Media Wiki is really not a good example for a barrier-free and intuitive documentation platform.

Do start using a graph-based system for documentation. It scales easily and engineers will naturally contribute.

…and without someone doing the organizational work needed for both approaches, the documentation will be an unorganized mess of various styles, depth & quality.

I do dislike tree-based organisation, but I can’t imagine the Wiki approach, because each article needs a unique name. That works fine for documenting real-world distinct things. But in a company, the only real distinct things with names are projects/products, and you do not want just one Wiki page per project.

I guess, for a project “Foo”, you could have pages named “Foo: Finances”, “Foo: Customers”, “Foo: Code”, but unless you make those understandable without context, that’s kind of a tree structure again.