0.4 brainstorming

1. Git workflow: getting on the same page (we should have a solid model and possibly extend gitwash to reflect our model of development)
a. who has merge rights to nipy/nipype master?
b. who has merge rights to nipy/nipype maint/0.3
c. gitwash:
– add info on how to create diff for easy review on github
– who to review
– who to send pull request to (dependency on which brainch it will merge into)?
– adding tools/suggestions from recent posts to nipy
– clear guideline about which branch (master or maint/0.3) to fork. (API changes vs API extensions.)
d. Use of common tag in commit messages : eg BUG, ENH, DOC, FA

2. – nipy umbrella integration

a. integrate other nipy projects with nipype

Examples: - nibabel for auto file-format conversion between nodes - nipy for model specification and estimation (I have started doing this (and got sidetracked): http://github.com/chrisfilo/nipype/tree/nipy_glm) - nitime for ‘resting’ connectivity analysis - dipy nodes for clustering

figure out dependencies of nipy-suite as yarik is aggregating different projects

3. – architecture: open problems, eeky solutions

a. adding functionality to traits, adding more logic cases
handling more complex command line parsing
handling file manipulation

(e.g., ANTS command lines) Camino (which would be nice to have included in the future) uses stdin and stdout for file input output. We might want to keep that in mind while making changes.

b.logging
c.adding setup.py to testing directories
d. traits features/bugs/incompatibilities (eeky solutions):
1. dynamic traits are not pickled properly (CG: And not deepcopied properly either).
2. metadata are class specific, not trait instance specific
3. graphical traits do not take undefined as a state
e. should interface and workflow be separate? (CG: You mean Interface and Node? If so 1)
f. automated test against different versions of softwaredependencies on different platforms?
(CG: Let’s start with automated tutorial running.)
g. integration with ipython 0.11, connectome viewer, slicer

4. – interfaces:

part 1. metadata + api stabilization + tests
a. what is the set of metadata a trait can have and what are their defaults (if not none)
b. additional logical metadata: e.g., requiresoneof
c. is the api stable?
(CG: No – we need to once again think about unifying inputs and outputs names.)
d. standardized unit testing for interfaces.

part 2. additional interfaces
a. finish wrapping freesurfer, spm, afni and fsl interfaces (complete support by 0.4)
(CG: What are we missing from SPM? And FSL (apart from TBSS)?)
b. wrap ANTS, Slicer, PyMVPA, PyXNAT
(CG: Slicer is basically ready… when Enthought will fix pickle and deepcopy bugs :/)
c. wrap “canica” for ica analysis

5. – workflow:

a. relocation handling, relative paths
b. add loops and conditionals on workflows
c. graphical interface/alternative (vistrails)
(CG: as an inspiration have a look at this)
d. metadata generation and extraction for inserting into databases (enhanced provenance tracking)
e. xnat/hid integration
f. backward compatibility, seamless upgrade of processed workflows with new versions of nipype
g. progress tracking across distributed computation (enhanced diagnostic and reporting)
(CG: even for local execution.)
h. centralized common workflows (e.g., see mindflows)
(CG: community portal)
i. web interface for canned workflows (e.g., hospital environments)
j. support for semi-automatic pipelines (when some steps need to be
done manually).