From 66cc8784ac99a6cdff362599ae9b437549e7128f Mon Sep 17 00:00:00 2001
From: Mohammad Akhlaghi <mohammad@akhlaghi.org>
Date: Tue, 31 Mar 2020 05:30:29 +0100
Subject: First draft of the version control section and figure complete

The figure was greatly improved, becoming much more clear and descriptive
of some of the main advantages of having version control in a complete
project like Maneage.
---
 paper.tex | 60 ++++++++++++++++++++++++++++++++++++++----------------------
 1 file changed, 38 insertions(+), 22 deletions(-)

(limited to 'paper.tex')

diff --git a/paper.tex b/paper.tex
index 0a85da2..167dea3 100644
--- a/paper.tex
+++ b/paper.tex
@@ -1270,35 +1270,55 @@ This style of managing project parameters therefore produces a much more healthy
 
 Maneage is fully composed of plain-text files distributed in a directory structure (see Sections \ref{principle:text} \& \ref{sec:generalimplementation} and Figure \ref{fig:files}).
 Therefore it can be maintained under under version control systems like Git (for more on version control, see Appendix \ref{appendix:versioncontrol}).
-Every commit in the version controlled history contains a complete snapshot of the executable data lineage, for more see the completeness principle in Section \ref{principle:complete}.
-Maneage is maintained by its developers in a central branch, which we'll call \inlinecode{maneage} hereafter.
+Every commit in the version controlled history contains \emph{a complete} snapshot of the data lineage, for more see the completeness principle in Section \ref{principle:complete}.
 
-The \inlinecode{maneage} branch contains all the low-level infrastructure that is necessary for any project; primarily the configuration features discussed in Section \ref{sec:projectconfigure} that are located under \inlinecode{reproduce/software} in Figure \ref{fig:files}, and executed with the \inlinecode{./project configure} command.
-The main branch only contains a minimal/demonstration analysis in order to be complete.
-The names of all the files related to the demonstration of the \inlinecode{maneage} branch have a \inlinecode{delete-me} prefix to highlight that they must be deleted when starting a new project.
+Maneage is maintained by its developers in a central branch, which we'll call \inlinecode{man\-eage} hereafter.
+The \inlinecode{man\-eage} branch contains all the low-level infrastructure, or skeleton, that is necessary for any project.
+This skeleton is primarily the configuration features discussed in Section \ref{sec:projectconfigure}\footnote{Recall that project configuration files are located under \inlinecode{reproduce/software} in Figure \ref{fig:files}, and executed with the \inlinecode{./project configure} command.}.
+The \inlinecode{maneage} branch only contains a minimal demonstration analysis in order to be complete\footnote{The names of all the files related to the demonstration of the \inlinecode{maneage} branch have a \inlinecode{delete-me} prefix to highlight that they must be deleted when starting a new project.}.
 
 To start a new project, users simply clone it from its reference repository and build their own Git branch over the most recent commit.
-They can then start customizing Maneage for their project in their own branch, and push that branch to their own Git repository for management.
-Project customization will usually start with deleting the demonstration files that have a \inlinecode{delete-me} prefix, and adding their own input datasets, analysis and narrative instead.
+This is demonstrated in the first phase of Figure \ref{fig:branching}: the project started by branching of commit \inlinecode{0c120cb} in \inlinecode{maneage}.
+They can then start customizing Maneage for their project and adding their high-level analysis in their own branch and push it to their own Git repository.
 Manages contains a file called \inlinecode{README-hacking.md} that has a complete checklist of steps to start a new project and remove demonstration parts.
-This file is updated on the \inlinecode{maneage} branch and will always be uptodate with the low-level infrastructure.
+This file is updated on the \inlinecode{maneage} branch and will always be up-to-date with the low-level infrastructure.
 
+%% Exact URLs of imported images.
+%% Collaboration icon: https://www.flaticon.com/free-icon/collaboration_809522
+%% Paper done:         https://www.flaticon.com/free-icon/file_2521838
+%% Paper processing:   https://www.flaticon.com/free-icon/file_2521989
 \begin{figure}[t]
   \includetikz{figure-branching}
   \vspace{-3mm}
