Tectonic shift think tank/Tech requirements/Versioning

Problem phases

Defining a section and breaking it off
- Required actions:
  - Built-in 'spidering' to include required images and templates
  - Come up with some kind of multi-page module selection metadata to easily select pages/chapters/books
Attaching that to a second wiki
- Required actions:
  - Import should store metadata allowing one-click update (resynch)
    - record branch points
  - conceptual: draft vs final publishing spaces
  - conceptual: trusting working with remote people?
Reattaching it to the original as a branch
- Required actions:
  - Short-term: push back on trunk, leaving local history local
    - "What happens in the gated community stays in the gated community"
  - Short-term: import with name suffix, etc to sit alongside
  - Long-term: explicit branching support in the history information
Merging of branches

Downstream/offline copying, similar to "cvs checkout"
- Customization, localization of resources
Upstream publishing
- Private development before publication "Gated community"
  - eg East Asia strong cultural preference to develop privately

different offline forces
- intermittent offline (development / on a plane)
- permanent offline (village w/ no net)
Links to upstream/offline site... how to handle properly
- style them?
Please take a look at this DOJO tool kit http://www.sitepen.com/blog/2007/01/02/the-dojo-offline-toolkit Mpal

grab some stuff from a central site
add new information to it...
- new body of work local to those profs
- use that localized work in teaching
  - like a customized book
and can publish that to let others use it
- it's public
- it's got your name on it!
  - incentive - openness, fame, all that that academics love :)
How does publishing work?
- checkout/push checkin -> to public site

Offline editing that's meant to go back to a central place needs to deal with merging a lot better than what we have now
...
- is there a good FOSS HTML-level and/or prose-level diff/merge tool?