aboutsummaryrefslogtreecommitdiff
path: root/paper.tex
diff options
context:
space:
mode:
authorBoud Roukema <boud@cosmo.torun.pl>2021-04-09 14:35:04 +0200
committerBoud Roukema <boud@cosmo.torun.pl>2021-04-09 14:35:04 +0200
commit832aca819ee88c4bb61504e7f9215dc7c50a625e (patch)
tree0c7adc39d6569b3cbb9eef034d1c21b0b768b27b /paper.tex
parent1140619c7f0c69ef0680f581ef1ccba31aba9deb (diff)
Minor copyedits
These are minor last minute copyedits for recently added text, e.g. a git hash is not literally a timestamp.
Diffstat (limited to 'paper.tex')
-rw-r--r--paper.tex4
1 files changed, 2 insertions, 2 deletions
diff --git a/paper.tex b/paper.tex
index 9f73e9b..06596df 100644
--- a/paper.tex
+++ b/paper.tex
@@ -206,7 +206,7 @@ Notebooks can therefore rarely deliver their promised potential \cite{rule18} an
\section{Proposed criteria for longevity}
\label{criteria}
The main premise here is that starting a project with a robust data management strategy (or tools that provide it) is much more effective, for researchers and the community, than imposing it just before publication \cite{austin17,fineberg19}.
-In this context, researchers play a critical role \cite{austin17} in making their research more Findable, Accessible, Interoperable, and Reusable (the FAIR principles\footnote{FAIR originally targeted data, work is ongoing to adopt it for software through initiatives like FAIR4RS (FAIR for Research Software).}).
+In this context, researchers play a critical role \cite{austin17} in making their research more Findable, Accessible, Interoperable, and Reusable (the FAIR principles\footnote{FAIR originally targeted data. Work is ongoing to adopt it for software through initiatives like FAIR4RS (FAIR for Research Software).}).
Simply archiving a project workflow in a repository after the project is finished is, on its own, insufficient, and maintaining it by repository staff is often either practically unfeasible or unscalable.
We argue and propose that workflows satisfying the following criteria can not only improve researcher flexibility during a research project, but can also increase the FAIRness of the deliverables for future researchers.
@@ -451,7 +451,7 @@ There is a thoroughly elaborated customization checklist in \inlinecode{README-h
The current project's Git hash is provided to the authors as a \LaTeX{} macro (shown here in the abstract and acknowledgments), as well as the Git hash of the last commit in the Maneage branch (shown here in the acknowledgments).
These macros are created in \inlinecode{initialize.mk}, with other basic information from the running system like the CPU details (shown in the acknowledgments).
-As opposed to Git ``tag''s, the hash is a core concept in the Git paradigm and is immutable for a given history, it is therefore the recommended timestamp.
+As opposed to Git ``tag''s, the hash is a core concept in the Git paradigm and is immutable for a given history, which is why it is recommended for precisely identifying a project version.
Figure \ref{fig:branching} shows how projects can re-import Maneage at a later time (technically: \emph{merge}), thus improving their low-level infrastructure: in (a) authors do the merge during an ongoing project;
in (b) readers do it after publication; e.g., the project remains reproducible but the infrastructure is outdated, or a bug is fixed in Maneage.