Fundamental Science Practices Frequently Asked Questions
What USGS scientific information products must follow FSP?
How does USGS define peer review and what are the FSP peer review requirements?
How is approval granted and what documents at a minimum must be submitted to the approving official?
What is the foundation of FSP?
What Federal Government policies require the release of scientific data, and how does the USGS intend to meet these requirements?
What is considered USGS scientific software and what are the USGS requirements for releasing it?
What types of project progress information can be reported and why is that important?
The frequently asked questions (FAQs) represent a Bureau consensus to ensure interpretations of Fundamental Science Practices (FSP) policies are uniformly applied throughout the USGS. These comprehensive FAQs not only provide further explanation of the FSP and related publishing policies but also describe the specific procedures and decision making necessary to meet the
FSP Background
Authorship
Review
Approval
USGS Publication Series
Journal Publications
Metadata
Data
Software
Project Reporting and Cooperator Publications
Web Pages, Conferences, Abstracts, and Presentations
Preprints
The FAQs will be updated as necessary and changes in the form of additions or revisions are reflected by date (month/year) as they occur. Questions about the FSP that are not addressed here should be directed to gs_fspac@usgs.gov.
FSP Frequently Asked Questions
What are the review and approval requirements for releasing scientific data to the public? [120]
Data intended for public release are subject to USGS FSP requirements including one data review and one metadata review, reconciliation, and Bureau approval by Science Center Directors or their designees. Data are never placed in the IPDS. [Read more]
What are the recordkeeping requirements regarding research activities? [119]
Documentation and recordkeeping requirements associated with data collection and research activities are found in the USGS Mission-Specific Disposition Schedules and General Records Disposition Schedules.
What are FSP requirements for release of research data collected by USGS but funded by external cooperators? [118]
If data are collected by USGS employees, students, emeritus and other volunteers, and contractors to benefit the USGS, or using USGS funds, it is the responsibility of the USGS to ensure appropriate release. An agreement between the cooperator/collaborator and USGS should specify the data management responsibilities. [Read more]
Where can I find additional information about managing and releasing USGS software? [143]
Refer to the Software Management website for additional information, including best practices and guidance related to the management and release of USGS software.
What hosting platforms are available for releasing USGS scientific software? [142]
The authoritative (or reference) copy of an approved USGS scientific software release must be distributed through a “.gov” server to comply with USGS open access requirements. USGS Git hosting platform is available, including USGS OpenSource GitLab, or USGS InnerSource GitLab, which can be restricted to a specific group of collaborators. [Read more]
What is the distinction in software release requirements between scripts used to prepare data for analysis or graphical visualizations and models or other packages of source code? [141]
Author should work together with their supervisor and Science Center Director to determine if a set of source code is appropriate for release as a USGS scientific software release or if the algorithms or statistical methods would alternatively be more appropriate for inclusion in an associated manuscript or the metadata of a data release. [Read more]
What are some reasons to not use a public repository for developing software? [140]
Department of the Interior, including USGS, applies strict requirements and platform authorizations for sharing software in public repositories. To avoid potential violations, policy-compliant and secure internal code repositories are available for sharing and releasing software. [Read more]
Do software releases need a DOI? [139]
Yes. Approved USGS software releases must be assigned a DOI with the 10.5066 prefix using the USGS Digital Object Identifier (DOI) Creation Tool. Software release products should be assigned a meaningful resource type in the DOI metadata such as software, model, workflow, or another appropriate term. The DOI metadata must appropriately describe the software product. [Read more]
What is required to comply with Federal Source Code Policy? [138]
Generally, source code associated with USGS software releases must be made available at minimum for Federal Government-wide reuse. Source code for USGS software releases must include an appropriate open-source license or secured re-use rights; be included in the USGS source code inventory; be accompanied by documentation to facilitate reuse and participation by third parties. [Read more]
My software release repository requires an open-source license. What can I use? What do I need to know about licenses? [137]
The software developer needs to have an understanding of the repository’s open source licensing requirements; several licensing options may be considered. [Read more]
Can I contribute code to open source projects, and if so, how should I identify and document my contributions? [136]
Yes. Software produced by the USGS and released publicly is in the public domain. However, some software may be partially or wholly owned by a non-Federal partner (e.g., university) and may elect to apply a license, including an open source license that includes restrictions. USGS employees have several options to navigate these circumstances. [Read more]
When does a software release product require a version number? [135]
Because software may be further developed and subsequently updated after the original version is released, all revised software should be released with a new version number. Although the approach to version numbering can vary, revised software releases can be grouped into three general categories: major revision, minor revision, and patch. [Read more]