== Talia Development Process ==

Let's call it TDP ;-) In any case, the process is just a rough guideline for development. It's a shameless ripoff of [http://en.wikipedia.org/wiki/Feature_Driven_Development Feature Driven Development], minus all advanced features. Version 2.0 now includes some management stuff from SCRUM. The presentation/rationale for the process is [http://groupware.discovery-project.eu/index.php?c=files&a=file_details&id=236&active_project=5 on the groupware].

=== Process elements ===

 * '''Requirement''' - A set of functionality required by the user. The requirement contains the user-facing specification.
 * '''Feature''' - A functionality (feature) that can be implemented in Talia. One or features may be required to fulfil a requirement
 * '''Defect''' - Something that doesn't work according to the requirement.
 * '''Task''' - A development activity that takes a certain amount of time. One or more tasks must be completed to implement a feature or fix a defect.
 * '''Idea''' - An idea for some functionality in Talia, the implementation is not planned at this moment.

=== Process Flow ===

 * '''Iteration''' - A development iteration is the time between two development meetings. For each iteration, a fixed set of features will be defined and implemented.
 * '''Weekly update''' - Each team member will send a weekly status update to the mailing list.
 * '''Development meeting''' - During the development meeting, the following process-related things will be discussed:
   * '''Post mortem''' of the previous iteration, identifying problems and possible improvements
   * '''Iteration planning''' for the next iteration. The team will identify the feature to be implemented. Each developer will list the necessary tasks and give an estimate for the completion. The iteration schedule will be kept in Trac.
 
=== Duties ===

Each team member has the following responsibilities:

 * Send the weekly update to the mailing list
 * Regularly update the estimates for the current tasks
 * Make sure that the automated build (cruise control) is not broken over night

== High-Level Process overview ==

 1. Develop the overall model
   * Gather Domain information
   * Study requirements
   * Study existing solutions
   * Indetify requirements
 1. Refine a requirement into features
   * Define Functionality
   * Update the overall model
 1. Create feature list for the component and specs
 1. Build by feature
 1. Repeat steps from 2 on as neccessary
 
== Practices ==

There are some practices that should be followed in the development, if possible. You may find that some are inspired by [http://www.joelonsoftware.com/ Joel on Software]

=== Coding ===

There are some basic CodingGuidelines, that should help with writing legible code. This should help outside contributors to integrate nicely with the code. In general, you should use the same coding style as in the Rails sources.

=== Notes ===

There are some CodingNotes, useful to share thoughts, ideas, troubles and conventions, during the coding process.

=== Specifications ===

 * Readable specifications are better than complete ones
 * Be clear, conscise (and possibly funny)
 * Put specifications on the Wiki

=== Testing ===

 * Each comonent should have a test suite
 * Tests should run against the specification
 * Add tests when you find bugs
 * The automated build should not be broken overnight

=== "Zero Defects" ===

 * Fix bugs before implementing more bugs ;-)

=== Code Reviews ===

 * We should agree on a code review process