Project management
The ImageJ and related SciJava projects take advantage of several project management tools.
Contents
Git
ImageJ uses the Git revision control system to manage its source code.
See the Git pages for more information, tutorials, etc.
Maven
ImageJ uses Maven for its project infrastructure.
SciJava projects use the SciJava Maven repository (using Sonatype Nexus) for managing SciJava libraries. Such a repository serves two main purposes:
Deployment
The main purpose of the SciJava Maven repository is to serve the artifacts that are not yet ready to be deployed to OSS Sonatype. Typically, these components are versioned at 0.x—i.e., still in incubation. Once components reach 1.0.0, we try to release them to the central Maven repository via OSS Sonatype.
This purpose is also crucial for agile development across multiple components. For more details, see Nine Reasons to Use a Repository Manager and Repository Management with Nexus.
Proxying
The SciJava Maven repository's secondary purpose is to serve as a fast, local mirror of Maven Central as well as several useful third-party repositories.
It acts as a unified, on-demand mirror for these public Maven repositories, reducing load on the remote servers and potentially reducing local build times.
Developers can benefit from the mirror by adding the following section to their $HOME/.m2/settings.xml file:
<settings>
...
<mirrors>
<mirror>
<id>scijava-mirror</id>
<name>SciJava public mirror repository</name>
<url>https://maven.scijava.org/content/groups/public</url>
<mirrorOf>*</mirrorOf>
</mirror>
</mirrors>
</settings>
Continuous integration
ImageJ uses Travis CI, a cloud-based continuous integration (CI) system, which automatically checks the code for build and test errors.
Issue tracking
SciJava software projects manage tasks and priorities using GitHub Issues:
You can search issues using the ImageJ search portal's GitHub button here:
Previously, some projects used Trac for issue tracking and roadmapping, but all Trac issues have now been migrated to GitHub. The old Trac-based issues are still available as read-only archives: see here for ImageJ and here for LOCI/Bio-Formats.
What are issues for?
Issues and milestones are public-facing entities, yet their content can be highly technical to serve as a roadmap and implementation guide for developers. As we see it, the various audiences for issues and milestones, and their needs, are as follows:
| Who | What | How? |
| Users want... |
to know what's already been reported | Browse and search all open issues. |
| to keep track of issues of interest | Subscribe to desired issues using notifications. | |
| to know which issues were fixed in a release | Browse issues at a particular milestone (e.g., 1.0.0 issues, 1.0.0 bugs, 1.0.0 enhancements). | |
| to ask questions and report new issues | Report new issues using the big green "New issue" button, or via ImageJ's Report a Bug plugin. | |
| Developers want... |
to track their current tasks | Browse issues assigned to a particular developer (e.g., ctrueden, hinerm). |
| to find new tasks to work on | Browse the "help wanted" label or unassigned issues. | |
| a place to discuss implementation details, etc. | Use pull requests. | |
| Maintainers want... |
to easily see what needs attention | Browse issues without a milestone. |
| to ignore inactive issues without closing them | Use the "unscheduled" milestone. | |
| to plan development timelines | Use future milestones (e.g., imagej, scifio). | |
| to report completed features | Use completed milestones (e.g., imagej, scifio). |
To meet these needs, we use the following conventions with GitHub issues:
Milestones
- For short-term active development, use names m1, m2, etc.
- These milestones themselves have no due date and never close, and contain only open issues
- When an issue is closed, it is moved to match its corresponding release milestone.
- Future planned breaking changes should go in SemVer-named milestones.
- All projects should have an "unscheduled" milestone.
- Issues in "unscheduled" are things that core developers and maintainers cannot make time to address.
Issues
- Use the standard GitHub labels.
- For repositories with multiple components (e.g., imagej-ui-swing) add "component:XXXX" labels, in orange, as needed.
- Every issue must belong to a milestone.
- Use the "unscheduled" milestone for inactive issues.
- If you are currently working on an issue, assign it to yourself.
- All issues in near-term milestones should have an assignee.
Using these conventions gives rise to a workflow where new issues come in with no assignee and no milestone, and the project maintainers either assign them to a developer who will carry out the work, or put the issue in "unscheduled" with no assignee.
As issues are closed, they are sorted into milestones which match each project's release tags, making it easy to browse which issues were addressed as part of each release.
The high-level topics of interest (i.e., bugs and enhancements) can easily be filtered by label, while milestones establish the timeline and functional development.
Note that the relationship between milestones and software releases can be one-to-many: e.g., bug-fix releases, or even the addition of new features, may not necessitate their own milestones. Good milestone structure should read similarly to a good git history: informative without being overly verbose.
Patch submissions
The preferred mechanism to contribute improvements to ImageJ and other SciJava components is using GitHub pull requests! See the Contributing page for details.
Roadmap links
- News about ImageJ and Fiji developments, including status updates, observations and comments about ImageJ programming.
- Recent changes to this web site (not the ImageJ code itself).
- BugZilla database of user-reported bugs from the Report a Bug plugin.
Citable code
Many of these tools are employed to facilitate reproducibility from a technical perspective. From a social perspective, we are writing software for science - in which scholarly citations provide another currency for reproducibility.
To this end, developers can now use digital archives like Zenodo to provide consistent methods for citation.
See also
- The Releases page, for more about how these resources are used to release SciJava software artifacts.
