NOAA Fisheries Integrated Toolbox

Onboarding Tools Overview

Toolbox Overview

The NOAA Fisheries Integrated Toolbox (NOAA FIT) is an interdisciplinary, web-based portal of operational tools that can be used for a variety of applications, including stock assessment modeling, forecasting, and data preparation for fish and protected species, as well as economic and ecosystem modeling. This web portal facilitates easier sharing and comparison of analytical tools (including ensemble modeling, model averaging, model coupling, and shared visualization). The FIT hosts a variety of operational tools developed by NOAA scientists and programmers, as well as those developed in collaboration with, and exclusively by external developers.

Initial Process

  • Request Onboarding
  • NOAA Github Policy walk through for NOAA developers
  • Version Control Implementation
  • Metadata form about tool
  • Coding Standards Best Practices
  • Code Repository Stats (active/inactive, latest version)
  • DOI for referencing code
Request Onboarding

Review the overall process in these slides and then contact fisheries.toolbox@noaa.gov to get started

NOAA GitHub Policy

NOAA has specific guidelines that cover the use of GitHub for version control . Tool designers can opt to use internal tools such as VLAB as well. Only NOAA affiliated personal will be able to directly push to an NOAA GitHub repository but the code is publicly available. Outside collaborators will be able to work separately and perform a pull-request to have their changes accepted.

Version Control Implementation

All code needs to be under version control, locally and on a server. Basic information about version control and best practices for the toolbox are available through resources.

Meta-data Form

Inital authors of a tool fill out a meta-data form (contact fisheries.toolbox@noaa.gov) about their tool which includes, background informtation that can be made public on the tools landing page.

Coding Standards Best Practices

We will implement code review for toolbox tools - though existing software may be too long/complex to review line-by-line, changes will be reviewed. We also recommend you review your code proactively for common software features, including documentation, a test suite, the ability to receive and report issues, etc.. and remedy as many of them as you can during onboarding. Once that is complete, we will issue a Fisheries Toolbox best practices badge.

Code Repository Statistics

Each repository will have code statistics badges on the landing page that allows for easily iddentifying the repositories activity.

Code and Tool Referencing

To ensure that tool authors and collaborators have acknowledgment on their tools, we recommend using code referencing such as zenodo.

Initial Process Completed

Link to Tool: The tool receives a landing page and link on the toolbox website

Basic support level determined : Depending on the collaborators affiliations and development state of the tool, each tool recieves differeing levels of support from the NOAA National Modeling Team.

Subsequent Steps

  • Code Badges
  • Documentation/User manual
  • Tutorials
  • Unit and Functional Testing
  • Continuous Integration
  • Journal Publications
  • Standard Inputs/Outputs
Code Badges

Standardized badges used in general software practices, such as those found on shields.io will be added to the code to help give users a sense of the structure and development stage of the code. Specialized badges developed by the Fisheries Integrated Toolbox team will also be applied.

Documentation and User Manual

Source code documentation should be written in concert with an auto-documentation generator. Use of a documentation generator such as Doxygen, ROxygen, Sphinx, or JSDocs forces a standard approach to in-line documentation as well as allowing an easily readable user-guide for collaborators that can be output to pdf or HTML. These guides can then be linked to from the tools main page and extended to include other information for users and developers.

Tutorials/Examples

Once a stable tool release is created, collaborators should include tutorials and examples that both inform users as well as can be used to ensure that released code works as expected.

Unit and Functional Testing

Unit testing ensures that pieces of the code work as intenteded. Functional testing works to ensure that chunks of code work wotgether correctly.

Continuous Integration

A server based system for collaborators to automate testing during the push of new code ensures that new code additions will work with the underlying code.

Journal Publications

Publishing tools and models with a specific version can be done various ways including through the Journal of Open Source Software.

Standard Inputs/Outputs

Although listed last, if early in the development stage, creating an architecture that standardizes inputs and outputs to the tool with allow a simpler way for users and collaborators to interact with the tool in the future. This will enable outside collaborators to build API's or Front End User Interfaces more simply. We suggest when possible to opt for configuration files written in JSON to enable this.

Continued Contributions

Cloud Application Development