From d11b81f10866a17616878ca6a035eb721e25566f Mon Sep 17 00:00:00 2001
From: Mohammad Akhlaghi <mohammad@akhlaghi.org>
Date: Mon, 30 Mar 2020 06:01:36 +0100
Subject: Section on starting new projects, and publishing project added

With the main structure of Maneage explained, I have started to explain how
a new project is created, along with a schematic diagram that shows two
scenarios of how Git can help with project management.
---
 paper.tex | 91 +++++++++++++++++++++++++++++++++++++++++++++++++++++----------
 1 file changed, 77 insertions(+), 14 deletions(-)

(limited to 'paper.tex')

diff --git a/paper.tex b/paper.tex
index dc5c032..0a85da2 100644
--- a/paper.tex
+++ b/paper.tex
@@ -254,7 +254,9 @@ Data provenance thus provides a high-level view of the data's genealogy.
 % Technical data lineage is created from actual technical metadata and tracks data flows on the lowest level - actual tables, scripts and statements.
 % Technical data lineage is being provided by solutions such as MANTA or Informatica Metadata Manager. "
 Data lineage is commonly used interchangably with Data provenance \citep[for example][\tonote{among many others, just search ``data lineage'' in scholar.google.com}]{cheney09}.
-However, for clarity, in this paper we refer to the term Data lineage as a low-level and fine-grained record of the data's genealogy, down to the exact command that produced each intermediate step.
+However, for clarity, in this paper we refer to the term ``Data lineage'' as a low-level and fine-grained recording of the data's source, and operations that occur on it, down to the exact command that produced each intermediate step.
+This \emph{recording} doesn't necessarily have to be in a formal metadata model.
+But data lineage must be complete (see completeness principle in Section \ref{principle:complete}), and allow extraction of data provenance metadata, and thus higher-level operations like visualization of the workflow.
 
 
 \subsection{Definition: reproducibility \& replicability}
@@ -901,7 +903,7 @@ We'll follow Make's paradigm (see Section \ref{sec:usingmake}) of starting form
     \includetikz{figure-data-lineage}
   \end{center}
   \vspace{-7mm}
