Minor typo corrections

After the submission and reading through the text another time I found some
typo corrections and fixed them. Also now that David is an author, I
removed him from the people to acknowledge (David brought this up himself,
thanks David ;-)).

1 files changed, 11 insertions, 12 deletions

diff --git a/paper.tex b/paper.tex
index cfab672..283e814 100644
--- a/paper.tex
+++ b/paper.tex
@@ -346,8 +346,7 @@ Section \ref{sec:collaborating} discusses the sharing of a built environment, an
 Scripts (in Shell, Python, or any other high-level language) are usually the first solution that come to mind when non-interactive, or batch, processing is needed (the completeness principle, see \ref{principle:complete}),
 However, the inherent complexity and non-linearity of progress, as a project evolves, makes it hard to manage such scripts.
 For example, if $90\%$ of a research project is done and only the newly-added final $10\%$ must be executed, a script will always start from the beginning.
-It is possible to manually ignore (with some conditionals), or manually comment, parts of a script to only do a special part.
-However, such conditionals/comments will only add to the complexity and will discourage experimentation on an already-completed part of the project.
+It is possible to manually ignore (with some conditionals) or comment already completed parts, however this only adds to the complexity and will discourage experimentation on an already-completed part of the project.
 These problems motivated the creation of Make in the early Unix operating system \citep{feldman79}.
 
 The Make paradigm starts from the end: the final \emph{target}.
@@ -508,8 +507,8 @@ These \LaTeX{} macro files thus form the core skeleton of a Maneage project: as
 Before the modular \LaTeX{} macro files of Section \ref{sec:valuesintext} are merged into the single \inlinecode{project.tex} file, they need to pass through the verification filter, which is another core principle of Maneage (\ref{principle:verify}).
 Note that simply confirming the checksum of the final PDF, or figures and datasets is not generally possible: many tools write the creation date into the produced files.
 To avoid such cases the raw data (independently of their metadata-like creation date) must be verified. Some standards include such features, for example, the \inlinecode{DATASUM} keyword in the FITS format \citep{pence10}.
-To facilitate output verification, the project has a \inlinecode{verify.mk} subMakefile (see Figure \ref{fig:datalineage}) and \inlinecode{verify.tex} the only prerequisite of \inlinecode{project.tex} that was described in Section \ref{sec:valuesintext}.
-Verification is the boundary between the analytical phase of the paper, and the production of the report.
+To facilitate output verification, Maneage has the \inlinecode{verify.mk} subMakefile (see Figure \ref{fig:datalineage}) which is the second-last subMakefile.
+Verification is thus the boundary between the analytical phase of the paper, and the production of the report.
 It has some tests on pre-defined formats, and other formats can easily be added.
 
 \subsubsection{The analysis}
@@ -625,7 +624,7 @@ Every commit in the version-controlled history contains \emph{a complete} snapsh
 Maneage is maintained by its developers in a central branch, which we will call \inlinecode{man\-eage} hereafter.
 The \inlinecode{man\-eage} branch contains all the low-level infrastructure, or skeleton, that is necessary for any project as described in the sections above.
 As mentioned in Section \ref{sec:maneage}, to start a new project, users simply clone it from its reference repository and build their own Git branch over it
-This is demonstrated in the first phase of Figure \ref{fig:branching} where a project has started by branching-off of commit \inlinecode{0c120cb}.
+This is demonstrated in Figure \ref{fig:branching}(a) where a project has started by branching-off of commit \inlinecode{0c120cb}.
 
 %% Exact URLs of imported images.
 %% Collaboration icon: https://www.flaticon.com/free-icon/collaboration_809522
@@ -646,18 +645,18 @@ This is demonstrated in the first phase of Figure \ref{fig:branching} where a pr
 
 After a project starts, Maneage will evolve, for example, new features will be added or low-level bugs will be fixed.
 Because all projects branch-off from the same branch that these infrastructure improvements are made, updating the project's low-level skeleton is as easy as merging the \inlinecode{maneage} branch into the project's branch.
-For example, in Figure \ref{fig:branching} (phase 1), see how Maneage's \inlinecode{3c05235} commit has been merged into project's branch trough commit \inlinecode{2ed0c82}.
+For example, in Figure \ref{fig:branching}(a), see how Maneage's \inlinecode{3c05235} commit has been merged into project's branch trough commit \inlinecode{2ed0c82}.
 This allows infrastructure improvements and fixes to be easily propagated to all projects.
 
