1 files changed, 2 insertions, 2 deletions
diff --git a/docs/requirements.md b/docs/requirements.md
index 75b43c8f..22de0cb5 100644
--- a/docs/requirements.md
+++ b/docs/requirements.md
@@ -63,7 +63,7 @@ Currently available dependencies:
 ## Requirements
 * Each module has at least rudimentary tests that can then be extended
    * Tests need to be deterministic, no random timeouts to check if something already happened, only `QTRY_VERIFY` and alike is allowed.
-* Clear layering. No depending on akonadi from everywhere.
+* Clear layering. No depending on Sink from everywhere.
 * Each module comes with a clear set of justified dependencies.
 * Commented code is only allowed in conjunction with a task in phabricator. No dead/commented code.
 * Each module requires a clear interface that allows the module internals to be replaced eventually.
@@ -220,4 +220,4 @@ These are the high-level aims that we have to work towards. This list is not a f
    * Inventory of exiting kdepim: This will help to fill the functional blocks, and help in carving out the require featureset.
    * 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.
    * 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.
-    * Prototype with domain logic + akonadi next + trivial UI. Show that this can work in it's basics.
+    * Prototype with domain logic + Sink + trivial UI. Show that this can work in it's basics.

diff --git a/docs/requirements.md b/docs/requirements.md index 75b43c8f..22de0cb5 100644 --- a/docs/requirements.md +++ b/docs/requirements.md
@@ -63,7 +63,7 @@ Currently available dependencies:
63	## Requirements	63	## Requirements
64	* Each module has at least rudimentary tests that can then be extended	64	* Each module has at least rudimentary tests that can then be extended
65	* Tests need to be deterministic, no random timeouts to check if something already happened, only `QTRY_VERIFY` and alike is allowed.	65	* Tests need to be deterministic, no random timeouts to check if something already happened, only `QTRY_VERIFY` and alike is allowed.
66	* Clear layering. No depending on akonadi from everywhere.	66	* Clear layering. No depending on Sink from everywhere.
67	* Each module comes with a clear set of justified dependencies.	67	* Each module comes with a clear set of justified dependencies.
68	* Commented code is only allowed in conjunction with a task in phabricator. No dead/commented code.	68	* Commented code is only allowed in conjunction with a task in phabricator. No dead/commented code.
69	* Each module requires a clear interface that allows the module internals to be replaced eventually.	69	* Each module requires a clear interface that allows the module internals to be replaced eventually.
@@ -220,4 +220,4 @@ These are the high-level aims that we have to work towards. This list is not a f
220	* Inventory of exiting kdepim: This will help to fill the functional blocks, and help in carving out the require featureset.	220	* Inventory of exiting kdepim: This will help to fill the functional blocks, and help in carving out the require featureset.
221	* 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.	221	* 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.
222	* 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.	222	* 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.
223	* Prototype with domain logic + akonadi next + trivial UI. Show that this can work in it's basics.	223	* Prototype with domain logic + Sink + trivial UI. Show that this can work in it's basics.