Plan overall GPF activities

Overall Goal

The overall goal is to demonstrate how papers will be published in the future, going beyond a PDF format and including software, datasets, and workflow all published in open and accessible ways that make the paper transparent, reproducible, and machine indexable. We refer to such a paper as a "geoscience paper of the future” (GPF), and part of this activity will be to define what that means.

Creating a GPF will include tasks such as data publication and citation, software publication and citation, describing software, using metadata standards, and capturing workflows and provenance. GeoSoft instructors will prepare participants through best practices in these topics, and be accessible to help as needed. No programming or computer science background is needed to participate.

Outcomes

Each participant will generate a GPF about their own research.

A Special Issue of a geosciences journal (TBD) that will include all GPFs from this activity. Special Issue editors could be among the participants. Participant papers will be submitted to this Special Issue.

A separate paper co-authored by all participants will discuss challenging issues, best practices, and benefits synthesized by the group during this activity.

Commitment

A 2 day face-to-face meeting (Feb-March) followed by biweekly calls (March-May). Most of the work will be planned at the face-to-face meeting, with about 2 hours of work per week after that.

Phased Plan

1. Jan-Feb: Defining Scope. Anyone interested would write a short proposal specifying the target science paper that will be turned into a GPF. The paper could be: a) a paper they have already published; b) a paper they have not yet published; c) a paper from a colleague that they find useful; d) a seminar paper in their field that people would appreciate seeing published in this way. Proposals can be submitted by individuals or by small teams (up to 4 people if that makes the work more manageable). The proposals will be peer reviewed by the group in an open discussion phase, with the goal of ensuring that the scope of each proposal is feasible.
2. Feb-March: Face-to-Face Kickoff Meeting. Discussions to elaborate the goals as well as training will take place during a 2-3 day face-to-face kickoff meeting (expenses covered by the GeoSoft project). At that meeting, GeoSoft researchers will walk through the specific tasks to be covered and recommend best practices.
3. March-May: Biweekly Goals and Reports. Participants will be given a specific task every two weeks. Each participant will keep an up-to-date electronic document (eg, web site, wiki, google doc) with a detailed report of the work done, which will form the basis for their GPF. A mailing list will be set up to address any questions or issues that may come up. The group will hold a telecon at the end of each 2-week period to share their results and to synthesize what worked, what did not work, and lessons learned.
4. June: Paper Preparation and Review: Participants will finalize writing their papers and will review each other’s papers.

Timeline

An initial plan for the GPF activity was presented to the GeoSoft Early Career Advisory Committee on December 5, 2014.

The major effort for this activity will occur from January to June 2015.

Tasks

1. Make data accessible: Publish input, intermediate, and final data in a public shared repository (e.g., FigShare), and cite it in the article.
2. Ensure software is usable: Gather all the software used in the article, including data preparation codes, pre-processing software, visualization software, and any scripts used. Check that all software runs with input data and generates the results as expected.
3. Make software composable: Define clearly for each piece of software used in the article what are the inputs and outputs and their data types.
4. Sketch the overall workflow: Describe the data flow across software components.
5. Make software executable: Ensure that software can be run by others.
6. Software attribution: Document creators, authors, contributors of the software. Cite the software as appropriate in the paper.
7. Make software accessible: Publish software in a public repository (e.g., GitHub), use a license, and cite it in the article.
8. Software evolution: Tracking updates and new versions of the software.
9. Document domain characteristics: Describe domain data and constraints that help others understand the software.
10. Augmenting a traditional article: Documenting the methods section, the figures, and the references.
11. Preparing the article for publication: Submitting the article to the journal.

Additional Outcomes

Possible additional outcomes to consider include:

• Awards to papers that best demonstrated some recognized quality of a GPF?
• A session with presentations of these papers will be held at the EarthCube All Hands meeting in May 27-28, 2015?
• A session at AGU/GSA 2015?
• The starting of a new GPF repository (within the journal? in EarthCube?)
• Increase recognition for investments in software (eg by measuring software downloads or citations of these papers)?
• Ideas and visibility for follow-on EarthCube proposals?
• A Phase V on reproducibility: ask others to run the software, perhaps try it with their own data? Engage people that could use these papers in a classroom setting?

Participants

Participants will be selected members of the GeoSoft Early Career Advisory Committee who want to learn and demonstrate in practice how to write a GPF.