Minor copyedits - 4.2 intro configuration

Minor edits - reduces about 17 words.

1 files changed, 9 insertions, 9 deletions

diff --git a/paper.tex b/paper.tex
index 7d65f8b..f9712bf 100644
--- a/paper.tex
+++ b/paper.tex
@@ -397,20 +397,20 @@ Very good feedback on the simplicity of using Make has been received from early
 \subsection{Project configuration}
 \label{sec:projectconfigure}
 
-Maneage orchestrates the building of its necessary software in the same language that it orchestrates the analysis: Make (see Section \ref{sec:usingmake}).
-Therefore, a researcher already using Maneage for their high-level analysis easily understands, and can customize the software environment too, without delving into the intricacies of third-party tools.
-Most existing tools reviewed in Section \ref{sec:principles} use package managers like Conda to maintain the software environment, but since Conda itself is written in Python, it does not fulfill our completeness principle \ref{principle:complete}.
-Highly-robust solutions like Nix and GNU Guix do exist, but they require root permissions which is also problematic for this principle.
+Maneage organizes both the building of its software and the analysis pipeline using Make (see Section \ref{sec:usingmake}).
+Thus, a researcher using Maneage for high-level analysis easily understands and can customize the software environment without needing to learn third-party tools.
+The existing tools listed in Section \ref{sec:principles} mostly use package managers like Conda to maintain the software environment, but Conda itself is written in Python, contrary to our completeness principle \ref{principle:complete}.
+Highly-robust solutions like Nix and GNU Guix exist, but these require root permissions, contrary to principle P1.3.
 
-Project configuration (building the software environment) is managed by the files under \inlinecode{reproduce\-/soft\-ware} of Maneage's source, see Figure \ref{fig:files}.
+Project configuration (building the software environment) is managed by the files under \inlinecode{reproduce\-/soft\-ware} of Maneage's source (see Fig.~\ref{fig:files}).
 At the start of project configuration, Maneage needs a top-level directory to build itself on the host (software and analysis).
-We call this the ``build directory'' and it must not be under the source directory (see \ref{principle:modularity}).
+We call this the ``build directory'' and it must not be located inside the source directory (see \ref{principle:modularity}).
 No other location on the running OS will be affected by the project, including the source directory.
-Two other local directories can optionally be specified by the project when inputs (\ref{definition:input}) are present locally: 1) software tarball directory and 2) input data directory.
-Sections \ref{sec:buildsoftware} and \ref{sec:softwarecitation} elaborate more on the building of the required software and the important problem of software citation.
+Two other local directories can optionally be specified by the project when inputs (\ref{definition:input}) are present locally: 1) a software tarball directory and 2) an input data directory.
+Sections \ref{sec:buildsoftware} and \ref{sec:softwarecitation} detail the building of the required software and the important issue of software citation.
 
 A Maneage project can be configured in a container or virtual machine to facilitate moving the project without rebuilding everything from source.
-However, such binary blobs are optional outputs of Maneage, they are not its primary storage/archival format.
+However, such binary blobs are optional. They are not Maneage's primary storage/archival format.
 
 \subsubsection{Verifying and building necessary software from source}
 \label{sec:buildsoftware}