The Exponent Project consists of 3 teams: Core Development, Documentation, and Bug Testing. A contributor can become a member of any and all teams should their skills support that potential. The Exponent Project activities are centered around 3 websites: The Development Planning (exponentframework.org), The Documentation site (exponent-docs.org), and Launchpad (launchpad.net/exponent-cms).

Exponent Core Development

• Integrating new code, features and bug fixes to mvc-trunk.
• Creating and publishing builds.
• Planning and setting dates for setting code freezes and release cycles.
• Picking what features will be slated for a particular release.
• Blueprinting new features and system enhancements.
• Strong code commenting and building API Docs.

Documentation

• Working with Core Developers to document any new features.
• Keeping the documentation repository on Launchpad up to date and current with exponent-docs.org
• Drafting Press Releases, News posts, news letters, and other announcement type activities within the community.

Bug Testing

• Detailed testing of the system based off the documentation and blueprints.
• Reporting bugs on Launchpad.
• Working with the Core Developers to decide on severity and assignment to a developer.
• Working with the Core Developers to schedule a release for the fix.

https://launchpad.net/exponent-cms

LaunchPad houses all the BZR branches for all Exponent codelines, bug tracking, and blueprint submission approvals.

Contributor Agreement and Exponent Teams

Once a community member has signed up for a Launchpad account and is added to any of the Exponent Teams, the Contributor Agreement is considered acknowledged and agreed upon.

Branches

mvc-trunk

• The core development brach for Exponent CMS MVC codeline

documentation

• Housing the hard files for documentation to be translated to exponent-docs.org

exp-api

• the API documentation build, based off current mvc-trunk.

Committing to mvc-trunk

Commit Messages
When committing code to mvc-trunk, commit message should be very clear and descriptive to the files, features and fixes being committed.
Commit messages should be prepended with on of the following labels to provide additional clarity to the nature of the commit:

• NEW FEATURE – description of the new feature
• BUG FIX – description of the bug being fixed
• CODE COMMENT – just adding comments where needed
• FILE CLEANUP – moved some things in to better places

other labels will no doubt be added as we move forward.

Code Syncing
The use of a good File Comparison tool is required to ensure that the code being committed is good. Since the current state of the mvc codeline is in a rapid state of development, and committing to the branch on a daily basis will be common, File comparison tools are essential. OIC Group internally uses SmartSynchronize, but there are some great (and cheeper) tools out there as well.

Blueprinting New Features

General Blueprint summary goes in Launchpad, Full blueprint details go on exponentframework.org. See Exponent Framework below for full blueprinting details.

Bug Reporting

Bugs should be logged on Launchpad under the bugs section.

http://exponentframework.org (you're on it)

The Framework site is the initial staging ground for new developments, housing blueprints and other development and contribution information.

Blueprinting

It's important to understand to scope of the work before you get started. Blueprinting is a way to detail out the work that needs to be done before development begins. Core Developers will be required to submit a blueprint for any major changes or features being added to the core code.

The blueprinting process

1. Create a word or open office document based off the appropriate blueprinting template. Templates are available for download on the blueprinting page.
2. Create a new blueprint page on exponentframework.org as a subpage to Blueprints and add a text module for your specific blueprint. Copy your blueprint in to the text module.
3. Head over to https://blueprints.launchpad.net/exponent-cms, and “register a blueprint”.
4. Place the url for the blueprint created on exponentframework.org in the “Specification URL” filed while filling out the form.
5. Work with the other members of the Core Development Team to get the blueprint approved, scheduled for development, tested, and released.

Developer Blogs

Team Members are welcome to post Blogs about their experiences in using the new Exponent 2.0 Framework.

http://exponent-docs.org

The Documentation site will be broken down in to 3 areas: Administrators, Designers, and Developers. All documentation on exponentdocs.org uses Exponent 2's new Help Module, allowing for written documentation, screenshots, videos, tips and tricks.

The Help Module has versioning built in, so that creating documentation can be specifically tied to a version of exponent. For example: initial documentation will be created for version 2.0. after release, websites are deployed, and documentation for that release pertains to that version. Months later, Exponent 2.1 is released with new features. A new version in the help module is created for that version, and all the documentation for version 2.0 is copied to version 2.1 where documenters can update particular portions of the documentation pertaining to that version.

For the Administration portion, this is especially useful as we move forward, as the Help Module was developed with the idea in mind that Help Icons and links will be placed throughout Exponent's administrative interfaces. This will allow allow Administrators to quickly get the information they need pertaining to the tasks they are trying to accomplish. Depending on the version of Exponent they are using, the "Help Links" throughout the system will corespond to the latest version of the administrative documentation on the Documentation site.

Creating Documentation

1. Checkout (bzr co) the documentation repository from launchpad. All documentation should fall in to this file structure:
       module_or_topic_name.odt (.odt files are open office standard)
       module_or_topic_name.txt (for easy copy/paste to the docs site)
       module_or_topic_name.pdf (for download-ablity from the docs site)
       screenshots/
           screenshot1.jpg
           screenshot2.jpg
       videos/
           screencast1.flv (all videos should be in flv format for easy playing on the website)
2. Create a word or open office document based off the appropriate template from the documentation repository on Launchpad or download the documentation package if available.
3. Flesh out the template with the documentation specific to the module or topic, mixing in imagery as necessary.
4. Save all screenshots and imager in the screenshots folder
5. Save any screencasts in to the videos folder a .flv file
6. Commit the new documentation back to launchpad
7. Copy and paste your documentation in to the appropriate places on exponentdocs.org, upload any screenshots, videos, and pdf files.
8. Optionally, if the documentation is specific to the administrative features in Exponent, and the location of a “Get Help” link is specified, work with a member of the Core Development Team to get the help link in place in the system to link to the new documentation.