Documentation

3 files changed, 51 insertions, 3 deletions

diff --git a/docs/design.md b/docs/design.md
index 4ab2e887..aff49183 100644
--- a/docs/design.md
+++ b/docs/design.md
@@ -49,6 +49,39 @@ Use-case specific controllers are used to operate on the data. Controllers allow
 Rather than splitting controllers by domain type (e.g. an email controller, or a calendar controller), we specifically write controllers for specific usecases (e.g. an email editor), that exposes all required actions. That way we ensure that the API's a UI is working with is always clear an consice, and that we have all domain logic captured in the domain logic layer, rather than the UI layer.
 Of course controllers will need to share functionality internally as soon as an action is available from more than one place.
 
+### Email Domain Logic
+* Folder list
+    * Folder List Controller
+        * Move mail to folder
+        * Move/Copy/Delete folder
+        * Synchronize folder
+    * Folder List Model
+        * Mixes akonadi next queries and subqueries (folder list with smart folders)
+        * name
+        * statistics
+
+* Mail list
+    * MailListController
+        * Mark as read
+        * Flag as important
+        * Move to trash
+    * MailListModel
+        * subject
+        * date
+        * sender
+        * folder
+    * ThreadModel
+        * thread leader (otherwise like maillist model)
+        * number of mails in thread
+
+* Mail Viewer
+    * MailViewController
+        * reply
+        * forward
+        * move to trash
+    * MailModel
+        * subject, date, sender, folder, content, attachments
+
 ## Infrastructure
 
 The infrastructure layer interfaces with the rest of the system. It is the place where we can integrate with various native infrastructure parts.
@@ -59,8 +92,14 @@ Note: The infrastructure blocks will use only types provided by the domain logic
 ### Akonadi Next
 Akonadi Next is used for primary data access and handles all synchronization.
 
+Interactions with Akonadi Next involve:
+* Adding/removing/configuring resources
+* Triggering synchronization
+* Querying of data
+* Creating/Modifying/Removing entities
+
 ### Configuration
-Configuration as traditionally store in config files in ~/.kde
+Configuration as traditionally stored in config files in ~/.kde
 
 ### Notification
 Notifications for the system.
diff --git a/docs/project.md b/docs/project.md
index 36980d13..4d942c90 100644
--- a/docs/project.md
+++ b/docs/project.md
@@ -1,3 +1,10 @@
+# Why?
+This project started with the aim to produce a product that doesn't cater to all usecases, but does what it does well.
+We want a codebase that is well maintainable by a small team, and that can move fast.
+We want a codebase where it is fast and easy to prototype new features and turn them eventually into full implementations, without compromising the quality of the rest of the system. Additionaly the product should be portable accross a variety of platforms, including mobile, not only due to a portable codebase, but also due to different interfaces for the various formfactors.
+
+Because no existing codebase fullfills those premises or easily allows to reach them, this project started.
+
 # Vision
 Kontact Quick aims to be an enterprise-ready PIM solution, that has a high-quality and rock solid core. The focus of the core is on high-quality code, maintainability, stability and performance.
 
@@ -9,7 +16,7 @@ Experimental or advanced features are supported as optional addons, to not affec
 Kontact Quick aims to be available on various form-factors and platforms.
 
 # Project Structure
-While this is an open project that welcomes participation from everyone who's interested, we do have an explicit team strucuture to ensure it's clear to everyone who's repsonsible for what. External contributions are alwas welcome and the team is of course open for extension.
+While this is an open project that welcomes participation from everyone who's interested, we do have an explicit team strucuture to ensure it's clear to everyone who's repsonsible for what. External contributions are always welcome and the team is of course open for extension.
 
 Team Lead/Maintainer: Christian Mollekopf
 Team Members: Michael Bohlender, Sandro Knauss, Aaron Seigo
@@ -17,7 +24,7 @@ Team Members: Michael Bohlender, Sandro Knauss, Aaron Seigo
 It's the team leads responsibility to:
 
 * Organize regular online meetings (medium yet unknown)
-* Give direction to the product and ensure it's followed.
+* Give direction to the product and ensure it's followed
 * Direct development and oversee decisions
 * Ensure documentation of decisions
 
diff --git a/docs/requirements.md b/docs/requirements.md
index 1b1f5f24..d909ddc0 100644
--- a/docs/requirements.md
+++ b/docs/requirements.md
@@ -83,3 +83,5 @@ Currently available dependencies:
 * Libraries need to be purpose built and with clear responsibilities. No artificial boundaries that don't help something.
 * Modal dialogs should be avoided.
 
+## Coding Guidelines
+* Run the tests before you push