-  \caption{\label{fig:branching} Schematic view of main Maneage branch, and how new projects start by branching off of it in two scenarios: pre-publicatioin (allowing easy collaboration) and post-publication (allowing other scientists to easily build upon each other's published work).
-    In the pre-publication scenario, another co-author has made two commits in parallel to the main author, which have later been merged as the project evolves.
-    In the post-publication scenario, another scientist builds upon the published work of another scintist, then merges with the Maneage branch to improve the low-level infrastructure.
+  \caption{\label{fig:branching} Projects start by branching off the main Maneage branch and developing their high-level analysis over the common low-level infrastructure: add flesh to a skeleton.
+    The low-level infrastructure can always be updated (keeping the added high-level analysis intact), with a simple merge between branches.
+    Two phases of a project's evolution shown here: in phase 1, a co-author has made two commits in parallel to the main project branch, which have later been merged.
+    In phase 2, the project has finished: note the identical first project commit and the Maneage commits it branches from.
+    The dashed parts of Scenario 2 can be any arbitraty history after those shown in phase 1.
+    A second team now wants to build upon that published work in a derivate branch, or project.
+    The second team applies two commits and merges their branch with Maneage to improve the skeleton and continue their research.
+    The Git commits are shown on their branches as colored ellipses, with their hash printed in them.
+    The commits are colored based on the team that is working on that branch.
+    The collaboration and paper icons are respectively made by `mynamepong' and `iconixar' and downloaded from \url{www.flaticon.com}.
   }
 \end{figure}
 
-Having the uniform Maneage branch at the core of all projects that use it has the following benefits:
+After a project starts, Maneage will evolve.
+For example new features will be added, low-level bugs will be fixed that are useful for any project.
+Because all the changes in Maneage are committed on the \inlinecode{maneage} branch (that projects also branch-off from) updating the project's low-level infra-structure is as easy as merging the \inlinecode{maneage} branch into the project's branch.
+For example see how Maneage's \inlinecode{3c05235} commit has been merged into project's branch trough commit \inlinecode{2ed0c82} in Figure \ref{fig:branching} (phase 1).
+
+This doesn't just apply to the pre-publication phase, when done in Maneage, a project can be revived at any later date by other researchers as shown in phase 2 of Figure \ref{fig:branching}.
+In that figure, a new team of researchers have decided to experiment on the results of the published paper and have merged it with the Maneage branch (commit \inlinecode{a92b25a}) to fix some possible portability problem for their operating system that was fixed as a bug in Maneage after the paper's publication.
+Propagating bug fixes or improvements in the low-level infrastructure to all projects using Maneage has been one of the reasons it evolved so well over the last 5 years, see Section \ref{sec:futurework}.
+As we started using it in more projects by more users, many bugs were found and improvements made.
+We would then implement it in Maneage and that fix would propagate to all other projects automatically in their next merge.
+
+Modern version control systems provide many more capabilities that can be exploited through Maneage, and the shared branch it has with \emph{all} projects that use it.
+For example a third project can easily merge various high-level components from different projects into its own branch, thus adding a temporal dimension to their data lineage.
+
+
 
-\begin{itemize}
-\item The project's infrastructure can be updated even after publication, when the operating systems or hardware may not be compatible with the project's core components.
-\item Other projects can branch-off an existing project and update their infrastructure while retaining the high-level analysis that they will edit.
-\item Merging work from multiple projects can be as easy as merging their branches: they all share the common \inlinecode{maneage} branch.
-\end{itemize}
 
 
 \subsection{Collaborating with same build directory}
@@ -1325,7 +1345,7 @@ Once the project is complete, publishing the project (its narrative report as we
 
 
 \subsection{Future of Maneage and its past}
-\label{sec:futureworkx}
+\label{sec:futurework}
 As with any software, the core architecture of Maneage will inevitably evolve after the publication of this paper.
 The current version introduced here has already experienced 5 years of evolution and several reincarnations.
 Its primordial implementation was written for \citet{akhlaghi15}.
@@ -1410,10 +1430,6 @@ Once the improvements become substantial, new paper(s) will be written to comple
 Work on the reproducible paper template has been funded by the Japanese Ministry of Education, Culture, Sports, Science, and Technology ({\small MEXT}) scholarship and its Grant-in-Aid for Scientific Research (21244012, 24253003), the European Research Council (ERC) advanced grant 339659-MUSICOS, European Union’s Horizon 2020 research and innovation programme under Marie Sklodowska-Curie grant agreement No 721463 to the SUNDIAL ITN, and from the Spanish Ministry of Economy and Competitiveness (MINECO) under grant number AYA2016-76219-P.
 The reproducible paper template was also supported by European Union’s Horizon 2020 (H2020) research and innovation programme via the RDA EU 4.0 project (ref. GA no. 777388).
 
-%% Collaboration icon: https://www.flaticon.com/free-icon/collaboration_809522?term=collaboration&page=1&position=36
-%% Paper icon: https://www.flaticon.com/free-icon/paper_2541979?term=paper&page=1&position=28
-The collaboration and paper icons in Figure \ref{fig:branching} were respectively made by `mynamepong' and `freepik' and downloaded from \url{www.flaticon.com}.
-
 %% Tell BibLaTeX to put the bibliography list here.
 \printbibliography
 
-- 
cgit v1.2.1

