|
F1
|
Strategic Plan
|
A publicly available software long-term plan is available.
In this format, the community can also provide comments
and suggestions that will be considered in the ASC strategic
software planning activities. This document will be updated at
least annually.
|
Initial Completion: September 2019
|
|
F2
|
Existing
Functionality
and Future
Deprecation
Decisions
|
Maintaining existing versions of the software past the time
when new versions are introduced is standard practice, and
past versions of ISIS are maintained and available for
download through GitHub. Ensuring that existing functionality
is not deprecated unless alternate solutions are common,
broadly accessible, and equally capable is also standard practice.
We include such information in the ISIS release notes and
maintain both applications for a specified period of time
(typically 6 months).
|
ASC is working with the ISIS TC to
define a sustainable Long-Term Support
(LTS) strategy.
|
|
F3
|
User base
for ASC tools
|
The SAT has recommended that the ASC should continue to
focus ISIS development on “experienced technical users
comfortable in non-graphical environments,” and we interpret
this set of users to primarily include a broad group of those
generating higher order data products (e.g., controlled mosaics),
those using the ISIS API to develop tools or custom software,
and mission teams (e.g., sensor models and data processing
pipelines). We agree with this recommendation, and plan to
tailor our software development efforts towards functionality
applicable to these groups.
|
Ongoing
|
|
F4
|
Open Source,
Community-
Driven Development
Model
|
We have made significant strides to actively facilitate broad
participation in ISIS software development by external
contributors through initiating and Open source community
surrounding the ASC software portfolio.
|
Ongoing
|
|
F5
|
Community and
User Support
Forum
|
The following communication platforms are available for
engagement with users: 1) AstroDiscuss; 2) Git Issues;
3) Git Project; 4) Gitter; 5) Request for Comment (RFC).
|
Completed: February 2019
|
|
F6
|
Task-based
Workflow
Tutorials
|
All ASC-developed tutorials and workshop materials are
available on the ISIS Wiki under Training. We have also
imported previous tips, discussions, and user questions to
AstroDiscuss. In addition, as we are developing our code bases,
we are continuing to focus on both the quality of new
documentation and making improvements to existing
documentation. Given the scope of work performed by ASC,
this finding is also tractably addressed by engaging the existing
community of users to collectively improve the documentation
that we all depend upon. Therefore, we will also continue to
reduce the burden of change submissions and actively engage
all users to submit improvements to our documentation.
|
Completed: March 2019
|
|
F7
|
ISIS on Windows
Subsystem
for Linux
|
ISIS can now be installed and used within the Windows 10
environment, and documentation regarding this functionality
is available. However, this installation method being not
strongly supported (i.e., not part of CI testing).
|
No currently planned actions:
September 2020
|
|
F8
|
Code
Modularity
|
A 5-year modularization plan will be available on GitHub, and
community comment and engagement are strongly encouraged.
This modularization plan will describe a series of milestones for
accomplishing this effort. Details to achieve each milestone will
be determined when that effort begins and made available for
comment by the planetary community via a Request for
Comment.
|
Ongoing
|
|
F9
|
Code
Accessibility
|
The ASC intends to continue to develop all major non-
proprietary software projects through GitHub and within this
Open Source community.
|
Ongoing
|
|
F10
|
Issue
Tracking
|
All non-proprietary Redmine tickets have been transferred to
the GitIssues. New Issues can be posted in the appropriate
GitHub repository to request bug fixes or new features.
|
Completed: February 2019
|
|
F11
|
Software
Development
Standards
|
The ASC has a published style-guide, Guidelines for contributing
to the ASC software portfolio, and a Code of Conduct to facilitate
the growth of an Open Source community surrounding the ASC
software portfolio and to encourage a welcoming environment
with inclusive and diverse participation.
|
Completed: November 2018
|
|
F12
|
Universal
Binary
|
With the release of ISIS 3.6.0 and the use of a conda-based
distribution system, ISIS is built and distributed using a more
universal binary. We will continue to make improvements to the
ISIS build and distribution systems to ensure that installation
dependencies on the host system are minimized.
|
Completed: November 2018
|
|
F13
|
Binary
Installation
|
The transition to a conda-only installation process allows ISIS
to be more easily installed by all users, and this change is in
direct response to community feedback regarding the difficulty
in building and/or installing ISIS. Mission teams or other funded
projects retain the ability to fund a custom ISIS release.
|
Completed: November 2018
|
|
F14
|
Development
Builds
|
The ISIS release schedule communicates how new features and
bug fixes will be distributed to the community on a stable and
regular cadence. Our current release plan includes quarterly
releases and up to three bug fix releases (on an as needed basis)
between each quarterly release (up to 12 bug fix releases
annually). Under the current build environment, weekly ISIS
builds are no longer created. Nightly builds are no longer
generated for public distribution, as they are used to allow for
overnight testing to run and for developers to assess the impact
of the previous day’s code changes (made through merged PRs).
|
Completed: November 2018
|
|
F15
|
Software
Compilation
|
The use of a standard CMake build system and the cross-
platform anaconda dependency management tooling
significantly simplifies the compilation of ISIS for all users.
The ASC agrees that the availability of appropriate test data is
needed to facilitate external developers to build and test the ISIS
system. Improving our testing capability is a long-term effort,
and we are actively and systematically addressing this concern
by adopting a testing framework, working to refactor and
improve tests while reducing overall test volumes, and exploring
options for version controlled large file storage and transmission
support for test data, where appropriate.
|
Ongoing
|
|
F16
|
Software
Optimization
|
The ASC strives to continuously identify ways in which we can
improve software performance. We value community feedback
regarding the applications where optimization would be most
beneficial to the community.
|
Ongoing
|
|
F17
|
Support for
Active Missions
|
The ASC will continue to support active missions by continuing
to improve the responsiveness that ASC can offer those active
teams, advocating for early involvement and consistent
communication with mission and instrument teams to help to
maintain this support, offering to provide mission teams a
technical contact role between ASC and the team, and continuing
to clearly communicate to missions scheduling and other
resource constraints that allow both parties to plan and
adequately budget for mission support.
|
Ongoing
|
|
F18
|
Support for
Small and
Irregular
Bodies
|
The ASC continues to leverage interactions with active flight
missions to make targeted improvements to ISIS to support
small bodies. These include, but are not limited to, support for
bundle adjustment in cartesian coordinates, support for
multi-part DSK files, and improved ray tracing for complex
viewing conditions with occlusion. The ASC will continue to
develop support for small, irregular bodies as a key component
of our software package through a combination of internally
funded software development, open source contribution by the
community, and collaboration with the community.
|
Ongoing
|
|
F19
|
Automated
Image Matching
and
Feature
Recognition
|
The ASC will continue the development of improved automated
matching capabilities within our software portfolio and will seek
to provide documentation that is helpful to the technical user.
|
Ongoing
|
|
F20
|
Broadening
the SPICE
Web Service
|
The ASC continues to actively address SPICE modularization
in the ISIS code base, but we do not plan to make alterations to
the calibration applications in the near term. This finding
highlights an opportunity for community contribution to the
ISIS code base, and the ASC is committed to supporting these
community efforts.
|
FY21 Work Planned for
Calibration Routines
|
|
F21
|
Python
Application
Programming
Interface
|
The ASC agrees that an API to the ISIS library written in a
dynamic language would be invaluable, but caution that the
immediate exposure of an API would likely not satisfy the
majority of ISIS users. Additional input is needed to determine
how such an API would be most often used by the community.
|
Ongoing
|
|
F22
|
Software
Management
Leadership
|
The ASC has put in place a new management structure that
includes both a Software Development Lead (currently Jay Laura
/ jlaura@usgs.gov / @jlaura) and a Technical Operations Lead
(currently Robin Fergason / rfergason@usgs.gov / @rfergason).
|
Completed: October 2018
|
|
F23
|
Workload
|
The ASC software portfolio is Open Source and the work
proposed is inline with that capacity.
|
Completed: March 2019
|
|
F24
|
Continued
Funding
for Support and
Maintenance
|
The ASC has dedicated funding through our NASA-funded
software portfolio to support bug fixes and feature
enhancements requested by the community through GitHub
Issues. In addition, we also dedicate effort toward specific,
larger efforts related to support and maintenance (e.g.,
improving our release system and making test data more easily
available) that make code submission by external contributors
less burdensome.
|
Completed ASC responsibility
through communication with
NASA HQ: July 2019
|
|
F25
|
External Review
of ASC Funding
Requests
|
The ASC is inviting external feedback by the community at
many different levels in the process, as we believe that
community input is extremely valuable. The ASC is actively
seeking to engage users and are more transparent in our
communication regarding software direction through
1) making our software long-term plan publicly available for
comment; 2) standing up a Technical Steering Committee;
and 3) initiating a Request for Comment (RFC) to describe
proposed changes to the ASC code base to encourage broad
community comment and engagement.
|
Completed ASC responsibility
through communication with
NASA HQ: July 2019
|