-  \caption{\label{fig:datalineage}Schematic representation of built file dependencies in a hypothetical project/pipeline using the reproducible paper template.
+  \caption{\label{fig:datalineage}Schematic representation of data lineage in a hypothetical project/pipeline using Maneage.
     Each colored box is a file in the project and the arrows show the dependencies between them.
     Green files/boxes are plain text files that are under version control and in the source-directory.
     Blue files/boxes are output files of various steps in the build-directory, located within the Makefile (\inlinecode{*.mk}) that generates them.
@@ -942,18 +944,27 @@ When the names of the subMakefiles are descriptive enough, this enables both the
 \subsubsection{Ultimate target: the project's paper or report (\inlinecode{paper.pdf})}
 \label{sec:paperpdf}
 
-The ultimate purpose of a project is to report its result and interpret it in a larger context of human knowledge.
-In scientific projects, this is the final published paper.
-The raw result is usually dataset(s) that is (are) visualized, for example as a plot, figure or table and blended into the narrative description.
-In Figure \ref{fig:datalineage} it is shown as \inlinecode{paper.pdf} and the instructions to build \inlinecode{paper.pdf} are in \inlinecode{paper.mk}.
-In the complete directed graph of Figure \ref{fig:datalineage}, \inlinecode{paper.pdf} is the only node that has no outward edge or arrows (further showing that it is the ultimate target: nothing depends on it).
+The ultimate purpose of a project is to report its result.
+In scientific projects, this ``report'' is the published, or draft, paper.
+In the industry, it is a quality-check and analysis of the final data product.
+The raw result is usually dataset(s) that is (are) visualized in the report, for example as a plot, figure or table and blended into the narrative description.
+In Figure \ref{fig:datalineage} it is shown as \inlinecode{paper.pdf}.
+Note that it is the only built file (blue box) with no arrows leaving it.
+In other words, nothing depends on it: highlighting its unique ``ultimate target'' position in the lineage.
 
+The instructions to build \inlinecode{paper.pdf} are in \inlinecode{paper.mk}.
 The report's source (containing the main narrative, its typesetting as well as that of the figures or tables) is \inlinecode{paper.tex}.
 To build the final report's PDF, \inlinecode{references.tex} and \inlinecode{project.tex} are also loaded into \LaTeX{}.
-Another class of files that maybe loaded into \LaTeX{}, but are not shown to avoid complications in the figure, are the figure or plot PDFs which may have been created during the analysis steps.
 \inlinecode{references.tex} is part of the project's source and can contain the Bib\TeX{} entries for the bibliography of the final report.
 In other words, it formalizes the connections of this scholarship with previous scholarship.
 
+Another class of files that maybe loaded into \LaTeX{}, but are not shown to avoid complications in the figure, are the figure or plot data, or built figures.
+For example in this paper, the demonstration figure shown in Section \ref{sec:analysis} is drawn directly within \LaTeX{} (using its PGFPlots package).
+The project only needed to build the plain-text table of numbers that were fed into PGFPlots (\inlinecode{tools-per-year.txt} in Figure \ref{fig:datalineage}).
+However, building some plots may not be possible with PGFPlots, or the authors may prefer another tool to generate the visualization's image file \citep[for example with Python's Matplotlib, ][]{matplotlib2007}, then load that image file into \LaTeX{} as a graphic.
+For this scenario, the actual image file of the visualization can be used in the lineage, for example \inlinecode{tools-per-year.pdf} instead of \inlinecode{tools-per-year.txt}.
+See Section \ref{sec:publishing} on the project publication for special considerations regarding these files.
+
 
 
 
@@ -1214,7 +1225,8 @@ When descriptive names are chosen for the subMakefiles, a simple glance over the
 \begin{figure}[t]
   \input{tex/src/figure-src-topmake.tex}
   \vspace{-3mm}
-  \caption{\label{fig:topmake} Important parts of High-level \inlinecode{top-make.mk}.
+  \caption{\label{fig:topmake} General view of the High-level \inlinecode{top-make.mk} Makefile which manages the project's analysis that is in various subMakefiles.
+    See Figures \ref{fig:files} \& \ref{fig:datalineage} for its location in the project's file structure and its data lineage, as well as the subMakefiles it includes.
   }
 \end{figure}
 
@@ -1253,17 +1265,66 @@ This style of managing project parameters therefore produces a much more healthy
 
 
 
+\subsection{Projects as Git branches of Maneage}
+\label{sec:starting}
+
+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.
+
+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.
 
-\subsubsection{Building the paper}
-\label{sec:buildingpaper}
+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.
+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.
+
+\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.
+  }
+\end{figure}
+
+Having the uniform Maneage branch at the core of all projects that use it has the following benefits:
 
 \begin{itemize}
-\item Discuss the importance of putting the \LaTeX{} related files in \inlinecode{texdir}. Especially how \inlinecode{tex/build} points to it.
+\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}
+\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 branch of Maneage during a collaboration.
+
+
+
+
+\subsection{Publishing the project}
+\label{sec:publishing}
+
+Once the project is complete, publishing the project (its narrative report as well as the full lineage) is the final step.
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{itemize}
+\item \inlinecode{./project make dist}.
+\item The data files, or image files that go into the \LaTeX{} paper in \inlinecode{texdir}. Especially how \inlinecode{tex/build} points to it.
 \item Discuss how easy it is to built graphics outside of \LaTeX{}.
 \end{itemize}
 
 
-\subsection{Future work and history}
+\subsection{Future of Maneage and its past}
 \label{sec:futureworkx}
 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.
@@ -1349,7 +1410,9 @@ 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

