From 2f3ad2e6a698a2588bf1db5ecb5916f3600d834e Mon Sep 17 00:00:00 2001
From: ansgarz <ansgar.zwick@meissa.de>
Date: Fri, 6 Sep 2024 10:44:55 +0200
Subject: [PATCH] rename folder docs -> doc & add goals.md

---
 .gitignore                |  2 +-
 {docs => doc}/dev.md      |  0
 doc/goals.md              | 36 ++++++++++++++++++++++++++++++++++++
 {docs => doc}/workshop.md |  0
 4 files changed, 37 insertions(+), 1 deletion(-)
 rename {docs => doc}/dev.md (100%)
 create mode 100644 doc/goals.md
 rename {docs => doc}/workshop.md (100%)

diff --git a/.gitignore b/.gitignore
index 41522cb..3554b5f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -21,7 +21,7 @@
 !deps.edn
 !pom.xml
 !dev/
-!docs/
+!doc/
 !resources/
 !src/
 !test/
diff --git a/docs/dev.md b/doc/dev.md
similarity index 100%
rename from docs/dev.md
rename to doc/dev.md
diff --git a/doc/goals.md b/doc/goals.md
new file mode 100644
index 0000000..85eed7b
--- /dev/null
+++ b/doc/goals.md
@@ -0,0 +1,36 @@
+# Goals
+
+### Goals for the end-user
+
+* Easy-to-use user interface
+  * Consistent structure for commands, parameters and options 
+  * User needs to provide only data which is required for the specific task
+    * e.g. data that can be derived from other data should not need to be provided
+  * Informative feedback - in both cases:
+    * Success
+      * high-level information about the performed actions is shown - possibly enriched with selected useful details
+    * Failure
+      * clear information about the error is shown - and where applicable, possible solutions are mentioned
+  * Intuitive user-interface, which requires only little documentation - but where necessary, documentation is provided either in the 
+    * help function or
+    * in separate documents (e.g. in cases where longer explanations are helpful)
+
+### Goals for the developer
+
+* Easy-to-understand architecture and code
+  * clear architecture (with high-level documentation)
+  * clear control flow
+  * sufficient control about the order of execution
+  * consistent and intuitive naming of modules, fields and functions
+  * documentation where helpful
+
+### Goals for end-user and developers
+
+* Clear modularization concept
+  * modules can be run separately (in the sense that they only involve other modules where strictly required)
+    * similar to the interface segregation principle but on module level 
+    * useful for developers e.g. for integration testing and for maintainability of the code (due to less dependencies)
+    * for end-users for selected modules, i.e. if they have a need to run the module separately  
+  * modules can be easily combined by developers in order to provide composed functionality
+  * modules require minimal input (i.e. only input which is strictly necessary for their execution)
+      * similar to the interface segregation principle but on data-level
diff --git a/docs/workshop.md b/doc/workshop.md
similarity index 100%
rename from docs/workshop.md
rename to doc/workshop.md