Smallest Federated Wiki
Feb'2015 Jon Udell article: A conventional wiki, says Mike Caulfield, is "a relentless consensus engine." A federated wiki may eventually yield consensus, but it promotes what Ward Cunningham calls a Chorus Of Voices. Does that sound like a pipe dream? Perhaps, but so did wiki, agile practices, and decentralized version control.
- Co-Creation of knowledge (and other things?) (scientific community, etc.)
- big wikis have spam/abuse problem
- small wikis get no traffic, Critical Mass
- Mike Caulfield class model: you can copy content from other students, as long as you "own" (understand, can speak to) what's on your page
- you get to keep your own Voice, no need for NPOV
- Emergent Value In Proliferation (divergence/convergence, stigmergy, Twin Pages)
- High Awareness In Foraging: Wiki Neighborhood
- Mutable Linear Form: simple small pages (Node Web)
- Authority From Trail Climbing: We leave it to the reader to seek the source and then judge themselves whether authority has waxed or waned.
- Locality Of Voice And Jargon: each WikiSpace has its own Context; Chorus Of Voices
- Expectation Of Service
- didn't build on Git because Git doesn't understand moving a paragraph
- Ward keeps his own wiki on his laptop, so his co-workers have to fork a page to make sure it's still there to read when he goes Off-Line!
- note how when Ward gives 2 talks he makes 2 WikiSpace-s, even though many pages might be the "same"
- he has 1 MacMini running a WikiFarm of 800 WikiSpace-s
- I notice he's use (Mac) Google Chrome
- "we started in Ruby and it was a nightmare (for newbies) to install so we moved to NodeJs, and it's been a breeze (maybe because it isn't old enough to have gotten crufty)"
hosting/installation: https://github.com/WardCunningham/Smallest-Federated-Wiki/wiki/Hosting-and-Installation-Guide Though NodeJs is not the reference implementation of the Federated Wiki server, it is the easiest method to get a production-ready Federated Wiki server farm. You will simply need to install Node J S and pull the dependencies for the project. When using Node J S, your Smallest Federated Wiki application is the actual web server, so Apache is not needed.
We have described the clone-on-edit policy. The clone-on-read alternative aggressively retrieves pages making the local wiki behaving like a cacheing proxy. https://github.com/WardCunningham/Smallest-Federated-Wiki/wiki/On-Federating-Wiki
- Nov'2014: but it still doesn't seem to have RSS feed!?!?
- Hacking Social Impact http://hsi.fed.wiki.org/
- Ward Cunningham http://ward.fed.wiki.org/
- Mike Caulfield http://journal.hapgood.net/view/welcome-visitors/view/recent-changes
- PhilJones - then he left
- The main reason, which overshadows pretty much everything else, is that I really hated paragraph-only editing.
- In general, SFW does more than I need it to. While I admire the way it puts multiple pages side-by-side, this adds a lot of complexity in the interface. And it means customizing the look and feel is a complex task.
- Similarly, although it's clever that SFW builds VersionControl into its page file format, I had pages with dozens of revisions, which were taking a long time to load. I'd rather leave version control to Git and have the pages smaller and faster to load.
- Without worrying about keeping history within the page files, I can go back to a format which is plain-text, rather than JSON. This means I can use things like diff and Meld when I want to see what's different between different versions or similar pages on different servers. Other text-oriented SmallTools in Unix should work straight-away.
- I'm moving towards a model where I work locally, and sync. static files for publication, or between my different machines using SyncThing. Once again the value of a complex public facing server is low.
- me http://billseitz.fed.wiki.org/
Edited: | Tweet this!