The jQuery folks are nice enough to provide a raw XML dump of their API documentation (http://api.jquery.com).
I wrote a quick macro to parse that data and store it as tiddlers:
http://svn.tiddlywiki.org/Trunk/contributors/FND/plugins/jQueryDocsImportMacro.js
Demo:
http://fnd.lewcid.org/tmp/jQueryAPI.html

http://groups.google.com/group/tiddlywikidev/browse_thread/thread/4974fa9717f669ab

The following guide is to serve as a quick introduction to Git-SVN, hopefully making it easy for others (e.g. fellow Osmosoftonians) to get started.
Note that I’m an enthusiastic command-line user, which is why this guide does not cover any GUIs. Also, I’m far from being a Git expert at this point, so feel free to suggest improvements!

Initial Setup

• check out Subversion repository:^[2][3]

  git svn clone -T[trunk_subdir] -t[tags_subdir] -b[branches_subdir] [URL]

  (e.g. git svn clone -TTrunk -tTags -bBranches http://svn.tiddlywiki.org)
  N.B.: For TiddlyWiki, it might not be desirable to convert the Trunk, Tags and Branches directories to metadata, as this might interfere with Cook.

• create branch for work in progress (WIP):

  git checkout -b [branch]

Working with Git

• modify files on WIP branch, creating (and amending) local commits:^[4]

  git add [files]
  git commit -m "[message]"
  git commit --amend

• switch to master branch:

  git checkout master

• grab changes from WIP branch:^[5]

  git merge --squash [branch]

• commit changes and push to Subversion:^[6]

  git commit -a -m "[message]"
  git svn dcommit

• switch back to WIP branch:^[7]

  git checkout [branch]
  git reset --hard master

  (if there are additional commits on the branch, git rebase master should be used — which might lead to merge conflicts though)

Useful Commands

• git branch (list, create or delete branches)
• git diff [-w] [--color-words] (display changes)
• git apply (patching)
• git status (working tree status)
• git log (commit history)^[8]
• git reflog (comprehensive history)
• git svn rebase (update local repository)
• git checkout [files] (revert changes)
• git config (user preferences)^[9]
• git gui (graphical user interface)
• gitk (repository browser)

Thanks to Kerry for getting me started with Git in the first place!

2008-09-30: minor updates (removed hyphens from git svn commands, updated .gitconfig, note on converting metadata on checkout)

2008-11-03: changed final git merge master to git reset --hard master (includes a note on git rebase master, as recommended by Kerry)

1. The same is true for other DVCS, like Mercurial — though I have only worked with Git so far.
2. Cloning an entire Subversion repository can take a while (mostly due to protocol overhead) — an alternative is to grab only the latest revision: git svn init [URL]; git svn fetch -r HEAD.
3. Instead of manually specifying directory names for trunk, tags and branches, -s can be used for the standard naming convention “trunk”, “tags” and “branches”.
4. Use git commit -a -m "[message]" to automatically add all modified files.
5. Squashing means that several local commits can be merged into a single commit.
6. dcommit will automatically perform an update (rebase).
7. The merge operation is required due to the rewritten commit history on the master.
8. git log can be used to display the differences between two branches: git log <a>..<b> — for example: git log origin/master..master (Git repositories), git log remotes/trunk..master (SVN repositories)
9. My current .gitconfig file (latest version on GitHub):

   [user]
   	name = FND
   [alias]
   	ci = commit
   	cia = commit -a
   	cim = commit -m
   	ciam = commit -a -m
   	co = checkout
   	diffi = diff -M --color-words
   	diffw = diff -M -w
   	diffx = diff -M -w --color-words
   	merges = merge --squash
   [color]
   	branch = auto
   	diff = auto
   	status = auto
   [color "branch"]
   	current = yellow reverse
   	local = yellow
   	remote = green
   [color "diff"]
   	plain = white
   	meta = yellow bold
   	frag = magenta bold
   	old = red bold
   	new = green bold
   [color "status"]
   	header = white
   	added = yellow
   	changed = green
   	untracked = cyan
   [svn]
   	rmdir = true

Our first idea was to use TiddlyWiki to aggregate data from various social networks, turning into a sort of global dashboard for users. However, the OpenSocial API does not permit this (yet, according to Google).
So we went for the opposite approach, embedding TiddlyWiki as an OpenSocial gadget. This opens up quite a number of interesting possibilities — for example, users composing and sharing notes.

The first step was to simply take the entire TiddlyWiki source code and wrap it into the required XML framework. Apart from having to deal with nested CDATA sections, this actually worked without too many problems (also thanks to the gracious help from a Google expert). We used TinyTiddly‘s externalized core to save us the headache of excessive scrolling through the source code. Since gadgets are limited to a certain display size, we decided to apply a theme designed for handheld devices^[1] (created by BT’s James Lelyveld).
The preliminary results can be seen here; the XML gadget file is located here.

The next steps, should we decide to follow up on this, are to integrate this with ccTiddly, as this prototype does not yet provide any way for saving the inputs. Also, there are some issues with running TiddlyWiki within a frame — for example, paramifiers and direct permalinks to specific tiddlers do not work properly.

While I’m not a huge fan of social networks (apart from Twitter, if that counts), this was a very interesting experience. Overall, the event was very enjoyable and well-organized, with quite a number of interesting attendees.

1. using Chef to build it from source

Many people believe that the open-source principle equals grassroots democracy.
However, I don’t think that’s a fair assessment.

While community involvement is generally important and valuable, it is also a double-edged sword.
For certain issues, opening the debate to the community at large can prove an obstacle to making progress. That’s because discussions involving a large number of people can easily get out of hand — especially if there is no tangible concept yet to base the discussion on.
Also, many tasks require a certain expertise, and should thus be delegated to qualified contributors. The wisdom of crowds (as described by Surowiecki) is no panacea, but only applies to certain kinds of decisions.

That is not to say the community should be excluded though. The entire process needs to be transparent — not only to avoid alienating contributors and users, but also because diverse opinions and perspectives are essential to achieving optimal results (e.g. to avoid common traps like coders’ tunnel vision).
But this involvement should be timed carefully. Gathering feedback on a well-thought-out concept will often be more productive than starting a discussion without a solid foundation.

Bottom line: In my opinion, open-source projects are more about transparency and a diverse assortment of skills, rather than forcing everyone’s direct involvement on every single level.

Thanks to Saq and Phil for their insights on this topic.
I’d be happy to continue the discussion in the comments…