Align wiki to goal
To align wiki to goal(s) of an organization means to ensure that naming conventions and balance/hide/ignore/delete protocol, at least, do not allow persistent contradictions of the wiki's purpose to remain in view of ordinary users.
 ...or limit your goals
The overwhelming majority of businesses including all small businesses have ZERO time nor money to make up their own general purpose content, or even industry specific content, or even generic statements of what the organization does internally. They outsource all of this, typically to the public web and often to semi-public webs and semi-private webs such as paid web services. If the wiki becomes pervasive in an organization it can be used to regularly update pages with all sorts of information that is not relevant or appropriate for those shared webs (semi-private, semi-public) but which remains part of their private web or intranet. That however must remain very focused on exactly one core business process, the "kaizen" of that one company, that they are continuously improving. This is a very tiny proportion of the information they rely on: a company's internal filing system might have only a few percent of what's consulted in its accounting, marketing, design and human capital processes. Naming conventions are therefore a balance between the internal and external needs, and if done poorly can skew organizational memory badly.
Thankfully, there are very few actual choices. Craig Hubley says "you do not get a choice about what to call a "green roof", it's called that, period. When you use google, or more importantly when your customers do, they'll be using that term, not another term that you made up." Many other reasons exist to slavishly adopt Wikipedia names.
"Your product's brand name is going to be something different, but you better have a good and generic explanation of why your green roof is better than the competitors'. Trying to pretend that you have no competitors doesn't work well in the age of google..." though it can work very well to franchise something that solves a specific problem.
However, "any small business trying to name more than the concepts directly relevant to its core business process (which should be broken down into a very few protocols), and adopting standard conventions to its operations, is committing a visible form of suicide... 99 per cent of the organizational memory will remain outside the organization as industry memory, species memory, and so on... you have no choice but to adopt the conventions that already apply beyond your core business process...In other words, if it IS described in Wikipedia, then it has a name, and you msut adopt that very same name." The days when IBM could call a disk drive a "DASD" and exclude competitors are over. Hubley says today's organizations "have NO choice but call things what they are called in Wikipedia, import articles on any relevant subject at all, correct those articles if they are giving some wrong impression to the whole world that the company needs to correct," and scoffs at the idea that persistent misinformation could possibly form the basis of any competitive advantage: "it will only generate mistrust... If it's actually "misinformation" you will never get away with it for very long." He notes also that ethical trolls never try to mislead others at all, they just refuse to answer certain questions, e.g. never ask who wrote what.
 sharing pays
While the PHB view is that a company succeeds when they know how to do something that others don't, and that divulging all your secrets to Wikipedia is a way to put yourself out of business, Hubley scoffs at that, noting that "information is no longer a source of competitive edge, ability to execute is. If you can rattle off what's in Wikipedia and show instantly how to apply it... then you will win. Your competitors will scramble to justify themselves in terms of the standard reference" and if you understand it better and regularly improve it, while they are stuck in their own data jail, ignoring what the world thinks "they'll lose." Companies must compete "on a higher level of abstraction: services not products" and defining and clarifying the terms is itself a service: "If you called someone and they gave you a pile of credible references and talked just like the most authoritative sources you, the customer, had seen, you'd be far more likely to deal with them than if they quacked a bunch of jargon at you they'd made up themselves."
 using a wiki to publish a public web
The simplest case is the use of a wiki to stage materials to publish to a public web. In this case, the wiki is private (like any corporate wiki) and only some pages from it are published, when approved. If the material is published to another wiki, this requires nesting wikis.
 nest wiki
However, even when sharing nouns, where multiple goals (and user bases and verb:namespaces) are involved, specialized articles may overwrite the more general, and only multiple nested wikis can keep those separate. This structure is analogous to that of software which usually relies on client/server/library levels of code.
Hubley: "Let the research range widely, import only what's directly relevant to the work, and send only the final decisions on to the lawyers to approve. That's three wikis at least." See also the develop/research/publish model below.
 like Wikinfo.org (two wikis, both public)
In a nested wiki, Hubley advises to "import and modify the imported articles to link to local versions of same. Getwiki, in other words, is actually the only front end doing it right...The correct approach is to nest your private data as a layer on top of semi-private on top of semi-public... on top of public sympathetic (i.e. Wikinfo) on top of public neutral (i.e. Wikipedia) data." Proprietary wiki "are worthless because they don't nest like this. You end up having to pick every single damn article yourself without defaults..."
 to develop/research/publish (three wikis, all public)
In the Consumerium model, three staged wikis are used to prepare content for release:
- one to develop new plans and labels to discern fair trade from unfair trade
- another to conduct research and compile evidence/source/authority informatino
- a third to prepare material to publish, probably involving legal vet and veto
This is required because lawsuits are almost inevitable based on Consumerium's goal which is to specifically discourage purchasing of products of unfair trade. Each and every time information is requested, it is potential restraint of trade which some governments strongly resist, especially if they have unfair subsidy or polluting policy.
 choose later what to share
Hubley says that users can "put more or less of your private data into the semi-public and public sources, that's your choice... I argue that more of that is in your best interest, but, if you're not actually capable of executing to a superior degree, you might try to hide some of it... though why anyone would care to hide information that is not reliably providing them an execution edge, I do not know." He advises mediawiki-based services and tikiwiki-based services make it easiest to import and share data, and that getwiki, despite its advantages, is "only supported by one guy who is constantly fighting with the mediawiki team. It's dangerous to rely on tools like that. If you were to use getwiki, you'd have to pay the one guy who wrote it."
Once the wikis are nested, you "can then make a choice as to how much and what kind of information to keep private to your own people, private to your own clients, semi-public to your community ..., spread to Wikinfo, spread to Wikipedia and thus the world... You might be more open, or more closed. But by no means should you set up a structure that forces you to keep things private that would be more strategic to make public, say by using two different wiki data formats."