commit 0a3a035cc794a63af63c86c0c68decfdb2d808f2
Author: Mark Claypool <claypool@cs.wpi.edu>
Date:   Mon Aug 8 13:58:58 2022 -0400

    Updates

diff --git a/evaluation.md b/evaluation.md
index d91cd06..ccfe627 100644
--- a/evaluation.md
+++ b/evaluation.md
@@ -1,6 +1,9 @@
-# Evaluation
+---
+pagetitle: Writing the Evaluation
+version: 0.2
+---
 
-v0.1
+# Writing the Evaluation
 
 Even for an "engineering-heavy" project where the main deliverable is a set
 of tools or software package, there should be an evaluation component.
@@ -8,14 +11,14 @@ of tools or software package, there should be an evaluation component.
 For example, below is some phrasing from an MQP that built an AB testing
 framework:
 
-    Each portion of the framework was tested individually. The Rust 
-    Crate and REST API were both unit tested, while the UI was tested
-    manually. The platform was system tested with a demonstration. The
-    demonstration objectively shows that when combined with the
-    sponsor's software, the framework provides working functionality
-    for A/B testing, and conversion events can be tracked. Based on
-    our tests, demonstration, and the expectations of our sponsors,
-    the framework is a successful minimum viable product for an A/B
-    testing framework. Overall, our system provides the foundation for
-    future experimentation in a serverless space and shows a future
-    for products.
+> Each portion of the framework was tested individually. The Rust
+> Crate and REST API were both unit tested, while the UI was tested
+> manually. The platform was system tested with a demonstration. The
+> demonstration objectively shows that when combined with the
+> sponsor's software, the framework provides working functionality for
+> A/B testing, and conversion events can be tracked. Based on our
+> tests, demonstration, and the expectations of our sponsors, the
+> framework is a successful minimum viable product for an A/B testing
+> framework. Overall, our system provides the foundation for future
+> experimentation in a serverless space and shows a future for
+> products.

commit c953ec66785852640f6e91b87d121fb0e6571aa3
Author: Mark Claypool <claypool@cs.wpi.edu>
Date:   Tue Apr 13 12:10:05 2021 -0400

    Updates

diff --git a/evaluation.md b/evaluation.md
new file mode 100644
index 0000000..d91cd06
--- /dev/null
+++ b/evaluation.md
@@ -0,0 +1,21 @@
+# Evaluation
+
+v0.1
+
+Even for an "engineering-heavy" project where the main deliverable is a set
+of tools or software package, there should be an evaluation component.
+
+For example, below is some phrasing from an MQP that built an AB testing
+framework:
+
+    Each portion of the framework was tested individually. The Rust 
+    Crate and REST API were both unit tested, while the UI was tested
+    manually. The platform was system tested with a demonstration. The
+    demonstration objectively shows that when combined with the
+    sponsor's software, the framework provides working functionality
+    for A/B testing, and conversion events can be tracked. Based on
+    our tests, demonstration, and the expectations of our sponsors,
+    the framework is a successful minimum viable product for an A/B
+    testing framework. Overall, our system provides the foundation for
+    future experimentation in a serverless space and shows a future
+    for products.