Proposals based on discussions from Day 1 of 3D2:

Ways to solve the breadth/introducability duality

1. Split it up
2. Document and ship what we have
3. Constrain the surface area
4. Coarse split: core vs. widgets
5. Core widget set + non-core widgets

Owen: Atomize and avoid duplication.
Dylan: Avoid an artificial split based on what's finished already.
Brad: Do a competitive analysis

Alex's "Straw Man" proposal (w/Owen's hacks):

Implement a coarse split:

a. Timmed/stripped core
b. Dojo.ext (less frequently used extensions)
c. Widget system (~30 core widgets)
    * identify core widgets, keep only those in main dojo repo
    * look across other toolkits to standardize on API (where makes sense)
d. Widget.extensions community site,
    * separate namespace
    * special purpose/uncommon widgets eg: ColorPicker?, GoogleMap?
    * community contributed widgets (poss. with own licenses)
    * will need gallery for finding
    * will need install scheme for placing in your dojo install
    * dojo-hosted SVN for CLA'd extensions, non-CLAd extensions must host externally  
    * rating system for community approval
    * supply characteristics with submission: version supported, accessibility, etc

e. Distribute packages separately
    * separate downloads for different components
    * different version numbers for different components
    * some SVN scheme to manage checkins/branches that doesn't suck (TBD)
    * separate projects are check-outable transparently via SVN magic
f. Break compatibility for next version, then freeze APIs
g. drive toward core 1.0 core by mid-2007, 1.0 widget core early 2008