Change: make paragraphs

3 files changed, 25 insertions, 26 deletions

diff --git a/ci-arch.html b/ci-arch.html
index e175cbb..4a3b77b 100644
--- a/ci-arch.html
+++ b/ci-arch.html
@@ -52,13 +52,11 @@
 <p>It is assumed as of the writing of this document that future CI will build on and deploy to containers orchestrated by Kubernetes.</p>
 <p>An important change is that we aim to change things so that as much as possible, all software deployments are to containers orchestrated by Kubernetes</p>
 <h1 id="requirements">Requirements</h1>
-<ul>
-<li><p>This chapter lists the requirements we have for the CI system and which we design the system to fulfil.</p></li>
-<li><p>Each requirement is given a semi-mnemonic unique identifier, so it can be referred to easily.</p></li>
-<li><p>The goal is to make requirements be as clear and atomic as possible, so that the implementation can be more easily evaluated against the requirement: it’s better to split a big, complicated requirement into smaller ones so they can be considered separately. The original requirement can be a parent to all its parts.</p></li>
-<li><p>FIXME: We may want to have a way to track which requirements are being fulfilled, or tested by automated acceptance tests. Need to add something for this, maybe a spreadsheet.</p></li>
-<li><p>These requirements were originally written up in the <a href="https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/CI_Futures_WG/Requirements">WG wiki pages</a> and have been changed a little compared to that (as of the 21 March 2019 version).</p></li>
-</ul>
+<p>This chapter lists the requirements we have for the CI system and which we design the system to fulfil.</p>
+<p>Each requirement is given a semi-mnemonic unique identifier, so it can be referred to easily.</p>
+<p>The goal is to make requirements be as clear and atomic as possible, so that the implementation can be more easily evaluated against the requirement: it’s better to split a big, complicated requirement into smaller ones so they can be considered separately. Requirements can be hierarchical: The original requirement can be a parent to all its parts.</p>
+<p><strong>FIXME:</strong> We may want to have a way to track which requirements are being fulfilled, or tested by automated acceptance tests. Need to add something for this, maybe a spreadsheet.</p>
+<p>These requirements were originally written up in the <a href="https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/CI_Futures_WG/Requirements">WG wiki pages</a> and have been changed a little compared to that (as of the 21 March 2019 version).</p>
 <h2 id="very-hard-requirements">Very hard requirements</h2>
 <ul>
 <li><p>These are non-negotiable requirement that must all be fulfilled by a our future CI system.</p></li>
diff --git a/ci-arch.mdwn b/ci-arch.mdwn
index 004544e..5c9e6f4 100644
--- a/ci-arch.mdwn
+++ b/ci-arch.mdwn
@@ -51,25 +51,26 @@ Kubernetes
 
 # Requirements
 
-* This chapter lists the requirements we have for the CI system and
-  which we design the system to fulfil.
-
-* Each requirement is given a semi-mnemonic unique identifier, so it
-  can be referred to easily.
-
-* The goal is to make requirements be as clear and atomic as possible,
-  so that the implementation can be more easily evaluated against the
-  requirement: it's better to split a big, complicated requirement
-  into smaller ones so they can be considered separately. The original
-  requirement can be a parent to all its parts.
-
-* FIXME: We may want to have a way to track which requirements are
-  being fulfilled, or tested by automated acceptance tests. Need to
-  add something for this, maybe a spreadsheet.
-
-* These requirements were originally written up in the [WG wiki pages][]
-  and have been changed a little compared to that (as of the 21 March
-  2019 version).
+This chapter lists the requirements we have for the CI system and
+which we design the system to fulfil.
+
+Each requirement is given a semi-mnemonic unique identifier, so it can
+be referred to easily.
+
+The goal is to make requirements be as clear and atomic as possible,
+so that the implementation can be more easily evaluated against the
+requirement: it's better to split a big, complicated requirement into
+smaller ones so they can be considered separately. Requirements can be
+hierarchical: The original requirement can be a parent to all its
+parts.
+
+**FIXME:** We may want to have a way to track which requirements are
+being fulfilled, or tested by automated acceptance tests. Need to add
+something for this, maybe a spreadsheet.
+
+These requirements were originally written up in the [WG wiki pages][]
+and have been changed a little compared to that (as of the 21 March
+2019 version).
 
 [WG wiki pages]: https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/CI_Futures_WG/Requirements
 
diff --git a/ci-arch.pdf b/ci-arch.pdf
index e1fd8c9..9ac7a26 100644
--- a/ci-arch.pdf
+++ b/ci-arch.pdf