The GMAT project will spend a significant amount of time during our R2017 release development on code cleanup, developer documentation, quality improvements, and refactoring for improved long-term positioning.
When adding ideas, please put your initials in-line, so we know who to contact in case more information is needed.
- Ensure that GMAT can continue to respond to customer needs as the team grows and evolves
- Improve work-time to perform frequent developer tasks (i.e. new built-in functions, new)
- Improve documentation of key components (developer docs and code comments)
- Ensure key components developed by those planned are documented and code is cleaned up
- Improve ability to add third-party plugins
- Improve system modularity and documentation
- to support re-use of sub-components
- to facilitate exposing of portions of GMAT through an API
- Address high value P2 improvements that often get overlooked
Key Developer Documentation
- (SPH) How to add new math and built-in GMAT functions.
- (SPH) How to add a new propagator
- (SPH) Overview of all architectural components
- (DJC)Document the code so that all methods are documented and no warnings are issued during builds.
- (DJC) If the Doxygen generator identifies missing blocks, fix them (Subheading: Follow the style guide!)
- (DJC) Warnings are being ignored. This is VERY dangerous – let’s clean them up now, and fix them as they occur.
- (DJC) Remove special case code from the Interpreter subsystem and Moderator(SPH)
- (DJC) Modularize libGmatBase into several libraries. The goal here is to fix the circular dependencies in the code, and as a side benefit to make some core components available as libraries. Having GMAT build with one library is okay, IMO, but the cross-dependencies make code maintenance more difficult.
Expansion to the Parameter Subsystem (DSC)
- (DJC) Add an option that does not require multiple inheritance
- (DJC) Add a registration method so that a class can register, rather than needing to create an object. Here's how I think we might do this -- but this doesn't work:
Existing High Value Quality Tickets
Tickets to be considered for quality improvements should be marked with the JIRA label "Quality". This filter tracks proposed quality improvements. Tickets prioritized as P1s tend to get addressed naturally. This is intended to address some high value P2s that have been ignored for too long.