How a team should use the Federated Wiki in a Commercial Environment is a question I had posed. matrix 
Ward goes on to offer some ideas based on his experience. matrix
I (Ward) used the HyperCard stack that anticipated Wiki to maintain a FAQ for WyCash design and implementation insights that weren't obvious in the codebase itself. Each time a Question came my way I offered answers that could be used immediately. Then I would write a page or two about what led to the question and how it was resolved. Over the years the linking became progressively more important.
The original design of Federated Wiki was on behalf of a company very protective of its own brand but with a need to collaborate with competitors regarding sustainability products industry wide. Wiki's controlled sharing came from this tension.
In year two of the project I promoted it as a version of "agile" where projects would maintain "lab notebooks" using all of the jargon and technical details necessary for their solutions. This then could be forked by first level management and revised to reflect the concerns at that level, primarily requirements and timetables. Second-level management could then fork these pages up to their level of concern and add their insights which would be more about resource allocation and new product sponsorship.
Later, at New Relic, I setup the newly implemented "Login to View" and invited several research-oriented projects to maintain notebooks as projects were forming but did not yet have the conventional structure. Here we said no information more private than "company confidential" would be entered in wiki which was actually hosted in my own digital ocean servers. Note, having left the company I can no longer edit but with root access I have potential visibility that I protect with the same "compartmentalization" that I provided to other companies where I consulted. (I wouldn't sign an NDA but was trusted as a professional which is more important to my kind of client.)
~
Brian via matrix : I'm not sure what sense you are referring to with "Commercial Environment." In the Extreme Programming sense, the team should use the tools (and customize the tools and their processes) in whatever way provides value to the team. If the team benefits from a tool that is de-centralized (vs centralized) and wants pages that can have customized plugins, often with pages that are line-up aware, then a FedWiki like tool might be an excellent fit for the team.
I think that Centralization might often be a much better fit for commercial environments with current cultures and legal structures, in which case, FedWiki might not be a very useful tool for them. However, de-centralized with sync-ing support might make a lot more sense with hybrid and remote work. Offline local Git repositories completely transformed the way I coded compared to when I used csv/subversion. In current FedWiki, this is manual and pull driven, but I could see cherry picking some of the Git push/pull request notion concepts to Fed Wiki and having that be a very successful paradigm for some environments. The thing that I initially found a bit frustrating with FW, and now find quite pleasing, is that FW is an area to explore these concepts and try a few of them out, with lots of views from people with many experiences.
~
robertsterbal via matrix : I think you should be asking who gets to make that decision
Ward via matrix : Yes. There is a long list of things that could work but don’t work because they run counter to endemic notions of command and control. I have stories, lots of stories.