Participating in i2b2 sponsored projects #

Certain projects are coordinated by the Foundation.

Attempting to minimize maintenance requirements and encourage rapid development, the method for administering the code base of the sponsored projects will be for individuals to have direct access to the code base. The participants will be responsible for checking out the project, making their changes, and checking in the project. There will only be a main branch for any project. The natural division of the i2b2 Hive into cells and plug-ins will allow projects to be worked on simultaneously. There is no such thing as “checking out the whole i2b2 project”.
If a major change is anticipated for i2b2 services, it will be preceded by publication of the new services so that work on cells and plug-ins can proceed simultaneously. The XML services are universally backward compatible, so that those cells and plug-ins that are not developed further should not become obsolete. Of course, they will generally not be able to take advantage of new functionality in the XML services before they are updated.
The programmers that have access to i2b2 sponsored projects are limited to those who agree to the terms of checking in working code only, and are intensely familiar with the codebase of the project. Programmers are responsible to make sure that their changes are merged properly by them into the main branch. A short Quality Assurance paradigm will follow every check-in. If the new changes to not pass QA, the programmer will be expected to bring the project into compliance. If the programmer refuses to do so, the project will be rolled back to its state before it was checked out by the programmer.
A typical time course of changes would be similar to the following diagram:

At the bottom of the diagram is shown the main branch of code is travelling from left to right. A copy of the code is obtained at some point by the programmer. The programmer works on the code for a while, and when ready to merge the code will check out the main branch. The code is merged while all other developers are blocked from checking out the project. All developers continue to be blocked during a QA period, at the end of which either the code passed and is kept, or fails and is rolled back. The cycle then continues.