General Requirements

• When complete, a developer with no prior experience building SproutCore applications must be able to visit the website, install the software, build and deploy a basic Cloud Application, including a data model, server interaction, bound views and controllers, without needing any personal assistance from the developers of the software.
• The overall code base must not have any major bugs that would prevent someone from building a Cloud Application or using a feature included in the framework.  Features and APIs that cannot be adequately tested should be removed from the main framework, to be added in a future release.  Favor fewer features that work correctly over more features that are half-baked.
• All major features must be unit tested so that changes can be easily integrated in the future with high confidence of no regressions.
• A community process must be established so that the focus of development can shift back to the community once major code rework is done.

Framework Requirements

The JavaScript framework must:

• Have no dependencies on third party JavaScript libraries (i.e. Prototype, jQuery, etc.)  
• Work alongside third party libraries so that developers can mix and match components as desired.
• Make it easy for developers to create a data model and a UI, syncing the two layers.  Then to separately sync the data model with the server as well.  Changes to each layer must generally propagate automatically through the application.
• Have a consistent API.  Names of properties and methods must have a constant meaning in all layers of the framework.  Property naming patterns (i.e. fooDidChange) must have a content meaning.
• Eliminate the confusing RHTML view helpers and implement the necessary infrastructure for a drag-and-drop view builder in a future release.
• Break the framework into several smaller subframeworks that can be included/excluded, and iterated independently.

The framework must also provide excellent performance.  Specifically it must:

• Minimize the start time of the application.  Especially on IE7 and IE8.  Even a very complex application should be able to load in under 1 sec including download time.
• Be able to smoothly display a list of 20,000 items with no visible pagination, using data loaded lazily from the server.
• Avoid easy-to-encounter performance traps.  Developers must need to do something obvious to cause major performance issues.  i.e. eliminate issues like the "echo" effect for bindings that can cause unnecessary updates to the UI, slowing performance.
• Provide a mechanism for developers to load only the pieces of the framework they need for their application to minimize the amount of code that must download before the app can start.
• Minimize the number of times the code touches the DOM.  This is especially for performance on IE.

Build Tools Requirements

The build tools worked in 0.9 but were difficult to modify.  They must have the following improvements:

• Easier to customize; adding custom build steps and rules through config files instead of needing to modify the underlying library.
• Support nested frameworks.  This will allow the SproutCore framework to be divided into smaller pieces.
• Unit tests.  All of the components must be unit tests so that changes can be integrated safely.
• Usable as a generic page building system.  The asset management and localization features of the build tools are used as a generic page generator.  Support this case.
• Auto-generate cacheable URLs.  The output bundle format must allow resources to be cached with a 1-year expiration.
• "Packed" JavaScript and Stylesheets.  To further reduce the number of assets load, automatically pack JS and stylesheets for multiple frameworks into single files.
• Lazy-loadable modules.  Allow frameworks to be loaded on demand instead of bundling all of them up front.
• Minimize external dependencies.  This way the gem install won't fail so easily.

Documentation Requirements

The documentation for SproutCore includes both reference material and "how-to" style Programming Guides.

The reference material must meet the following:

• Cover all major functions of the framework.  No classes or methods may be left undocumented except for internal ones.
• Provide accurate description and examples for all classes.
• Be available through a built-in document view and in the online wiki.  
• The online wiki version should be automatically generated from builds when they are released.  This way they can be indexed by Google.

The Programming Guides must meet the following requirements:

• Explain the high-level architecture and "best practice" approach to building a Cloud Application.
• Cover all major tasks covered by SproutCore, including examples and diagrams where appropriate to support all learning styles.
• Be publicly editable so that developers using the programming guides and help to improve them.

Sample Code Requirements

The sample code for SproutCore is intended to provide working examples of how the code should be used.  There are two types of sample code that should be created:

1. Feature sample code simply demonstrates how to implement a particular complex feature such as drag and drop or outline support.  See the Sea Dog project for specific samples that need to be created.
2. Tutorial sample code builds an entire application, end-to-end, in steps along with a tutorial style guide.  One or two of these must be created so that new developers can walk through the entire process.

Website Requirements

The marketing website for SproutCore needs to make it easy for new developers to learn about SproutCore and get started testing it.  Specifically:

• It should sport a unified look and feel across all parts of the website.  Better attention should be paid to the design so that the site looks like we care.
• It should describe on the front page SproutCore's main purpose and value proposition.  
• The primary goal is to encourage a developer to install the build tools and get started trying to code.  
• The secondary goal is to provide links to more information, community support materials, and background information so that a developer can assess the project's size and viability before they get started.  All of these secondary pathways should lead back to encouraging the developer to download the software and give it a try.
• The tertiary goal is to provide links to a developer site that contains resources for developers already working with SproutCore.

SproutCore's website needs to link developers directly to support several community areas as well to support the project.  Specifically:

• Blog.  The blog is used to provide community news and announcements about the development of SproutCore
• Wiki.  The wiki is the primary source of developer documentation and planning materials.  Must be editable by the entire community.
• Ticket tracking.  The ticket tracker should be used to track bugs and, ideally tasks, planned for future work.
• Source code.  Link to the source code on Github so that developers can easily browse changes, download code, etc.
• Mailing List.  IRC.  Link to online sources for help.
• Meetup Group/Upcoming.  A place to schedule events for the community.

All components of the website should be editable by the community, even the main marketing page.  (Though the main marketing page may require approval before changes can be submitted.)  The SproutCore project is intended to be a place for developers writing Cloud Applications to share the cost of building the app.  We want to allow the community to contribute to all pieces of the project, even the marketing side.