Imagine a company with an internal wiki: It contains important stuff, funny pictures, rants, and some interesting information about some of the projects. The company now wants to selectively publish some of these pages, and maybe even allow clients to modify this subset of the wiki. How do you do it?

Set up two wikis, an inner wiki and an outer wiki. Use NearLinks to link from the inner wiki to the outer wiki.

Employees will use the inner wiki. When linking or searching, the pages on the outer wiki will be as accessible as the pages on the inner wiki.

Other visitors will use the outer wiki. They know nothing of the inner wiki. They cannot link to or search the inner wiki.

CategoryWiki CategoryInterCommunity


For multiple wikis, the nomenclature is harder to get right. Imagine four companies: three clients, and one producer, resulting in five wikis, one for each company, one for all of them. Which one is “inner” and “outer”? It depends on your perspective! If you work for the producer, then the each client wiki and the common wiki are all “outer” wikis. The producer wiki is the “inner” wiki. Employees of your clients will see two wikis, one for them and one common wiki. To them, the company wiki is the “inner” wiki and the common wiki is the “outer” wiki.

If all those groups are working together on something, maybe you have a single ProjectWiki? which is shared/outer to everyone. And (maybe) every entity has its own private/inner wiki which they integrate with the ProjectWiki?. But SubsetWiki still smells like the wrong Framing as it’s overly hierarchical. Maybe you need to think of the network of wikis, where some are related via uni-directional NearLinks.

Actually, I don’t think this model works well. If I’m in the outer wiki, I’d like to see links back to my org’s inner wiki, and to my wikilog, and to my private diary. Which is why I increasingly think that SisterSites/NearLink needs to be client/proxy/personalization-based. (BackLinks are an issue, too.) --BillSeitz

Yes, clearly this is not a perfect solution. When people having access to both wikis read pages on the outer wiki, some functionality will be reduced. I’m not sure the money is well spent if we build a lot of infrastructure into this: Proxy-based could mean authentification, for example, where you have to provide credentials to the proxy so that the software then knows whether to use the “outer” script, or the “unified” script for you. You could also solve this via firewall rules. From the inside of the network, you’ll automatically use the “unified” script.

For the the use case at our company, where I thought about this idea, however, we’d have a ScratchWiki on the inside, about 200 pages, and our corporate website on the outside, about 10 pages. Therefore, the pages on the outside are obviously much less important when it comes to backlinking.

There’s a lot of literature describing how companies published their IT knowledge bases to customers. One problem is that the internal knowledge base has a lot of graffiti and off-colour comments about customers. Also, the knowledge base is often bogus for a long time until a real solution is found. So instead companies elect publishing boards (usually one person) to selectively publish material to a public mirror, often with its own discussion board. One secondary effect is that the professionalism of the main knowledge base increases dramatically as it is a lot easier to clean publish material to the outside world. Some companies have tried to put their entire knowledge base on the outside, but that doesn’t work very well either.

Similar but different:

A classroom, way out in Florida, sets up a wiki, on, say, “Mechanics.” (Entry-level Physics.)

You live in Washington. You want to learn Mechanics. Being a proper WikiZen, you search for the Mechanics wiki. You find Florida’s Mechanics wiki.

But, it doesn’t really make sense to work there, does it?

Because you’re intruding on some classroom. There’s a professor in charge of little minion students, and they’ve got class schedules, and homework assignments, and all sorts of stuff floating about. It’s clearly not your territory.

So, what do you do? As far as I can tell, you’re screwed.

What the classroom should have done instead:

  • Make a general Mechanics wiki. Open to the public. ScratchWiki, of course, by ScratchWikiFirst.
  • Make a classroom wiki. CommunalWiki, intended for students and the professor of this particular class and semester.

NearLink the classroom wiki to the general mechanics wiki. UnifiedRecentChanges, as well.

Make a note on the general Mechanics wiki that the classroom wiki exists (link to it,) but isn’t really intended for general public use. (You probably don’t even need to say it- GuidePosts and all.)

Students work on the general Mechanics wiki for teaching and learning Mechanics. For classroom maintenance (homework assignments, group projects, policy, whatever) they use their private wiki.

This way, students participate in the global discussion, while still having their own space for class.

Define external redirect: ProjectWiki

EditNearLinks: CategoryInterCommunity GuidePosts