summaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
authorChristian Mollekopf <chrigi_1@fastmail.fm>2015-10-23 11:51:34 +0200
committerChristian Mollekopf <chrigi_1@fastmail.fm>2015-10-23 11:51:34 +0200
commitb6721435a682b605d0360cd0fb6d3f7a0e0739a9 (patch)
tree21aeb8d251ab44d21c43f5ea17f9b4bb6b6b0d6a /docs
parent177da269a96c263a51494ebb38913b0b8d7a47e5 (diff)
downloadkube-b6721435a682b605d0360cd0fb6d3f7a0e0739a9.tar.gz
kube-b6721435a682b605d0360cd0fb6d3f7a0e0739a9.zip
documentation
Diffstat (limited to 'docs')
-rw-r--r--docs/project.md32
-rw-r--r--docs/requirements.md134
2 files changed, 165 insertions, 1 deletions
diff --git a/docs/project.md b/docs/project.md
index 4d942c90..93e20f7f 100644
--- a/docs/project.md
+++ b/docs/project.md
@@ -5,7 +5,37 @@ We want a codebase where it is fast and easy to prototype new features and turn
5 5
6Because no existing codebase fullfills those premises or easily allows to reach them, this project started. 6Because no existing codebase fullfills those premises or easily allows to reach them, this project started.
7 7
8# Vision 8
9## Differentiators
10In order to avoid simply replicating what's already existing it's important to know how this product differentiates to other existing solutions.
11This section is supposed to outline that
12
13* To Roundcube Next
14 * Native application
15 * Responsivness of UI (assuming we can't reach that in the browser)
16 * Not in a browser (assuming we can't effectively hide that)
17 * Desktop integration (notifications, startmenu)
18 * Offline capability
19 * Cryptography
20
21* To Kontact/Thunderbird/...
22 * Simple but powerful UI (assuming we can achieve that)
23 * Performance (lower resource usage, quick and responsive operations)
24 * Easy & automated setup (scriptable setup process, syncable configuration, setup can easily be nuked and setup from scratch)
25 * Codebase
26 * Well automated tested
27 * Efficient further development
28 * Codebase can go to mobile platforms as well
29
30* To existing mobile applications
31 * Complementing usecases that make the overall product more useful (A mobile/tablet could even be the preferred interface for some interactions due to additional screen and touch capabilities)
32 * Categorization
33 * What's next, schedule checking
34 * Todolist view
35 * Notification center
36 * Better integration with kolab
37
38# Vision Statement
9Kontact 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. 39Kontact 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.
10 40
11We strive to keep the core to the necessary minimum, with minimal dependencies and maximum portability, and in a way that it is maintainable by a small team. 41We strive to keep the core to the necessary minimum, with minimal dependencies and maximum portability, and in a way that it is maintainable by a small team.
diff --git a/docs/requirements.md b/docs/requirements.md
index d909ddc0..a3a72b4a 100644
--- a/docs/requirements.md
+++ b/docs/requirements.md
@@ -85,3 +85,137 @@ Currently available dependencies:
85 85
86## Coding Guidelines 86## Coding Guidelines
87* Run the tests before you push 87* Run the tests before you push
88
89# Roadmap
90
91The final roadmap lives on phabricator.kde.org. This section tries to outline some of the high level aims that should help form the roadmap.
92
93## Priorities
94* High Priority
95 * kolab support
96 * reliability/maintainability (testability)
97 * portability
98 * usability
99 * Mobile
100 * QML interface
101 * Configuration Synchronization
102 * Automatic setup
103 * Enterprise environment support
104 * Professional product, and actual alternative to competitors
105 * Open Protocols/Standards
106 * Multi Accounts & Identities
107 * Crypto / Privacy
108 * Fast at scale
109* Medium Priority
110 * Search / Tags
111 * More integrated with the rest of kolab
112 * Closer integration between mail/tasks/events/addressbook
113 * Well supported
114 * Community
115 * Automation (Wallace)
116 * Extensible / Theming
117 * Multiple open instances
118 * Offline support
119
120## Features
121
122A list of features that has to be refined and put on the roadmap on phabricator.
123This is very much WIP and the features listed here are largely coming from what is existing in Kontact and the Kolab Groupware Server.
124
125### General
126* autoconfiguration/automatic setup/preconfiguration: The complete setup process should require a minimum of configuration and should be fully scriptable.
127
128### Mail
129* folderlist (with search)
130* smart folders
131* multi account & identity
132* threading/conversation view
133* actions
134 * flags: read/unread/important
135 * delete/move/copy
136 * reply to/reply to all/forward
137 * bulk operations on selected/thread
138 * move to special folder
139 * archive
140 * move to trash
141* attachments
142* crypto
143* search
144* tags
145* create event/todo from mail
146* snippets
147* mail composer
148* shared folders / acls
149* undo
150
151### Calendar
152* calendarlist (with search)
153* smart calendars
154* multi account & identity
155* create/edit/modify event/todo (journal?)
156* week/month view
157* ical import/export
158* delegation of events/todos
159* iTip handling
160* freebusy for scheduling
161* tags
162
163### Notes
164* notebooks
165* create/edit/modify note
166* tags
167* note editor
168 * title/content
169
170### Todos
171* todolists
172* create/edit/modify todo
173* tags
174* todo editor
175 * summary/content/start date/due date
176* delegation of todos
177
178## Feature Brainstorming
179* Why is it the sender of a message that dictates how/where I receive/read the message?
180* VOIP system knows when you're away, allows to forward the call to your mobile
181
182### Desktop
183* Autocomplete conversations from sent folder: Automatically merge sent messages that belong to a conversation/thread from the sent folder (making it unnecessary to send a copy to yourself or alike)
184* Inbox for everything: upcoming events, uncategorized todos, open invitations, email, delegated todos. This could either be a mixed inbox for everything (as in what you have to go through), or an overview page with multiple inboxes.
185* No invitation in mail inbox: Mail is a transport mechanism and there is little reason to clutter your mail inbox with invitations. So move invitations to a separate queue.
186* Fuzzy match on folder search: It should be as easy and fast as command-t for vim (meaning as fast as you type)
187
188### Mobile
189* Swipe left right through email inbox (tinder for kolab aka "kinder")
190 * Same works for invitations (accept/decline)
191 * Same for todos, done/do later (if not touched keep for today)
192* Quick inline reply in mails (what's app style)
193* Note taking/todo management on the run, with categorization workflow on the desktop (or also on mobile)
194
195# Deliverables
196These are the high-level aims that we have to work towards. This list is not a final list of deliverables, but should convey the areas we need to work on. More detailed information should eventually be available on phabricator.
197
198* Project Vision
199 * Target Users & Usecases
200 * Personas
201 * Scenarios
202 * Description of environment
203 * UI Mockups for envisioned clients
204 * The target feature-set
205
206* Milestones
207 * First working product: A simple email application for the linux desktop
208 * read-only first
209 * read-write second
210 * Some intermediate releases: Largely depends on what deliverables we want, and wether we can use releases that only contain a subset of the groupware types.
211 * Application by application (calendar, email, ...)
212 * First release on other platforms (e.g. android)
213 * Production ready (1.0): Includes calendar, email, addressbook, notes, tasks with basic functionality (which we need to define)
214 * From here on we implement feature by feature from the roadmap
215
216* Implementation
217 * Inventory of exiting kdepim: This will help to fill the functional blocks, and help in carving out the require featureset.
218 * Functional blocks: We need to identify the function blocks that we require, see to what extent they are already existing and how we can reuse what's there already. The functinal blocks should largely follow from the identified requirements.
219 * Prototype the domain logic: We need to prototype the domain logic as envisioned to see wether that works out. This will be an ongoing process especially while working towards the first milestone.
220 * Prototype with domain logic + akonadi next + trivial UI. Show that this can work in it's basics.
221