As the focused projects are open to all developers, a more rigid structure must be in place to ensure that the work that is done is worthwhile. As such, a sub-project authorisation scheme will be used. All sub-projects will be discussed and defined here on the project wiki page. Each sub-project will require some empirical evidence of the advantages of the work. When a satisfactory design has been completed, and the data provided to prove the worth, one of the primary developers [list] will authorise the project, and work can begin.

Once a sub-project has been approved, a temporary branch will be created for the work to take place in. During the development, all commits will be reviewed and commented on by someone from the primary development team. When the work is complete and reviewed, the developer will, possibly with the help of one of the primary developers, merge the changes into the trunk.

Each sub-project will go through a number of stages, the current status of the sub-project should be indicated as part of the sub-project section. The status names are…

1. Design
2. Approval
3. Implementation
4. Testing
5. Validation

The development of proposals should occur in a temporary branch in SVN based off the trunk, this ensures that the trunk isn't tainted during development, and makes it easier to monitor the changes in isolation from other changes happening on the trunk. The reason for having each sub-project in it's own branch, rather than a larger branch for the duration of the containing project is to avoid the problems associated with long lived branches, keeping them up to date, and avoiding the problems of merging such long lived branches back into the trunk.

During such development, the developer should follow normal SVN practice of keeping their branch synced to ongoing changes in the trunk. Care should be taken to only merge changes from the trunk that won't affect the ongoing development. Careful syncing during development will simplify the merge back into the trunk when the time comes.