Following discussions with and the support of other programmers on the project, I'm writing to propose we transition to having a TVB code repository on Github, ready for SfN-inspired contributors, and keeping it synchronized with the SVN repo as demonstrated in "Subversion Master with Git Mirrors" . I know this has been proposed before. As others have pointed out, the months leading up to SfN, before the source code goes public, is the right time to push this through if we're going to do it. My analysis follows.
Git & Github style workflow very well known in the open source community and reputed to be very easy to use
Free, reliable hosting for open source projects
Easy and public feedback system that allows rapid two-way communication between issue reporter and core developers
Provides framework for collaborative projects, allowing many developers to work on several organization level projects under a single name
Provides public (or private) tagged issue and milestone system, providing a point of synchronization between core devs who have JIRA access & technical contributors who want to know if || when their bug will be fixed.
Subversion repo remains unknown and unaccessible to public but remains the reference repo.
Discussion & dissection of any code or commits is built in to the interface, hyperlinked with issue disscussion, wiki, etc.
Any comments may use rst style markup to embed pictures, syntax highlighted code, or pictures
Typical contributor workflow isolates the contributors work from the official repo until the maintainers of the official repo decide to merge the code. This workflow requires that a contributor 1. clone the official repo, 2. create a branch 3. make changes 4. submit a pull request, at which point Github supports discussion between anyone on the project on any part of the commit, resulting in rejection or merge.
Good support for branch visualization, which works very well with the typical contributor workflow.
Wiki is provided as well, where information for the technical users is easily provided (and updated by them), e.g. running from source, or coding guidelines for contributions
Github allows unlimited number of users participating (current JIRA is limited at 10 until we pay more, I believe)
Git is a distributed versioning system, which means I can continue to work even when I'm not connected (which has sometimes been an issue in Marseille even in the office).
Most IDEs that provide revision control system support can interface with both SVN and Git
Both SVN and Git have good documentation & packages for every OS
One cannot write plugins for Github (as far as I know), while JIRA can be extended (though who really would take the pains to write Java to do that )
While synchronization of the code between the SVN and Git systems appears to be quite painless (except for potentially large merges), the synchronization between JIRA and the Github issue system may lead to some extra work, though this may be mitigated by another JIRA plugin  which synchronizes them.
Github does not provide some of the more advanced team work & planning features that may seem essential to core developers, such as those under the Agile and Tempo menus of JIRA.
Git has been accused of being complicated to use  (though this is not everyone's experience ) and there are tools to help with complex workflows .
Setup an organization on Github, which we all join
Create the necessary Git mirrors on Github for SVN repos, with copies on the TVB SVN server
Setup hooks in Subversion so that each SVN commit results, automatically, in synchronizing the local git repo and pushing those changes to Github
I (and others who like Git) can begin using the pull-request style workflow to make our changes in Git, and then commiting them to SVN
While Lia should be the one to actually do #1, #2 and #3, I can provide whatever tech support she may desire.
My conclusion is that placing a TVB Git mirror on Github would greatly ease the introduction of TVB as an open source project into a large community of scientific programmers that have already expectations about the workflow of distributed projects. Most importantly, it provides an efficient yet controlled mechanism for the contribution of code to TVB.