-Another useful scenario is reviving a finished/published project at later date, possibly by other researchers as shown in phase 2 of Figure \ref{fig:branching} (e.g., assuming the original project was completed years ago, and is no longer directly executable).
-Other scenarios include projects that are created by merge various other projects.
+Another useful scenario is reviving a finished/published project at later date, possibly by other researchers as shown in Figure \ref{fig:branching}(b), e.g., assuming the original project was completed years ago, and is no longer directly executable.
+Other scenarios include projects that are created by merging various other projects.
 Modern version control systems provide many more capabilities that can be leveraged through Maneage in project management, thanks to the shared branch it has with \emph{all} derived projects, and that it is complete (\ref{principle:complete}).
 
 \subsection{Multi-user collaboration on single build directory}
 \label{sec:collaborating}
 
 Because the project's source and build directories are separate, it is possible for different users to share a build directory, while working on their own separate project branches during a collaboration.
-Similar to the parallel branch that is later merged in phase 1 of Figure \ref{fig:branching}.
+Similar to the parallel branch that is later merged in Figure \ref{fig:branching}(a).
 To enable this mode, \inlinecode{./project} script has a special \inlinecode{--group} option which takes the name of a (POSIX) user group in the host operating system.
 All files built in the build directory are then automatically assigned to this user group, with read and write permissions.
 Of course, avoiding conflicts in the build directory, while members are working on different branches is up to the team.
@@ -704,7 +703,7 @@ Furthermore, writing parsers of Maneage projects to generate Research Objects is
 
 Maneage was awarded a Research Data Alliance (RDA) adoption grant adhering to the recommendations of the publishing data workflows working group \citep{austin17}.
 Its user base (and thus its development) grew phenomenally afterwards.
-But it is far from complete: bugs will be fixed and its core architecture will continue evolve after the publication of this paper.
+However, bugs will still be found and its core architecture will continue to evolve after the publication of this paper.
 A list of the notable changes after the publication of this paper will be kept in the \inlinecode{README-hacking.md} file.
 
 Based on feedback from early adopters, we have seen the following caveats for Maneage.
@@ -716,7 +715,7 @@ Once the usage of these tools was witnessed in practice, these tools were adopte
 A second caveat is the fact that Maneage is effectively an almost complete GNU operating system, tailored to each project.
 Maintaining the various packages can consume time for its core developers.
 In Maneage, package management (Section \ref{sec:projectconfigure}) is in the same language as the analysis, therefore some users are already adding their necessary software in it and submitted them to the core Maneage branch, thus propagating the improvement to all projects using Maneage.
-With a larger user-base look forward to an increasing number of such contributors, hence decreases the burden on our core team.
+With a larger user-base we look forward to an increasing number of such contributors, hence decreasing the burden on our core team.
 
 Another caveat that has been raised is that publishing the project's reproducible data lineage immediately after publication may hamper their ability to continue with followup papers because others may do it before them.
 Given the strong integrity checks in Maneage, we believe it has features to address this problem in the following ways:
@@ -761,7 +760,7 @@ With a larger user-base and wider application in scientific (and hopefully indus
 
 %% Acknowledgements
 \section*{Acknowledgments}
-The authors wish to thank David Valls-Gabaud, Alice Allen, Johan Knapen, Ignacio Trujillo, Roland Bacon, Konrad Hinsen, Yahya Sefidbakht, Simon Portegies Zwart, Pedram Ashofteh Ardakani, Elham Saremi, Zahra Sharbaf and Surena Fatemi for their useful suggestions and feedback on Maneage and this paper.
+The authors wish to thank Alice Allen, Johan Knapen, Ignacio Trujillo, Roland Bacon, Konrad Hinsen, Yahya Sefidbakht, Simon Portegies Zwart, Pedram Ashofteh Ardakani, Elham Saremi, Zahra Sharbaf and Surena Fatemi for their useful suggestions and feedback on Maneage and this paper.
 We also thank Julia Aguilar-Cabello for designing the Maneage logo.
 During its development, Maneage has been partially funded (in historical order) by the following institutions:
 The Japanese Ministry of Education, Culture, Sports, Science, and Technology ({\small MEXT}) PhD scholarship to M.A and its Grant-in-Aid for Scientific Research (21244012, 24253003).