"SplitWiki" is the name of an older idea we've had about forming groups. It's largely been superceded by the HubAndSpokeWikis model.
The approach is basically:
- Wait until a wiki is "really big."
- Then look at what you have in your PageDatabase.
- Partition major portions of the database into "families."
- Make new wiki for each family.
- Transfer the pages to the target wiki.
Minor details included:
- Put new wiki on the InterMap and NearMap so that you can easily access the target wiki from the parent wiki.
- Put the RecentChanges into RecentNearChanges?, so people can keep up-to-date with the recently departed wiki.
- Apply WikiNodes:WikiNodes to all the wiki, and connect them appropriately.
The major flaws of the SplitWiki approach:
- The Big Bang. The "Big Bang" is when we suddenly find we have "too many" pages, and start dividing up into pieces. In HubAndSpokeWikis, pages are continually exporting and importing.
- Partitioning the entire PageDatabase. The entire PageDatabase is partitioned in the SplitWiki mode. In HubAndSpokeWikis, we only transfer pages that we care to transfer.
Measuring a "Big Bang," and then partitioning the entire database- just way too much work, and much too shocking for continuity of friendships and thought. HubAndSpokeWikis gets us to our end goal just as well, without all the agony.
Arguments for Splitting a Wiki
Some of these arguments are still valid, and apply to HubAndSpokeWikis as well. We should isolate them on another page.
We can probably do so in terms of SharingDocumentsAndMessages for ThePublicWeb, and in terms of the InternetConcentration or ContentAndCommunity. We'd probably want to reference CommunityBudding? as well, as yet unwritten.
- SocialWiki seem to converge around a clique, and be nebulous in subject matter. A FocusWiki, on the other hand, has a clear goal. It doesn't really require a clique to work a FocusWiki. It's pretty easy to judge a contribution: Does it take us to the goal, or not? Many many many people can contribute to a FocusWiki, and carry it forward.
- A FocusWiki represents a piece of "ConceptSpace?" that can be easily "picked up" by another wiki. It's easy to imagine three or four SocialWiki all picking up a bunch of FocusWiki. Some FocusWiki would be held by 1 or 2 SocialWiki, some may be "held" by 3 or 4 SocialWiki.
- Because a FocusWiki has a specific charter, there is no (or very minimal) OffTopic. This is nice to look at.
- If two SocialWiki disagree about something (hem,hem), but are otherwise in perfect agreement about some other thing, and if that smaller thing was held in a FocusWiki, then there is LessRedundancy, and there can even be collaboration, within that smaller arena.
- RecentChanges is well managed, since everything is OnTopic in the FocusWiki.
- I suppose that, in general, arguments and advantages of "modularity" in software likely apply here as well, in wiki-land.
I don't know if we want to keep the "WikiStartup" and "CategoryWiki" tags; I would consider this page "archival" material.
It's really neat, observing the progress from ye olden days..!